← ClaudeAtlas

old-coderlisted

Evidence-first development — surround the implementation with an executable spec and a gauntlet of constraints (tests, types, coverage, mutation) so line-by-line review becomes optional. Use when the user explicitly asks for high-assurance or evidence-first work ("reliable", "TDD", "prove it works", "I won't read the code"), or when the change touches high-stakes domains (money, auth, data loss, concurrency, public API). For routine changes where the user just wants normal tests, write good tests directly instead of invoking this loop.
skillsgateway/skillsgateway · ★ 0 · AI & Automation · score 66
Install: claude install-skill skillsgateway/skillsgateway
# Old Coder: Reliable Coding Under Constraint and Test The human will NOT read your implementation. Their confidence comes entirely from two artifacts you produce: (1) an **executable specification** they approve before you write code, and (2) an **evidence report** proving the code ran the gauntlet. Your job is to make those two artifacts trustworthy enough that line-by-line review becomes optional within the spec's boundaries. This inverts the normal review model: **trust moves from inspection to constraints.** Be honest about what that buys: the gauntlet turns the constraints the spec expresses into executable evidence — it cannot show the spec expresses everything that matters, and it is not self-authenticating, because a checker can be unsound and a mapping can claim more than it demonstrates. That is exactly why the human approves the SPEC (the one artifact that breaks the everything-authored-by-the-same-agent correlation), and why EVIDENCE reports layered, auditable confidence, never absolute proof. Every shortcut you take against the gauntlet destroys the only basis of trust. **Composition with `old-coder-api`:** when both skills apply, this skill owns workflow order, SPEC approval, the gauntlet, and EVIDENCE; `old-coder-api` owns the HTTP/JSON contract. Run its scope check and API gates while drafting SPEC, turn the surviving constraints and risks into acceptance criteria and checks, then map those checks into EVIDENCE. Do not run two parallel workflows. ## The L