mwguerra/plugins/implementation

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.

1. 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.

1. Idiomatic beats clever; correct beats small; money/security fail closed.
2. Tests must be able to fail. A test that passes against the pre-change code

proves nothing. Bugfixes reproduce red before going green.

1. i18n completeness: a user-facing string added in one locale and missing in the

others is a bug.

1. Honest delivery: conventional commits, real test output, skipped steps declared,

leftovers listed. Never weaken a test to make it pass.

1. 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.