/implement

name: implement
description: "Make an ad-hoc change no plan file governs, then run post-implementation QA. Use when the user asks to \"just implement\", \"implement directly\", \"implement without a plan\", or \"apply the change\"."

Implement

Standard implementation flow: load style rules, make the change, run post-implementation QA.

Task Tracking

At the start, use `TaskCreate` to create a task for each step:

1. Run `/code-style` skill 2. Load task-specific skills 3. Make the change 4. Run verification 5. Run `/smoke-test` skill for UI/UX changes 6. Run `/preview` skill for UI/UX changes 7. Post-implementation QA

Step 1: Run `/code-style` Skill

Run the `/code-style` skill to load existence, reuse, mirror, and symmetry rules before editing.

Step 2: Load Task-Specific Skills

Scan the work for types that match available skills, matching against the richest context available: a plan's **Implementation Steps** if a plan is in conversation context, otherwise the user request, a prior skill's task description, or an improvement entry. For each unambiguous match, run the skill via the Skill tool. For example, if the work includes "add a Drizzle migration" and a skill exists whose triggers reference Drizzle migrations, load it. If a work type has no matching skill trigger, do not load a generic skill.

If unsure, do not load.

Step 3: Make the Change

**Unless one subagent per step was settled on for a plan that governs the work**, apply the change described by the current context — the user request, a prior skill's task description, or an improvement entry. Keep the edit scoped to what the context describes.

When the fix changes how a value is constructed, grep for every other site that constructs it and fix the ones carrying the same defect; treat these siblings as part of the same change. If the scope balloons beyond what the context specified, stop and confirm scope before continuing.

**When a plan governs the work and one subagent per step was settled on for it**, the Implementation Steps go to subagents, and this session reviews what each one returns. Use `TaskCreate` to create a task for each Implementation Step, then take them in order, one at a time.

Before each spawn, capture `git status --short` and run `git stash create`, which snapshots the working tree without changing it and prints nothing when the tree is clean.

Spawn a single subagent (`model: "opus"`, no `name`). Wait for it to report before continuing; do not relaunch it if it has not yet reported. Its prompt directs it to read `${CLAUDE_SKILL_DIR}/references/step-implementer.md`, and gives:

• The plan's path and the Implementation Step to implement
• What earlier Implementation Steps changed that this one builds on, and anything they left for it to finish
• The task-specific skills from Step 2 that this Implementation Step's work matches
• The checks it must pass
• A cap on any verification whose count the plan leaves open, such as mutation runs

When it reports, review what it changed against the plan: `git diff <snapshot>`, or `git diff HEAD` when the tree was clean, shows its changes to tracked files, and `git status --short` compared with the capture shows the files it added. Run the checks the prompt named. Then settle everything the report leaves open before the next Implementation Step starts:

• Make a small correction in this session.
• Give larger rework, or a block this session can clear, to a new subagent for the same Implementation Step, passing along what the first one reported.
• Take a block or a deviation that changes what the plan delivers to the user with `AskUserQuestion`, and carry out the answer through one of the two routes above.
• Carry a gap that a later Implementation Step's work closes into that step: name it in that step's prompt, and confirm it closed when reviewing what that step changed.

Mark the Implementation Step's task completed once nothing is left open.

When the user asks how a running subagent is doing, read its progress from the same comparison against the capture. When the user asks to change its course, message it with the SendMessage tool. After a subagent has reported, changes go through the routes above.

Step 4: Run Verification

Before this step starts or uses a process that runs until it is stopped, such as a server or a watcher, run the `/test-run-rules` skill. Its rules verify without modifying code, so act on a failed check as this step directs.

If a Verification section is in conversation context (e.g., from a plan file), execute the commands, smoke checks, or MCP tool invocations it specifies. If a check fails, run the `/investigate` skill. If a check is blocked by a dependency, unclear requirement, or environmental issue, use `AskUserQuestion` to surface the blocker and let the user choose how to proceed. If no Verification section is in context, go straight to the configuration check below.

When the Verification section lists both checks that can force code edits, such as a formatter or a linter, and a slow run, such as an integration suite, finish the edit-forcing checks and the edits they force before starting the slow run. When an edit lands after a slow run started, re-run it; when re-running is not practical in this session, state which part of the verification the final code did not get.

When the change adds or documents a configuration override — an environment variable, build flag, or any setting a reader is told to set — prove that a supported path delivers it: set the value, run the build or process meant to consume it, and confirm the output changed. When no supported path delivers it, fix the path or drop the documentation before this step completes. Restore the setting afterwards, and rebuild or discard any output produced with the non-default value. Passing checks are no evidence here, since a default that matches the value already in use keeps a broken override invisible to every run that never asks for a different