Create an implement-plan skill that consumes a plan artifact

[williamthorsen]

Problem

Implementation is the only phase of the ticket lifecycle with no governing skill. The next-steps menu after plan / design-and-plan defines its implement options as "no skill invocation; implement manually" — sound in-session, where the conversation still carries the ticket and ratified design decisions, but a fresh session handed "Implement path/to/plan.md" is ungoverned: nothing resolves the ticket contract, enforces task order or per-task acceptance criteria, runs the closing quality gates, presents post-implementation next steps, or emits lifecycle events (#984, #985) during the longest phase of the flow. Cross-session and cross-harness handoffs (plan under one model or harness, implement under another) therefore behave differently from same-session implementation.

Proposed solution

A user-invocable implement-plan skill as the canonical implementation path for both same-session and handoff invocation, composed from the existing shared artifacts (ticket-source resolution, lifecycle-events partial, option format) rather than duplicating them:

• Resolves the plan — explicit path, else already-in-context (same-session), else the newest *_plan.md in the ticket's artifact directory — announcing the resolved path and timestamp before executing, and asking when none is found. Resolves the ticket — explicit source, else the branch manifest's stored ticket_url, else plan provenance. The ticket's acceptance criteria are the contract; the plan is the mechanism.
• Executes tasks in plan order against per-task acceptance criteria, raising material divergences to the user rather than silently rerouting, then runs the plan's Verification gates. The plan artifact stays read-only; progress is carried by lifecycle events, not artifact mutation.
• Emits lifecycle events (skill.started, per-task skill.progress, skill.completed, input.requested/input.received at the closing menu).
• Closes with its own next-steps menu (review branch / orchestrated review / create PR) whose review recommendation is made from the observed diff, not predicted at plan time.

The next-steps-after-plan partial collapses its two implement options into one 🚀 Implement option that renders an implement-plan invocation; work-triviality calibration survives as a ➕ context line on that option.

Acceptance criteria

Must have

• implement-plan resolves plan and ticket with zero arguments in a fresh session on a planned branch, and announces the resolved plan path and timestamp before executing
• The ticket's acceptance criteria govern when plan and reality diverge, and the plan artifact is never modified
• Lifecycle events fire at start, per completed task, at completion, and around the closing menu, via the emit-event helper
• The closing menu's review recommendation is derived from the observed diff
• The next-steps-after-plan partial offers three options, with Implement rendering an implement-plan invocation carrying plan and ticket paths
• No content references the removed implement options (complexity-classification.md row updated; next-steps-after-review's separate findings-flow wording is a different flow and stays)