old-coder: a coding-agent skill that trades code review for two documents
An old coder's strategy for the agent era: don't read the code — make it run the gauntlet. Evidence-first development skill for coding agents, inspired by Uncle Bob.
At a glance
- What is it?
- AmazingAng/old-coder is a markdown skill that makes a coding agent write a test plan you approve and an evidence report you read, instead of you reading the diff. It is a workflow protocol, not a test runner, and the repository is candid about what the gauntlet cannot prove.
- Who is it for?
- Adopt old-coder if you already run a coding agent on a codebase with a real test suite and you want a reviewable artifact instead of a diff, and if you can afford the mutation-testing and property-testing layers the skill asks for. Skip it if your project has no runnable test command, if you cannot approve a spec before coding starts, or if you need proof that the spec itself is complete, because the README states the gauntlet cannot supply that.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 29 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem old-coder targets: review bandwidth, not code generation
Coding agents can produce more code than a person can read. The README quotes Robert C. Martin's stated strategy of not reading code written by agents at all, and treating constraints as the substitute: unit tests, gherkin tests, QA procedures, quality metrics, mutation testing, coverage. The repository turns that position into an installable skill. The intended user is someone running an agent loop on an existing project where tests can be executed, and who is willing to spend their attention on two documents rather than on a diff. It is not a tool for generating a greenfield project from a prompt, and it is not a library you import. The artifact is markdown plus a references directory, which is why the README says it works with Claude Code, Codex CLI, Cursor, Aider, or a custom agent loop. The bet is narrow: if you are not going to read the code, the things you do read have to carry the trust. That sentence is the whole thesis, and everything else in the repository is machinery for making those two documents worth reading.
SPEC, RED, GREEN, REFACTOR, GAUNTLET, EVIDENCE: the actual loop
The README's flowchart runs SPEC to RED to GREEN to REFACTOR to GAUNTLET to EVIDENCE, with a dashed edge from REFACTOR back to RED labeled next behavior. SPEC comes before any code and contains concrete examples of what the code must and must not do, plus the tools the agent wants to install. Approving it is described as the single yes or no you give. RED means writing a test and watching it fail; GREEN means writing code until it passes; REFACTOR means cleaning up with tests untouched. GAUNTLET is the check battery. EVIDENCE is a report from one final fresh run, which the README says you can rerun yourself with a single command. The important architectural detail is that no step in the loop is a program shipped by this repository. There is no daemon, no plugin, no test harness. The agent reads SKILL.md and its references, then behaves differently. That means the enforcement mechanism is instruction-following, and the failure mode of the skill is the same as the failure mode of any prompt: an agent that ignores it produces a plausible-looking report anyway.
What the gauntlet actually checks, and why mutation testing is in the list
The README gives a table of checks, each paired with the question it answers. Full test suite: did anything break. Types, lint, and complexity: any obvious mistakes, any unreadable tangles. Changed-line coverage: is every new line exercised by a test. Mutation testing: plant bugs on purpose, do the tests catch them. Property-based tests: do the rules survive hundreds of random inputs. Real execution: does it run outside the test harness. Supply chain and secrets: did the agent pull in risky packages or leak a key. Suite health: are the tests themselves stable, in any order. Beyond that table there is a menu of domain layers (concurrency, UI checks, API compatibility, performance, observability) selected per task from a risk model documented in references/gauntlet.md. Effort scales with risk: the README says a typo fix runs a couple of checks, while anything touching money, logins, data, or concurrency runs everything and the agent attacks its own code with hostile inputs first. Mutation testing is the check that distinguishes this from ordinary coverage-driven workflows. Coverage tells you a line executed; mutation testing tells you whether a wrong line would have been caught. The README also notes, in the demo description, that fresh-context verification of earlier green states found an unsound mutation runner, which is a useful admission: the check itself is code and can be wrong.
Installation: npx skills add, or copy SKILL.md into a rules file
The primary install path is the skills CLI: npx skills add https://github.com/amazingang/old-coder --skill old-coder. For Claude Code the manual route is cp -r skills/old-coder ~/.claude/skills/ for a user-level install, or the same copy into <project>/.claude/skills/ for a project-level one; the README says you can then invoke /old-coder or let it trigger on high-assurance requests. For other agents, the instruction is to add skills/old-coder/SKILL.md to your AGENTS.md, rules file, or system prompt, and to keep its references/ directory alongside it. That last clause matters: SKILL.md points at references, and references/gauntlet.md is where the risk model lives, so a copy that takes only the markdown file loses the layer-selection logic. There is a second, optional skill in the same repository, old-coder-api, installed with npx skills add https://github.com/amazingang/old-coder --skill old-coder-api, or both at once by passing --skill twice. The README states the division of labor when both apply: old-coder owns workflow, approval, and evidence; old-coder-api owns the API contract, and its gate decisions become SPEC constraints and gauntlet checks. The API skill covers compatibility, authorization, idempotency, pagination, rate-limit, and operability gates. Nothing in the material describes a version pinning mechanism for the skill itself, so a rules file that references a copied SKILL.md will drift from upstream until you recopy it.
The honesty rules, and the limit the README states plainly
Because the agent grades its own work, the skill imposes reporting rules. The README lists them: never weaken a test to make it pass; never report a check that did not run; label anything unverified as unverified rather than pass; if no human approved the spec, the report must say so and claim less confidence. These are behavioral constraints on the agent, not assertions the tooling can enforce on its own. The README then states the boundary directly: the gauntlet turns the constraints expressed in the spec into executable evidence, and it cannot prove the spec is complete or authenticate its own checkers and mappings. That is why a human approves the SPEC, and why EVIDENCE reports bounded, auditable confidence rather than absolute proof. This is the most interesting design choice in the repository, and also the one that most limits it. If your spec omits a requirement, every check can pass and the code can still be wrong in the way that matters to you. The demo section reinforces the point rather than hiding it: the README says fresh-context verification of earlier green states still found real behavioral defects and an unsound mutation runner, and that the current report discloses both the fixes and the final state's verification status.
The demo-rate-limiter numbers and how to rerun them
The repository ships demo-rate-limiter/, described as a rate limiter built end to end under old-coder. Its evidence.md is presented as the point of the exercise: 41 tests, 100% coverage (49/49 statements and 20/20 branches), and 22/22 planted bugs caught. Those figures come from the README and the demo's own report; they are not independent measurements. The README gives the command to reproduce the whole report: cd demo-rate-limiter, then python3 -m venv .venv && .venv/bin/pip install -r requirements-dev.txt -e ., then ./tools/gauntlet.sh. That is the single command the EVIDENCE document is supposed to be rerunnable with, and it is the concrete thing to check before believing any report the skill produces on your own code. Note what the demo does and does not establish. It shows that the workflow can be carried through on one small Python project with a purpose-built gauntlet script. It does not show how the approach behaves on a large existing codebase, on a language without a mature mutation-testing tool, or on a repository whose test suite is already slow or flaky. The README's own account of finding defects in previous green states suggests the gauntlet is best understood as raising the cost of shipping a defect, not as a gate that closes.
Where old-coder is the wrong tool, and what to compare it against
Three cases look like poor fits. First, projects without an executable test command. The gauntlet's checks are all downstream of a suite that runs, and the skill has no mechanism for creating one from nothing. Second, work where the spec cannot be written before coding. The approval step is the trust anchor; if requirements are genuinely being discovered by writing the code, the SPEC becomes a formality and the EVIDENCE inherits its weakness. Third, any setting where you need the checks themselves to be trustworthy without inspection, since the README concedes the gauntlet cannot authenticate its own checkers. The nearest comparison is plain test-driven development with a mutation-testing tool such as mutmut or Stryker wired into CI. That approach makes the checks executable by a machine and enforced by the build, but it produces no document a human approves before coding and no bounded report after. old-coder inverts that: the enforcement is a protocol the agent is asked to follow, and the deliverable is two reviewable artifacts. A CI pipeline will fail a build whether or not anyone reads anything; old-coder will not fail anything, it will hand you a report that says unverified where the agent could not check. If you want a hard gate, you want the CI route. If you want a paper trail that scales with the agent's output, that is the gap this fills. The two are not mutually exclusive, and the README's gauntlet table is close to a specification for what such a CI pipeline would run.
Maintenance cost, licence, and what to verify before adopting
The licence is MIT, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are retained. That is the whole of the licence implication here; the repository ships markdown and a demo, not a linked library, so there is no copyleft surface to reason about. Nothing in the supplied material discusses a support policy, a release cadence beyond v0.1.0 dated 2026-08-15, or a compatibility matrix across agent versions. The maintenance cost that is visible is the cost of the gauntlet itself: mutation testing and property-based testing add runtime to every task the agent performs, and the README's risk scaling exists precisely because running everything on a typo fix is wasteful. There is also the cost of keeping the copied SKILL.md and its references/ directory in sync with upstream if you install manually rather than through npx skills add. Before adopting, do three things. Run the demo command above and confirm the reported numbers reproduce on your machine. Pick one small change in your own repository, ask the agent for a SPEC, and read it as if it were the only artifact you would ever see, because under this workflow it nearly is. Then check whether your test suite can survive the suite-health check, since a suite that passes only in one order will make the gauntlet's output misleading rather than reassuring.
Editorial conclusion
Adopt old-coder if you already run a coding agent on a codebase with a real test suite and you want a reviewable artifact instead of a diff, and if you can afford the mutation-testing and property-testing layers the skill asks for. Skip it if your project has no runnable test command, if you cannot approve a spec before coding starts, or if you need proof that the spec itself is complete, because the README states the gauntlet cannot supply that. Before trusting any report it produces, rerun the demo with cd demo-rate-limiter && python3 -m venv .venv && .venv/bin/pip install -r requirements-dev.txt -e . && ./tools/gauntlet.sh and compare the numbers.
Community notes