implement

Implement the work described by the user in the spec or tickets. Read docs/agents/issue-tracker.md and docs/agents/triage-labels.md first. If either is missing or unreadable, stop and tell the user to run /setup-supermatt-skills in Claude linked installs or Cursor, /supermatt:setup-supermatt-skills from the Claude plugin, $setup-supermatt-skills in Codex, or /skill:setup-supermatt-skills in OMP. Resume only after both required docs exist and have been read. Fetch each ticket you are given with the tracker's Read an issue operation and read it in full. A parent you are asked to pick from is not such a ticket: see below.

When the user names a parent spec and asks for its next ticket, use the configured tracker's List children and Resolve blockers operations. A frontier ticket is an open child of that exact parent, with every blocker confirmed closed, whose state maps to the canonical ready-for-agent role in triage-labels.md: a label on hosted trackers, a Status: value locally. Do not require a numeric blocker count or interpret missing information as zero. For a custom tracker without these named operations, enumerate children from its documented read/list operations and explicit parent links, then read every declared blocker; stop if those operations cannot establish complete membership or blocker state. An incomplete listing stops selection; an unreadable, malformed, or unresolved child's eligibility is blocked and must be reported, not guessed.

Treat ## Parent as an actual Markdown section, not a quoted example or a mention elsewhere. It must identify one unambiguous parent; resolve links to canonical identity and report conflicts with native parentage rather than choosing a convenient match.

Choose the eligible child with the lowest ticket number. A ticket with no code left, because every criterion is already on the default branch or only a human step such as a release remains, is not frontier: name it and what it waits on, then take the next one. With no frontier ticket left, say so, report blocked or unknown candidates, and stop. Name the ticket you picked before you start. When a ticket names a parent, read only the parent's sections the ticket points to or the work needs, with the tracker's Read a section operation where it has one. An assigned migration-map row requires reading the parent's authoritative ## Migration map section before implementation. With no spec or issue, the decisions settled in this conversation are the spec: write them to a file in the OS temporary directory, so the review can check against them.

When two criteria of a ticket cannot both hold (for example, a data shape the ticket names against "no test changes"), ask the user which one wins before you write code, and post the answer on the issue with the Comment on an issue operation. A conflict resolved in silence comes back as a review finding and the same question after the work is done.

When the issue is a pull request, check out its head branch first, and push your commits back to it. If the push is refused (a fork that does not allow maintainer edits), stop and tell the user.

Before you start, record the current commit with git rev-parse HEAD, and on the default branch create a branch named by the repo's convention.

Before changing data contracts, state transitions, shared mutable state, or retryable effects, load codebase-design through the host's skill mechanism. Follow its state-contract guidance for the affected behavior.

Where possible, at pre-agreed seams, load and follow the tdd skill through the host's skill mechanism. Seams that the spec or issue names or the user explicitly confirmed are pre-agreed. Obtain confirmation for any newly reached seam, including refactor and review-fix seams, before writing tests.

Use tdd's affected-seam checks during each cycle. A finished slice is one completed behavior or fixed review finding, and can contain several cycles. Before committing it, complete the repository's full required gate. Reuse checks already green on the same relevant files, dependencies, configuration, and environment; run only the missing or invalidated checks. Chain newly run checks and the commit on their own exit statuses (&&) so a red check stops it. Run checks bare, never through an output filter, and wait for background checks to finish. A handoff or evidence report alone does not require another application build or test run; repository rules, hooks, and CI still apply.

Commit each finished slice to the current branch, so the work lands as small commits instead of one commit that carries the whole ticket. Reference each issue the work implements in each commit message (#<n>, or the file path on a local tracker).

Once every slice is committed, QA the changes since the commit you recorded in a fresh context: this context wrote them, so it shares their blind spots. Spawn one subagent that loads and follows the qa skill through the host's skill mechanism, and give it that commit as the fixed point and the spec path or issue reference as the request, without an implementation summary or suggested verdict. Include a working preview's startup command, URL, worktree, process ownership, and temporary config paths when available, so QA can verify and reuse the setup. Tell it to report back without changing repository files or filing an issue. On each later pass, pass the prior QA report, its tested commit, the fix diff, and the earlier fails with their steps; qa scopes the follow-up. Without subagents, load and follow qa yourself and state the independence gap. Fix each fail test-first by loading and following tdd, commit the fix the same way as the work, and QA again until the verdict has no fail. Name each blocked scenario and what it needs in your final message.

Then load and follow the code-review skill through the host's skill mechanism to review the changes since the commit you recorded, and give it the spec or issue as the spec. Its report ends on the verdict line, and it is not the end of this skill: continue to the next step in the same turn, working from that report. A single reader's output, such as a .peer.md file, is input to the review, not a finding to fix.

Fix every verified finding the review reports on this branch, at every severity, and commit the fixes the same way as the work. Two kinds of finding go to the user as a question instead: one whose fix would reverse something the spec asked for, and one whose cause lies outside this repo (an agent, service, or library working as designed), so no change here removes it. Every other finding ends fixed or asked: one you judge not worth fixing (a one-caller helper, a local convention) goes to the user as a question too. Open each question with the code it concerns (file:line) and what the choice changes, then put it as options (O1, O2, ...), each with what it does and what it costs. When the reviewer proposed a fix, one option is that fix in the reviewer's own words. End the question on the option you recommend and the deciding reason, so the user can answer with a code. Once the user answers, persist each accepted decision and its reason: comment on the issue with the Comment on an issue operation when one exists; otherwise append it to the supplied spec or the named temporary review spec. Pass that updated artifact to follow-up QA and review so later sessions can read what the user already settled. Done when your final message quotes the verdict line of each review and names every finding code of each review with how it ended: the commit that fixed it, or the question that asks it.

Leave each issue you implemented open. A closed issue is what unblocks the tickets that wait on it, so it closes only once its commits are merged into the default branch. The merge step closes it through /ship-pr in Claude linked installs or Cursor, /supermatt:ship-pr from the Claude plugin, $ship-pr in Codex, or /skill:ship-pr in OMP. Tell the user the work is ready to ship only when every review axis is complete, every verified P0 and P1 finding is fixed, and every remaining verified finding is fixed or has a disposition explicitly accepted by the user. Unanswered finding questions block readiness. Issue closure still waits on the merge. A pull request stays open for a human to merge.

When the work is a refactor, or when a review fix only restructures code, keep behavior the same:

• If the code has no tests, pin its current behavior first: load and follow the tdd skill through the host's skill mechanism and write the characterization tests it describes. Commit them on their own (test:) before the refactor.
• Commit the structural change as refactor:, and leave test files alone in it, except for a mechanical rename or move. A test that has to change means behavior changed.
• Tests that the design agreed are superseded by tests at a deepened interface are deleted in their own commit, not a refactor: one, once the new tests are green.
• When a step goes red, revert it and take a smaller step.

Follow-up verification

A review fix that has to change behavior (a bug or a spec gap) goes test-first: load and follow the tdd skill through the host's skill mechanism. Once such fixes are committed, run follow-up QA, then load and follow code-review on the fix commits only (since the commit before the first fix), passing the prior reports and their checked commits. Every later review round uses the previous reviewed commit as its fixed point, not the original branch base. A test-only fix uses the affected tests and independent follow-up review; it does not invalidate browser QA of unchanged runtime code. Fix what the review reports the same way before calling the work ready to ship. When the review asks for both kinds, fix the structural findings first and commit them as refactor:, then make the behavior fixes on top of that commit.