implement

name

implement

description

Build the feature, fix, or rollback spec'd in blueprint/context/current-feature.md, one small reviewable step at a time. Creates the matching branch, implements each step, shows the diff and explains it in plain English, tests, and iterates until it works. Type: Rollback specs use a guarded reverse patch that preserves Blueprint history. After each approved step it offers an optional commit checkpoint on the branch; the work-level commit, merge, and logging are /complete's job. Use when the user runs /implement, or asks to build, implement, or start the current feature, fix, or rollback once its spec is ready.

implement - build the current spec, one reviewed step at a time

Where this sits in the workflow:

/feature, /fix, or /rollback  ->  [implement]  ->  /complete  ->  next
(the spec)                         (build it,       (commit +
                                    reviewed)        merge + log)

/feature, /fix, or /rollback wrote the spec to blueprint/context/current-feature.md and stopped. This skill turns that spec into code, following the build loop in blueprint/context/ai-interaction.md, without vibe coding: small steps, a visible diff plus a plain-English explanation for each, testing, and iteration until it works, all behind your approval. It builds on a branch and offers an optional commit checkpoint after each step; the work-level commit, merging, and logging are /complete's job.

Before you start

Read blueprint/context/current-feature.md. If it has no real spec (still the stub, or its status is already complete), stop and tell the user to run /feature (for a planned feature), /fix (for an ad-hoc bug or change), or /rollback (for a completed feature reversal) first. Pull the conventions from blueprint/context/coding-standards.md and the data model from blueprint/context/project-overview.md so the code matches them.

If the spec's Design reference points at prototypes/*.html, those mockups are the visual target - build components to match them, and treat prototypes/theme.css as the token source (the spec's first step ports it into the app's global stylesheet before the components are built).

Resuming? If the spec already has some build steps checked off (- [x]), this feature was started earlier and interrupted (often a cleared context). The spec and its ticked steps are files, so pick up where it left off: read which steps are done, check the git branch and git status/log to see what is committed and what is still in the working tree, then continue from the first unchecked step instead of starting over. No separate save/load is needed - the project instructions load current-feature.md every session.

Step 1 - branch

Create and check out a branch named from the spec: feature/<name> for a feature, fix/<name> for a fix, or rollback/<name> for a Type: Rollback spec. If the project isn't a git repo yet, say so and ask the user to run git init first; the loop needs branches. On resume, the branch already exists - check it out instead of creating a new one.

Type: Rollback safeguard

For a rollback spec, do not hand-delete the old feature and do not run a whole commit git revert. Completed feature commits also contain Blueprint history and plan bookkeeping, while current-feature.md now contains the active rollback spec. Reversing the whole commit would damage that state.

Before the first rollback build step:

1. Re-resolve the target archive's introducing commit and confirm it matches the full Target commit SHA recorded in the approved spec.

2. Confirm the target is an ancestor of HEAD, has the recorded single parent, and the only dirty path before applying the patch is the approved rollback spec. Stop on drift.

3. Preview the target's product diff while excluding .agents/**, .claude/**, blueprint/**, AGENTS.md, CLAUDE.md, and prototypes/**. Confirm the preview is non-empty and matches the Product paths in the spec.

4. Apply that product diff in reverse with three-way conflict detection and stage it. Substitute the two approved full SHAs before running:

   git diff --binary <target-parent> <target-commit> -- . \
     ':(exclude).agents/**' \
     ':(exclude).claude/**' ':(exclude)blueprint/**' \
     ':(exclude)AGENTS.md' ':(exclude)CLAUDE.md' \
     ':(exclude)prototypes/**' |
     git apply --reverse --3way --index
   

   Never omit the protected pathspec exclusions for convenience.

5. Show both git diff --cached and git status. Confirm no protected path is staged or modified before presenting the step for review.

If the reverse patch conflicts, stop and report the exact paths and later commit that appears involved. Do not auto-resolve, discard, stash, reset, or switch to a broad checkout. Ask whether to resolve only the conflict allowed by the approved spec or abandon the attempt. A cascade into another completed feature needs a new rollback plan.

Step 2 - build one step, review, iterate, checkpoint

Work through the spec's build steps in order, one at a time. For each step:

1. Implement just that step: the smallest change that satisfies its "done when."

2. Show the diff, not whole files.

3. Explain it, and prove it. Give a short summary: what the step delivered, one line per changed file on what it does and why, then confirm the step's "done when" is met with evidence (build output, a screenshot, a passing assertion). This summary is the comprehension gate, so keep it concrete, not ceremonial. Include a short How to try it note when the step has a manual path: the command, URL, click, endpoint, or output the user can check.

4. Build, and test if the project tests. Run the project's build command (see Commands in AGENTS.md). If the project declares a test command in AGENTS.md (the opt-in switch), run it: a step that adds logic must ship a passing test in the same diff, and the suite must be green before the step is approved (see the Testing gate in coding-standards.md); UI and integration-only steps ride on screenshot plus build evidence. For UI or integration done-whens, prefer Playwright when it is already installed or declared in AGENTS.md; do not add it silently for an unrelated feature. Create focused test files next to the source they cover, per coding-standards.md. Never install a runner mid-step unless the current spec is explicitly the unit-testing setup itself (for example /fix "add unit testing"). If a step surfaces non-trivial logic the spec didn't foresee, add a focused test then, or note why not. When a step's done-when is behavioral (a click, a download, a flow across screens), run /check to prove it against the running app rather than eyeballing it.

5. Iterate until it works. If it fails or the user wants changes, revise the step (re-prompt or hand-edit the code), show the updated diff, and re-test. Repeat until it works and the user approves. Nothing is committed until the user is happy with the step.

6. Mark it done, then prompt to move on. Once the step is approved, check that step off (- [x]) in blueprint/context/current-feature.md so progress survives a context clear. If the step repaired a finding tracked in blueprint/context/findings.md, set that finding's status to fixed now too and note the repair in its Resolution line. Never set closed: a repair is re-reviewed by /audit before it clears, because a fix can introduce a worse defect than the one it removed. Then offer a short choice, noting that checkpoints are optional since makes the real feature-level commit. Use the current tool's short user-input prompt when available; when you've just produced a long block to read (a deep explanation, a big walk-through), ask in plain text instead, so the prompt doesn't cover what the user is still reading:

Never batch the whole thing into one diff. If a step's diff is too big to read, split it. Build and tests must pass before any commit.

Step 3 - hand off to /complete

Before handing off, check blueprint/context/findings.md. A P0 or P1 finding still open or fixed there means /complete will refuse the merge, so close the loop now:

• Repair each open P0 or P1 as an extra reviewed step. First append it to the spec's build steps in current-feature.md (- [ ] Repair F-03 - <title>) so the repair is on the record and survives a context clear, then run the same loop as Step 2: smallest change, diff, plain-English explanation, evidence. Check the step off and mark the finding fixed together.
• Then run /audit so the repairs are re-reviewed and can move to closed. A repair this skill made never closes itself.
• If the user decides a finding should not be fixed, only they can set accepted (reason recorded). A finding that looks wrong goes back to /audit to invalidate with recorded evidence; this skill never sets accepted or invalid.

When every step is built and the build and tests pass (committed as checkpoints or not), stop with a compact review packet:

• branch name
• what changed, grouped by file or area
• checks run, with the exact command or proof used
• how to try it manually, or a pointer to /try
• ledger state: any findings still open or fixed, by ID
• known risks, skipped checks, or follow-up notes
• next action, usually /complete

Then tell the user /complete makes the one work-level commit, logs it (archive, update the build plan for a feature or rollback, reset), and merges with approval. This skill does not touch main.

Rules

• One small step per diff; the user reviews and approves each before any commit.
• Explain every change in plain English. Understanding the code is the point.
• Iterate on the branch until each step works; never commit code the user hasn't approved.
• Follow blueprint/context/coding-standards.md (server vs client, scope user-owned queries by the authenticated user id, validate inputs, and so on).
• Build only what the spec says. If the spec is wrong or thin, stop and fix the spec first, do not improvise.
• Per-step commits are optional checkpoints. The work-level commit, the merge, and any push are /complete's job.
• For Type: Rollback, reverse only the approved product diff and preserve all protected Blueprint paths.

Formatting

Format the output to match the project's conventions in blueprint/context/ai-interaction.md: concise, scannable markdown, with lists for enumerations and tables for matrices rather than dense paragraphs.