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>
51 lines
2.2 KiB
Markdown
51 lines
2.2 KiB
Markdown
# 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.
|
|
|
|
1. **STATUS** — one line: done / blocked / partial, and the outcome.
|
|
2. **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.
|
|
3. **ISSUES** — anything found that is wrong, missing or surprising. One line
|
|
each. `none` is a valid and welcome answer.
|
|
4. **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`.
|