| name | implement-spec |
| description | The discipline for implementing any spec or planned change in this repo — breakdown per aspect, red acceptance first, aggressive self-review, live verification like a human (browser included for site work), the detail pass, and the truth sweep. Load before writing the first line of an implementation. |
| metadata | {"version":"1.0.3","origin":"ported from panaversity/zia-vsor-sdk .agents/skills/implement-spec (2026-08-17)"} |
Implementing a spec
The spec is the contract; this skill is how the contract becomes code without losing anything on
the way. It exists because prose discipline drifts and checklists don't — follow it in order.
(Until specs/ exists here, "the spec" is the plan or decision the change implements —
research/ plans and AGENTS.md → Decisions entries count.)
1 · Breakdown before code
Read the spec twice. Decompose it into aspects — every contract clause, every negative promise,
every error slug, every acceptance line is an aspect. Write the list into the working branch's
commit plan. An aspect with no test planned is a hole: fix the plan, not later.
2 · Red first
Turn the spec's acceptance into failing tests before any implementation — integration tests
verbatim where the spec gives observable behavior, unit tests for what it marks unit-tier. Run
them; watch them fail for the right reason. The implementation's job is to turn exactly these red
lights green — nothing more. If implementing reveals the acceptance is wrong, fix the spec in the
same commit (code wins; supersession visible).
3 · Implement in aspect-sized commits
One aspect, its test, its code — smallest change that proves the next assumption. Never batch five
aspects into one commit; review dies there.
4 · Aggressive self-review before declaring anything
Before "done", attack your own work the way this repo attacks specs:
- Re-read the spec clause by clause against the diff — every clause either has a passing test
or a written reason it can't.
- Hostile pass: what did I not handle — interruption, empty input, weird names, missing binary,
no network, wrong platform? The error contract is the map; every failure path must be reachable
and tested.
- For anything non-trivial, run the repo's adversarial pattern: independent reviewers with distinct
lenses (
/code-review at high effort, or spawn review agents). Findings get fixed or recorded
— never quietly dropped.
5 · Live verification — like a human
Tests prove clauses; only running the thing proves the product. Before done:
- Walk the real path by driving the real CLI: the actual command a user runs, on a clean
directory, timed. Read the actual output — is the error's remedy real? Is the handoff next step
correct right now?
- For anything with a page: open it. Build the fixture site, serve it, and verify in a real
browser context (playwright when available; curl + DOM assertions minimum): the page renders,
the title is right, the css token actually applies, dark and light both, zero console
errors, zero failed/external network requests, click the nav, run a search. The predecessor's
flat-layout bug shipped because nobody loaded the page — that class of failure is yours to
prevent.
- Never certify a cached environment. The predecessor certified a stale wheel because its
install cache was keyed on a stable path and a permanent
0.0.0 version — a hand-run walk
installed last run's artifact and reported on code that no longer existed (2026-08-14: a 24KB
theme tarball certified while the staged one was 66KB). The npm analog: never verify from a
reused install dir or a stale global link. pnpm pack the package and install the tarball
into a fresh temp directory for every walk. If a live result contradicts the code you just
wrote, suspect this before suspecting the code.
- Record what the live run taught beside the code (
found live: … comments) — the
predecessor's convention, and the reason its scars don't repeat.
6 · The detail pass
Detail is the product. Before done: every error carries its remedy · every printed path is real ·
--json envelopes (where they exist) are complete and stable · empty states and first-run output
read as designed · measured constants carry date and method · no present-tense claims about
unbuilt behavior anywhere in the diff.
7 · Truth sweep and gate
Any document the change made false is corrected in the same commit (README, AGENTS.md,
docs/status.md, the spec itself). Then the full local gate: pnpm lint:ci && pnpm fmt:ci && pnpm typecheck && pnpm guard && pnpm check:corpus && pnpm test:unit && pnpm build && pnpm test:integration && pnpm publint. Done means: acceptance green on a clean machine, docs true, findings
resolved or recorded.
The rule under all of it
If you cannot tell whether you are done, you skipped step 2. If you are sure you are done but
haven't run it, you skipped step 5 — and that's the step that catches what everything else misses.
