Files

T

jpmschweitzerandClaude Opus 5 0dc68dc1b8 docs(meta): fork-for-sidequests rule + wiki skill corrections from the cold test

The cold test worked as an experiment: a fresh agent with Skill(wiki) cited it first, refused to hand-edit body frontmatter, knew the corp regen-db stamp trap, and knew corp_specialization is missing from its own template. It also found four things the skill had wrong or missing, all verified before folding in: body frontmatter is a MIDDLE layer (atlas CLI -> systems.db -> scaffold writes the page -> import_economics reads it back), not the origin GOVERNANCE.md implies; the four empty categories are Q-118, an open scope question rather than an invitation; some bodies are visual-regression goldens and nothing in wiki/ says so; and status is editorial, not an import gate. Also: check current state before editing, since the test's own task described a change that was already true.

T-1244 corrected in the same pass — tectonics is derived from planet_class via a lookup (body_definition_parser.py:563), so the measured 68% 'low' is a projection of the class distribution, not an authoring choice. The ticket's question changed accordingly.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-20 00:46:04 +02:00

2.2 KiB

Raw Blame History

Fork for side quests

A side quest is work that is worth doing but is not the task in hand: filing a ticket, writing up a finding, chasing a tangent, a docs pass. Doing it inline costs the main thread its context — which is why forward intent tends to go unrecorded at all (T-1245).

Default: fork it. Spawn an agent from the frozen context, keep working.

Fork when

Writing or appending a ticket, especially a long one.
Recording a finding that is real but off the current path.
An investigation whose ANSWER matters but whose SEARCH does not — "does X exist", "who else calls this", "is this documented anywhere".
Anything you catch yourself deferring with "I'll note that later". Later is where notes die.

Do NOT fork when

It is on the critical path — if the current task blocks on the answer, do it inline and keep the reasoning visible.
It needs a judgement only the lead has context for (a design call, a trade-off the user has been steering).
It is one command. A fork costs more than the work.

The report contract — required, and brief

Every fork returns exactly this, in this order. Long reports defeat the purpose; the lead is mid-task.

STATUS — one line: done / blocked / partial, and the outcome.
FILES TOUCHED — every path created or modified, or none. This is not optional. The lead has to know what is in the working tree before staging, and an unreported edit turns into a mystery diff at commit time.
ISSUES — anything found that is wrong, missing or surprising. One line each. none is a valid and welcome answer.
FRICTION — what was hard to find, misleading, or only found by luck. This is the docs/skills feedback loop; a fork that hit a wall silently wastes the evidence.

Git discipline

Forks do not commit. .claude/hooks/git-centralize-guard.sh already blocks .git-mutating commands for teammates, so this is enforced rather than trusted — but the FILES TOUCHED line is what makes it workable, because the lead is the one who stages and has to know what changed and why.

If a fork's work should not land in this branch at all, say so in STATUS rather than leaving the lead to discover it in git status.

2.2 KiB Raw Blame History