v0.3.0 — executor-subagent chain execution

Executor-subagent chain execution

Chains now run each goal's implementation in a fresh-context subagent instead of the main conversation. Main context only orchestrates — spawn executor, spawn judge, apply verdict, advance cursor.

This is the load-bearing change that lets multi-goal chains run autonomously without main-context aging out. Main-context cost per goal drops from "all the implementation work" (tens of thousands of tokens accumulating per goal) to "executor return summary + judge spawn" (~10K tokens flat). A 9-goal chain that used to need 9 fresh sessions can run in one.

The judge-as-subagent pattern v0.2 already had was half the answer. v0.3 extends it: executor is also a subagent.

What changed

• skills/goal-chain/SKILL.md — Step 6 (Start mode) and Advance-mode next-link path now spawn an Agent with a structured executor directive. Steps 7–8 receive the executor's structured return (STATUS / SUMMARY / VALIDATOR_OUTPUT_TAIL / FILES_CHANGED / BLOCKERS), spawn the judge, apply the verdict, and either advance or re-spawn the executor with the judge's fix-list (within max_rejections).
• skills/goal/SKILL.md — new top-level Execution modes section explaining inline (standalone /goal) vs subagent (chain-driven). Execution Loop step 7 branches per mode; step 8 marked as inline-only.
• skills/goal-judge/SKILL.md — Invocation sources section documents the three entry points: inline auto-fire from /goal, chain-orchestrator invocation after executor return, on-demand /goal-judge for advisory review. Inputs section gains a subagent-mode-extra-context note: executor's self-report is a hint, not authoritative — judge still verifies independently against the contract.

Backward compatibility

• State files unchanged. chain.json / state.json / active.json / log.md shapes are identical. A v0.2 chain in progress can be resumed under v0.3 — only the execution mechanism differs.
• Contracts unchanged. All v0.2 contract.md files remain valid. validate-contracts.py schema is unchanged.
• Inline /goal unchanged. Standalone /goal "<objective>" still runs in main context with ScheduleWakeup pacing. v0.3 only affects chain-driven execution.
• 80/80 lifecycle test assertions pass across 14 tests (scripts/test-lifecycle.py) — state shapes verified unchanged.

Migration

• Existing in-progress chains: just /plugin update goalkeeper and resume. The next chain advance will spawn an executor subagent for the next goal automatically.
• Existing inline /goal users: no action needed.
• New chains: the recommended pattern is to prep all contracts in one session, then /goal-chain once and let it run all goals to completion in a single main-context conversation.

Design decisions worth flagging

• Executor subagent is fresh context, no conversation history. This forces contracts to be fully self-contained at prep time. Any goal contract with checkpoint-1 questions ("ask user about X") is a smell; resolve those at prep, not during execution.
• Judge is still spawned by main context, not by executor. Preserves the invariant that the judge sees an independent view (executor's diff + log + validator output) and reasons fresh. If the executor could spawn its own judge, the judge would be in the executor's sub-sub-context with shared-rationalization risk.
• Reject + re-spawn cycle stays within main context. If the judge rejects, main re-spawns the executor with the original contract + log (which now includes the judge's fix-list). Each retry is a fresh subagent; orchestration + rejection_count live in main. This caps loops at max_rejections without burning main-context budget on internal iterations.
• Subagent mode does not need ScheduleWakeup. The subagent runs end-to-end in one turn. ScheduleWakeup was an inline-mode concept for pacing long-running validators across main-conversation turns; subagents handle long validators within their own turn.

Discovery context

The change was driven by hitting the v0.2 ceiling on a real 9-goal chain in production. After 2 successful goal completions in the same main-conversation context, context budget became the constraint — not validators or judges, the orchestrator itself. The fix wasn't "smaller goals" or "more sessions" — it was finishing the subagent pattern v0.2 had already half-implemented for judges.

Install / upgrade

If you have goalkeeper installed via the Anthropic plugin marketplace:

/plugin update goalkeeper

Or for a fresh install:

/plugin marketplace add itsuzef/goalkeeper
/plugin install goalkeeper@0.3.0

Then confirm:

/plugin list

Full CHANGELOG

See CHANGELOG.md for the complete v0.3.0 entry including the prior v0.2.0 (missions) and v0.1.x history.