Implement

Implement

Execute the work described by a spec or tickets in thin vertical slices. Each slice cuts a complete path through every layer (schema, API, UI, tests) and lands green. Drive TDD within each slice; verify framework-specific patterns against official docs; subject non-trivial decisions to a fresh-context doubt cycle before they stand.

When to use

• Implementing work described by a spec, plan, or set of tickets.
• Multi-file changes that should land one vertical slice at a time.
• Framework-specific code where current docs determine correct patterns.
• High-stakes or unfamiliar code where correctness matters more than speed.
• Lightweight changes that don't need a spec — small config edits, mechanical renames/moves, project scaffolding (see references/lightweight-changes.md).

Not for: changes needing design decisions (use spec); system architecture (use architecture); pure test-driven exploration or bugfix-via-test with no spec — red-green-refactor as the whole task (use tdd). Have a spec and want slice-by-slice implementation? That stays here, with TDD driven within each slice.

Steps

1. Read the spec or tickets. Orient on what "done" means. Note any

pre-agreed TDD seams — integration points where tests must exist before code lands. If versions are missing or ambiguous, ask; the version determines which patterns are correct.

1. Slice the work vertically. One demoable end-to-end path per slice, sized

to a single fresh context. Keep it compilable between slices. Wide refactors (one mechanical change fanning across the codebase) are the exception — sequence them as expand–contract, never force them into a tracer bullet.

1. For each slice, implement via TDD at the seams:

• Write the failing test first (red), then the code (green), then refactor.
• For framework-specific code: detect the stack and exact versions from the

dependency file; fetch the relevant official docs page (not the homepage); follow the documented pattern and cite the source URL in a code comment. Flag anything you cannot verify as UNVERIFIED. When docs conflict with existing code, surface the conflict — don't silently pick one. See [references/source-verification.md](references/source-verification.md).

• Run the typecheck and the affected test file(s) after each slice. Don't

repeat a command on unchanged code — it adds no information.

1. Run a doubt cycle for non-trivial decisions. A decision is non-trivial

when it introduces branching logic, crosses a module boundary, asserts a property the type system can't verify (thread safety, idempotence, ordering), or has irreversible blast radius (production deploy, data migration, public API change). Name the claim, extract the artifact + contract (not your reasoning), spawn a fresh-context adversarial reviewer, reconcile each finding against the artifact text, and stop on trivial findings / 3 cycles / user override. See [references/doubt-cycle.md](references/doubt-cycle.md).

1. Commit the slice with a descriptive message. Each slice is independently

revertable. Don't mix concerns — feature, refactor, and config changes go in separate commits (see §9, behavior-preserving change discipline, in engineering-principles.md).

1. After all slices: run the full test suite once. Not per slice — once, at

the end. If it fails, localize with the debugging skill; don't re-run blind.

1. Run /code-review on the diff. Address blocking findings before

committing final state.

1. Commit final state to the current branch (if not already committed per

slice).

Verify

• Full test suite passes.
• Typecheck clean.
• /code-review returned no blocking findings.
• Framework-specific patterns carry source citations (or explicit UNVERIFIED

flags); no deprecated APIs used.

• Non-trivial decisions survived at least one fresh-context doubt cycle.
• Work committed to the current branch.

References

• [${CLAUDEPLUGINROOT}/references/engineering-principles.md](${CLAUDEPLUGINROOT}/references/engineering-principles.md) — discipline shared by every skill.
• [${CLAUDEPLUGINROOT}/references/clean-code.md](${CLAUDEPLUGINROOT}/references/clean-code.md) — code-quality bar for the implementation.
• [references/source-verification.md](references/source-verification.md) — source hierarchy, citation rules, retrieval safety.
• [references/doubt-cycle.md](references/doubt-cycle.md) — the five-step doubt cycle and cross-model escalation.
• [references/lightweight-changes.md](references/lightweight-changes.md) — small edits, renames, scaffolding that don't need a spec

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: int2t05
• Source: int2t05/engineering-skills
• License: MIT

Install and usage instructions live in the source repository linked above.