implementation

name	implementation
description	Use when asked to implement, build, add, fix, refactor, or change anything non-trivial in a codebase — especially vague asks ("do that", "make it work") that need clarification, planning, and verified delivery with tests and commits

Implementation Discipline

A delivery process that turns any ask — precise or vague — into a verified, committed, honestly-reported change. Full process: references/process.md (read it when this skill triggers on a standard or epic request). /implement (this plugin) is the explicit entry point with the same process.

The spine

Intake → Investigate → Plan → Build → Verify → Deliver — always in that order, weighted by request size (trivial asks compress phases; epics expand them into an approved plan + task graph).

The rules that don't bend

1. Read before asking; ask before assuming. Context first (CLAUDE.md, memory, deep-analysis docs, git log, similar code), then 2–4 decision questions max — only ones whose answers change what gets built, each with a recommended option.
2. Check docs/deep-analysis/ before building (when present). Known flaws in the subsystem you're touching get fixed first, built around, or surfaced — never silently built upon. Resolved roadmap items get marked with the commit hash.
3. Idiomatic beats clever; correct beats small; money/security fail closed.
4. Tests must be able to fail. A test that passes against the pre-change code proves nothing. Bugfixes reproduce red before going green.
5. i18n completeness: a user-facing string added in one locale and missing in the others is a bug.
6. Honest delivery: conventional commits, real test output, skipped steps declared, leftovers listed. Never weaken a test to make it pass.
7. Escalate mid-flight discoveries — an architectural surprise pauses the build for a question; it does not get assumed away.

Delegation

Independent, well-scoped slices go to the implementer agent (this plugin) in parallel with precise briefs (files, conventions, done-criteria, what NOT to touch). Parallel slices must touch disjoint files — agents writing the same git working tree at once eat each other's staged changes. Own the integration, delegate the slices: the cross-cutting files every slice converges on — CHANGELOG, the route/registration index, central migration or provider wiring, the release pipeline — stay in the main loop; the slices are self-contained limbs that never edit the wiring, and you stitch their output in. When you fan out several slices at once, scout the shared facts once into a common brief (don't make each agent re-derive the architecture), and honor any owner cap on concurrent mutating agents (e.g. a max_parallel_agents memory) — small fan-out first, widen only once disjointness holds; read-only fan-out isn't capped. Coupled, ambiguous, or money/security-critical work stays in the main loop. Always integrate and review delegated output yourself before claiming done.

Companion processes

• Before building on an unaudited large/risky codebase: run deep-analysis first — implementing on top of unknown foundations is how confident regressions happen.
• Epic that spans many places with uncertain blast radius: route through deep-work for the plan → adversarial review → serial execute → synthesize loop.
• Before delivering a high-stakes change or conclusion: run adversarial-verify — an independent pass that tries to refute it catches what your own re-reading won't.