All Skills
/to-code Phase 3: Carrying Out the Plan

The /to-code Skill

Builds pre-decided work from approved vertical tracer bullets, drives two-layer testing at Clean Architecture seams, typechecks continuously, and commits atomically.

"Third. Carry out your plan of the solution, check each step. Can you see clearly that the step is correct? Can you prove that it is correct?" — George Pólya, How to Solve It (1945)
TERMINAL OR CHAT PROMPT 
/to-code @docs/plan/checkout-plan.md Execute vertical tracer bullet Task 1, run speed-tiered verification, and commit atomically.

What it does

to-code builds work that has already been decided. You point it at a planned vertical tracer bullet in docs/plan/{slug}-plan.md or a bug remediation plan in docs/bug-reports/{slug}-bugfix.md, and it writes the code, drives two-layer test-driven verification at decoupled seams, runs typechecks and linters as it goes (check:fast), executes the full test suite (check:full) at phase boundaries, and commits cleanly to the current branch.

It never reopens the plan. There is no interview, no speculative scope expansion, and no impromptu proposal of a different architecture. Whatever was agreed upstream in the specification and plan is the immutable contract, and the skill's sole job is to turn that vertical tracer bullet into a verified green commit. That is what separates it from typing "build this" at a fresh agent, which often redesigns the architecture while half-building it.

When to reach for it

Where the work currently lives decides whether this is the right skill:

The work is… Reach for
A planned vertical ticket in an approved plan /to-code @docs/plan/{slug}-plan.md (one ticket per turn, pausing at approval gates)
An approved plan ready for full end-to-end execution /to-code auto @docs/plan/{slug}-plan.md (autonomous mode with 4 circuit breakers)
A bug with an approved remediation plan /to-code @docs/bug-reports/{slug}-bugfix.md
A routine mechanical fix (≤ 2 files) with no formal plan /to-quick-fix
An approved specification, not yet decomposed into tracer bullets /to-plan first, then /to-code per ticket
Requirements or API contracts not yet specified /to-spec
Already built, and you want an unsparing quality & SOLID audit /to-review directly

Prerequisites

  • Approved Plan Document: Requires an approved Technical Specification (docs/spec/{slug}-spec.md) and Implementation Plan (docs/plan/{slug}-plan.md). The Pause Rule mandates explicit plan approval before coding.
  • Clean Git Baseline: In autonomous mode (/to-code auto), stops before Task 1 if git status --porcelain reveals dirty files outside planning artifacts.
  • Configured Speed-Tiered Verification: Mechanical commands (check:fast, check:task, check:full) must be configured in docs/ARCHITECTURE.md Section 8.

What one run does

A single tracer-bullet execution run has five sequential steps:

  1. Context Ingestion & Seam Grounding: Reads the target ticket, extracts Ref ID (REQ-XXX) and AC Ref (AC-XXX), inspects docs/plan/ progress checkboxes, and locates existing code seams without re-running completed tickets.
  2. Two-Layer Testing Mandate (RED → GREEN): Author a failing unit or widget test at the seam (TDD Red), then write clean, intention-revealing production code that deterministically turns the assertion green.
  3. Continuous Typecheck & Linting: Runs check:fast (< 5s) per coherent seam edit. Never allows compilation errors or lint failures to accumulate across edits.
  4. Post-Green Simplification Pass (Derive Differently): Reviews diff against the 6-Rung Decision Ladder (YAGNI → Codebase Reuse → Stdlib → Existing Deps → Simplicity → Polish) to eliminate accidental complexity while keeping tests green.
  5. Selective Atomic Commit: Stages exclusively the files modified for this ticket (git add <file>) and creates an atomic conventional commit linked to the task ID (e.g. feat(auth): implement [TASK-003] tracer bullet).

Pre-agreed seams & Floor-Guard Anti-Cheat

The skill's central idea is Uncle Bob's Clean Architecture seam: the public boundary you observe behavior at without reaching inside (Entities → Use Cases → Adapters → Frameworks). Tests live at seams.

The 5 Forbidden Cheat-to-Green Moves:

  • Adding suppressions (@ts-ignore, @ts-nocheck, eslint-disable, # noqa).
  • Skipping or weakening tests (.skip(), xit(), stripping assertions).
  • Leaving unimplemented stubs (throw new Error("Not implemented"), /* TODO */).
  • Lowering coverage thresholds or quality ratchets in config files or docs/ARCHITECTURE.md.
  • Adding unapproved rule exceptions without explicit human sign-off.

Common questions

Can I run all tasks in the plan at once without pausing after each ticket?

Yes. Invoke /to-code auto @docs/plan/{slug}-plan.md. In autonomous mode, the agent executes planned tracer bullets sequentially without human stepping between tasks, but halts immediately on 4 Mandatory Circuit Breakers: (1) Dirty git baseline, (2) Test/build failure after 2–3 attempts, (3) Spec-vs-code discrepancy, or (4) High-risk destructive actions (database drops, auth permission changes).

What happens if existing codebase reality contradicts the approved Spec?

The agent is strictly forbidden from guessing, hacking around the discrepancy, or silently rewriting the contract. It immediately stops execution, emits a structured CONFUSION: or MISSING REQUIREMENT: block in chat, and asks you whether to adapt the code or update the specification first.

Why did /to-code refuse to build an additional feature I requested in chat?

The Mandatory Pushback Rule: /to-code strictly carries out pre-agreed specifications and plans. Unplanned features introduce scope drift and unverified invariants. The agent will push back and instruct you to route the request through /to-spec or update the plan first.

It's working if

  • The session opens by reading the ticket or plan and restating what it will build, rather than asking you what to build.
  • Real test runner tool calls appear in the execution trace before code modifications occur (TDD Red → Green).
  • Fast typechecks (check:fast) execute repeatedly per coherent seam edit, with zero compilation errors accumulating.
  • The git commit stages only the specific files modified for that ticket (zero git add -A or scratch file leakage).
  • Surrounding code is left cleaner than it was found (Boy Scout Rule), with zero unrequested out-of-scope refactorings.

Where it fits

to-code is Phase 3 in the main idea-to-ship pipeline: 

/to-explore → /to-prd → /to-spec → /to-clarify → /to-plan → 🛑 PAUSE → /to-code → /to-review → /to-docs

It receives approved vertical feature slices from /to-plan (or bug remediation plans from /to-fix). Once all slices turn green and pass the test suite, it hands off directly to /to-review for the 5 SOLID principles, defensive security, and release-readiness audit.