#1004 Add an implement-plan skill for the implementation phase

[williamthorsen]

What

Adds an implement-plan skill, bringing the implementation phase under the same governance the rest of the ticket lifecycle already had. An agent handed a saved feature plan is now instructed to carry it through to a finished branch: treating the ticket's acceptance criteria as the contract wherever plan and code disagree, leaving the plan itself unedited, and running the plan's own verification gates. The instructions hold whether the plan was written moments earlier in the same conversation or handed cold to a fresh session.

The menu offered after planning now presents three options rather than four, its two implement options collapsed into a single Implement. Whether the finished work wants a review pass is now decided once there is a diff to judge, rather than before any code exists.

Why

Implementation was the only phase of the ticket lifecycle with no skill behind it. That was survivable in-session, where the conversation still carried the ticket and the design decisions behind the plan, but it meant a plan handed to a fresh window — or to the other harness — was carried out however that session improvised, with nothing resolving the ticket contract, holding task order, running the closing gates, or reporting progress during the longest phase of the flow. It also forced the review decision to plan time, where it had to be guessed before anyone knew what the code would look like.

Details

🎉 Features

• implement-plan resolves its plan from an explicit path, else the plan already in context, else the newest plan artifact for the ticket — matching both the base and revised filename forms, so a refined plan wins over the original it supersedes. It announces the resolved plan and timestamp before executing, so a superseded plan is caught while the choice is still free.
• The ticket resolves from an explicit source, else the branch manifest's stored URL, else the plan's own provenance. When every source fails, the skill says so and runs against the plan as the sole contract rather than stalling or silently substituting one.
• Tasks run in plan order against their own acceptance criteria, each committed as its own commit, since everything the closing menu offers reads committed history. Divergence that no longer fits the plan's approach goes to the user before implementation continues; adapting details within it does not.
• Lifecycle events fire at the start of the run, after each completed task, at completion, and around the closing menu, so a watching surface can render the phase while it runs.
• The closing menu offers a review pass, an orchestrated review, or a PR, and recommends from the realized diff rather than the plan-time estimate. Work that looked trivial at plan time carries that read forward as a note rather than a commitment.
• The skill reads the feature plan shape only. A spike plan carries investigation steps and a deliverable instead, so the plan-time menu renders a separate 🔬 Investigate option for it, invoking no skill, and the skill turns one away at the step where it reads the plan. Whether carrying out a spike plan should get a governing skill of its own is tracked as a separate decision.

🧪 Tests

• The spec-inlining suite covers implement-plan as an option-format consumer, and pins the collapsed menu's Implement mapping and its spike carve-out — the clauses an improvised menu would drop, each guarding a named failure.

Closes #1004

[github-actions]

Dependency audit

Production dependency audit passed.