implement-spec: write the hand-back inline, not in a fork #33

Before you file

• I searched the existing issues.
• I looked in Discussions under Ideas.

Kind

Change to a skill

Component

implement-spec (skill)

Proposed behaviour

implement-spec writes its hand-back by invoking the report skill inline, in the orchestrator, instead of launching a fork of the conversation that invokes it and pasting the result. Step 6 drops the fork paragraph and its two fallback rows (no fork; fork returns something other than one Message), keeping the missing-skill fallback; step 8 and the CX block say the same invocation. The report-skill design records the fork as a rejected alternative with the numbers below, and the contributing guide's list of Claude-only pieces drops subagent_type: fork. The two implement-spec eval cases keep passing; their "no fork in this run" line goes, since nothing forks.

Motivating case

PR #31 chose the fork so the skill and template text, about 1,500 tokens per hand-back, would stay out of the orchestrator's context. Measured on 2026-10-16 after the merge, the premise does not hold:

• Every call reads the whole conversation as input. Inline, the orchestrator writes the Message in the call it makes anyway: one read. Forked, the fork reads the context to write, and the orchestrator reads it again to paste: two reads per hand-back. In a live session the fork call cost about 670,000 input tokens, cached; an ordinary run at its later waves is 100,000 to 300,000. The inline residue, 1,500 tokens riding in later calls, never approaches one extra read.
• The docs say a skill cannot have the foreground: "Where fork mode is on, as it is by default in an interactive session, Claude Code runs the subagent in the background, forks and non-fork subagents alike, and Claude can't ask for the foreground." So the pasted Message always lands a turn after the launch.
• A fork cannot ask the author anything and has no channel back to the main session while it runs (tested 2026-10-16: a sub-agent has SendMessage but no address for its launcher). Only main can ask, so nothing that ends on a question belongs in a fork.
• The headless eval sandbox has no fork agent type at all ("Agent type 'fork' not found"), so every eval of implement-spec already exercises the inline path; the fork path was proved once, by hand, after the merge (report skill and communication rule: write every message for a reader who did not watch the work #26, comment of 2026-10-16).

The only thing the fork buys is a slightly smaller context near the compaction limit, in exactly the runs where its second read is most expensive.