What it does. 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.
Highlights
- Write behaviors as Gherkin-style scenarios or a named test list — concrete
- Include what the change must NOT do (invariants that must survive: existing
- The spec doubles as the authorization point: include the setup plan —
- Show the spec to the human in plain language and get approval **before writing
- An answer to a question is not an approval. If you asked the human to
When to use it. 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…
Install
npx skills add AmazingAng/old-coder --skill old-coder
Or copy the skill folder manually:
git clone https://github.com/AmazingAng/old-coder.git
cp -r old-coder/skills/old-coder/ ~/.claude/skills/old-coder
Source: AmazingAng/old-coder — 708 stars, MIT, last pushed 2026-08-18.
