version: "1.0.2" name: implement description: Use when implementing a small or medium change directly in the current session, without a multi-task plan — via design's fast-path routing, or direct invocation ("/implement", "just implement this", "quick fix").

Implement

The fast path for small/medium work: no plan.json, no per-task files, no orchestration. Implement inline in the current session, then hand off to one holistic review.

Design Gate

If design's tier router already presented a mini-design (or short design doc) and got explicit approval for this exact request earlier in this session, that gate is satisfied — skip straight to Worktree Setup.

Otherwise, this is a direct invocation (the user asked for an implementation without going through design first) and the Compressed Design Gate below runs before any code is touched — no exceptions.

Compressed Design Gate (direct invocation only)

The same wrong-assumption failures that unexamined plans cause on a large feature happen just as easily on a one-file fix that felt too trivial to plan. Size changes how much ceremony the gate needs, not whether it runs.

1. Challenge the framing — what problem does this solve, is there a simpler alternative? (mirrors design's Challenging Assumptions).
2. Ask clarifying questions only if genuinely ambiguous — don't manufacture questions for a request that's already clear.
3. Present a mini-design: 2-5 sentences covering what changes, where, and why this approach — no formal doc, no file written.
4. Resolve workflow + approval in one AskUserQuestion — settle the workflow now, alongside approval, so the choice is made before implementing instead of surfaced after the work is already done. Run caliper-settings get workflow:

• If a value is returned, note it ("Using your configured workflow: <value>") and ask a single Approval question (Approve / Needs changes).
• If PROMPT_REQUIRED, ask two questions in one call — Workflow (Create PR / Merge PR / Stop after review) and Approval (Approve / Needs changes).

Wait for approval before writing any code. "Needs changes" loops back to step 3; the resolved workflow value carries forward to the review hand-off.

Worktree Setup

If design already ran its own worktree setup before handing off — it does this for both Small and Medium tiers, passing $WORKTREE — reuse that worktree; the signal is whether $WORKTREE was passed in, not the tier name. Don't create a second one. On direct invocation, set one up:

• From the main checkout, create the worktree with git and register the main repo for permission-free access, then EnterWorktree(path: "$WORKTREE") — a path-entered worktree is never auto-removed by the harness. See: skills/design/worktree-isolation.md for the rules the session runs under once inside.

``bash MAIN_ROOT=$(caliper-main-root) WORKTREE="$MAIN_ROOT/.claude/worktrees/<feature>" git worktree add "$WORKTREE" -b <feature> mkdir -p "$WORKTREE/.claude" && jq -n --arg d "$MAIN_ROOT" '{permissions:{additionalDirectories:[$d]}}' > "$WORKTREE/.claude/settings.local.json" seed-agent-memory "$WORKTREE" ``

• Bootstrap dependencies — See: skills/design/dependency-bootstrap.md (lives in skills/design/; read it there rather than duplicating its content here)
• Run tests to establish a clean baseline before changing anything

Inline TDD

Implement directly in the main session — no subagent dispatch for fast-path work. Follow the TDD cycle for test discovery, common failure modes, and boundary-test patterns at cross-component seams.

See: ./tdd.md

Commit Discipline

Commit frequently in small, logical, atomic units as work lands rather than batching the whole change into one commit at the end. Small commits keep the downstream review's diff easy to reason about and give you a clean rollback point if a later step reveals an earlier one was wrong.

Chain to Implementation Review

REQUIRED SUB-SKILL: Use implementation-review — once the change is implemented and tests pass, invoke it in standalone mode over the feature branch diff. No plan.json exists on this path, so its mode-detection picks standalone automatically.

Map the workflow setting to implementation-review's continuation flag (all four schema values, exactly):

Resolve the value:

• Downstream of design: the value is already resolved from design's workflow question earlier in this session — reuse it, don't re-prompt or re-read settings.
• Direct invocation: the Compressed Design Gate already resolved it (from settings, or the workflow question asked at approval) — reuse that value, don't re-prompt or re-read settings.

Integration

Workflow: design (small/medium tier) or direct invocation → this skill → implementation-review (standalone) → pr-create/pr-review/pr-merge