[sabind]

Why

Closes #33

PR #31 chose a fork of the conversation for implement-spec's hand-back so the skill and template text, about 1,500 tokens per hand-back, would stay out of the orchestrator's context. Measured after the merge, the premise does not hold: every call reads the whole conversation as input, so inline the orchestrator writes the Message in the call it makes anyway, one read, while forked the fork reads the context to write and the orchestrator reads it again to paste, two reads per hand-back. A skill cannot have the foreground, so the pasted Message always lands a turn late; a fork cannot ask the author anything; and the headless eval sandbox has no fork agent type, so every eval already exercised the inline path. 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.

What

implement-spec invokes the report skill inline, in the session, to write its hand-back, at every cadence and for the final report, and at spec cadence launches the next wave in the same turn straight after the report instead of ending its turn on it.

Changes

• Replace the fork in skills/implement-spec/SKILL.md step 6 with an inline invocation of the report skill, drop the two fork fallbacks and keep the missing-skill one, say the same in step 8 and the CX block, and add that the report ends the message, not the turn, so at spec cadence the next wave's executors are launched in the same turn straight after it. The cost is paid only to trigger the skill and once more to run the skill, versus just one to run the skill without the fork loading context. There is nothing it does not cover that was not already there; it is a minor change to the runtime, and nothing really breaks it since it is simpler than the previous version. The same-turn wording was added after the spec-cadence eval failed twice on the first wording, the run ending its turn on the wave 0 report.
• Drop subagent_type: fork from the contributing guide's list of Claude-only pieces. A docs update.
• Update the works-one-wave and works-all-waves eval prompts and READMEs: the "no fork in this run" line goes, and the cases say the hand-back is written by the report skill invoked inline. The tests were updated to match; no grader changed.
• Bump the version to 0.11.0.

Testing

make validate passes: 19 unit tests and both plugin validations.

Evals, run on 2026-10-16 at list price, one case per invocation:

Case	Wording	Score	Runs	Cost
works-one-wave	first	1.00	1	$0.60
works-all-waves	first	0.56	2	$0.57, $0.59
works-all-waves	with the same-turn fix	1.00	2	$0.99, $1.05
works-one-wave	with the same-turn fix	1.00	1	$0.54

The two failures are the record of why the same-turn sentences exist: the kept trace showed the run writing wave 0's report through the report skill, its Next saying "Wave 1, task 2 ... It starts now.", and the turn ending there, so wave 1 never started.

Risk and rollout

Minor: a simpler runtime for the same hand-back. The version is 0.11.0; teammates pick it up with claude plugin update freethinking@freethinkingit. No rule or template changed.

Notes for reviewers

• There is not much to question besides the premise: that a fork is a second read of the context per hand-back and buys only context headroom. The issue holds the measurements.
• The merged spec under .claude/specs/report-skill/ is left as it was, on the principle in Workflow rule: specs as records, in-flight choices, discoveries as issues #6 that a spec is the record of its task and is not edited after the merge; this issue and PR are the record of the reversal. The spec's text on the fork is therefore stale by design.
• The fork path was proved once by hand after PR [#26] Add the report skill and the communication rule #31 merged (report skill and communication rule: write every message for a reader who did not watch the work #26, comment of 2026-10-16); after this PR nothing in the plugin forks.

🤖 Generated with Claude Code