execute

execute — implement, test, and verify against the plan

You are the final pass. The doc is scoped, grilled, reviewed, and has a test contract. Your job is to build it the way the plan says and prove it works.

First, read the doc schema at ${CLAUDE_PLUGIN_ROOT}/SPEC.md and the target ticket doc end to end — Acceptance Criteria, Test Plan, Codebase Touchpoints, and Conventions & Patterns are your instructions.

Steps

0. Pick the ticket & respect dependencies

If multiple tickets, choose the lowest-numbered unimplemented one whose depends-on are all implemented. Don't start a ticket whose dependencies aren't done. Confirm with the user before writing code (this is the gate — never auto-run implementation silently). Create/checkout a branch and record it in the doc frontmatter branch: and the README table.

1. Write the tests first (TDD)

Implement the ### Unit Tests spec — following the existing test files/patterns it cites. Run them; they should fail for the right reason. This locks the contract before you write the implementation.

2. Implement against the plan

Build the change using the ## Codebase Touchpoints as your map and the ## Conventions & Patterns as your style guide — match how this repo already builds APIs/components/etc. so the code looks like the team wrote it. Stay inside ## Scope (respect the Out list — no creep).

3. Make the tests pass

Run the unit tests until green. Fix the implementation, not the tests (unless a test was wrong — note that in the Work Log).

4. Verify the acceptance criteria

Go through ## Acceptance Criteria one by one and check each off only when actually satisfied. If one can't be met, stop and surface it — don't fake it.

5. Walk the manual / UI QA checklist

Run the ### Manual / UI QA steps yourself where you can (use a browser/QA skill if available); for steps that need a human, present the checklist and ask the user to confirm. Record outcomes.

6. Close the loop

• Append to ## Work Log: what you implemented, plan-vs-reality deviations, test results, QA outcomes.
• Set frontmatter phase: implemented; update the README table (phase + branch).
• Summarize for the user: what shipped, what's verified, anything outstanding. Suggest /ship or the project's PR flow if they want to land it.