implementation-phaselisted

Use when implementing an approved ticket, once analysis and planning are done — the fixed procedure that replaces rewriting an implementation prompt per ticket. Pre-analysis that proves the build green and names every file and existing test before an edit is made; implementation keyed to the principles a diff can actually violate, from a kernel free of domain through database ownership, migrations, secrets, degrading optional dependencies, wiring, anti-corruption and observability to the API patterns; tests at the layer holding the logic, with regression coverage and the per-test bar; a manual test document only where automation genuinely cannot substitute for a human; recorded decisions that cite the principle behind them; and the pull-request description. Formatting is left to .editorconfig rather than restated. Refuses to proceed if the standards are not actually readable in the session.
konradcinkusz/architecture-standards · ★ 0 · AI & Automation · score 72

Install: claude install-skill konradcinkusz/architecture-standards

# The implementation phase You are in the implementation phase for one ticket. Analysis, clarification and planning are done and approved; this document is what happens next. Follow the steps in order and do not collapse them. One rule outranks everything below, because breaking it is the most expensive failure mode in this estate: **read the standards, do not re-derive them.** The architecture is already written down — [15 principles and a compliance checklist](https://github.com/konradcinkusz/architecture-standards/blob/main/docs/architecture/00-REFERENCE-ARCHITECTURE.md), and a guide per domain under [`docs/guides/`](https://github.com/konradcinkusz/architecture-standards/blob/main/docs/guides/). An agent that reconstructs an architectural rule from whatever code it happens to see will reconstruct it wrong, and the diff will look plausible. **The input is this session.** What varies per run is the change agreed in the conversation — the analysis, the decisions taken, the scope approved. The procedure below does not vary at all, which is why it is a document you invoke rather than a prompt you rewrite per ticket. It takes no argument: everything it needs is already in front of it. Second of three phases: [`TICKET-ANALYSIS.md`](https://github.com/konradcinkusz/architecture-standards/blob/main/docs/delivery/TICKET-ANALYSIS.md) comes first and its gate is what admits you here; [`PR-REVIEW.md`](https://github.com/konradcinkusz/architecture-standards/blob/main/docs/delivery/