old-coder skill
An evidence-first development skill: the agent wraps code in a spec and a gauntlet of checks so line-by-line review becomes optional
- 759 ★ on the repository
- Last commit
- MIT
Extended access
Why this level
- Runs tests, types and mutation checks over project code
- Installs and runs gauntlet tooling
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/old-coderDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewExtended accessThe tool runs code or makes network calls and only reads external data.
- Runs tests, types and mutation checks over project code
- Installs and runs gauntlet tooling
This is third-party code. Review the repository files before installing.
What it does
The skill gives the agent a loop where trust comes not from reading code but from two artifacts. First the agent writes an executable spec with concrete examples of what the code must and must not do, and you approve that spec. Then the code runs a gauntlet of checks: tests, types, coverage and mutation testing, summarized in an evidence report. It ships a companion skill old-coder-api for HTTP and JSON contracts and a demo project with a ready gauntlet.
Who it is for. For developers who need high assurance and proven, not merely claimed, code quality.
Good fit when
- You want evidence-first TDD with an executable spec
- The change touches money, auth, data loss or concurrency
- You want done to be backed by checks, not a claim
Not a fit when
- A routine change where ordinary tests are enough
- You cannot run tests, types and mutation checks
Example request
Build this feature with the evidence-first loop: a spec for approval first, then code with a checks reportLimitations
The gauntlet confirms what the spec expresses but does not guarantee the spec captured everything that matters, which is why human approval of the spec is the key step. The full loop takes time and a configured toolchain for tests, types and mutation testing. The report gives layered, auditable confidence, not absolute proof.
How to disable. Remove the old-coder folder from your agent's skills directory, for example ~/.claude/skills/old-coder.
FAQ
What exactly do I approve?
The spec, not the code. It is the one human decision, and it breaks the correlation where everything was authored by the same agent.
What is old-coder-api for?
A companion skill for HTTP and JSON contracts: compatibility, authorization, idempotency, pagination and rate limits.
Discussion
No questions or reviews yet.
Related
SkillsA skill that finds AI slop in code: duplicate helpers, empty abstractions, weak tests. It cleans one pattern per commit.
A cleanup skill for agent-written code: finds surplus tests, self-checks and fallbacks and deletes them, keeping behavior
Guard skills for coding agents: a second pass over the diff that catches typical AI mistakes in code, tests and docs
Skills for spec-driven development: brainstorming, planning, debate-style review and idea grilling before the first commit.
A skill that runs a full refactor so agents read code more easily: it finds hidden links and needless dependencies.
A skill of working rules for coding agents: diagnose from code, verify in the running product, turn corrections into constraints.
README in short
The README describes an approach where the human does not read the implementation but trusts two artifacts: an approved spec and an evidence report from the checks. The loop runs from spec to red and green tests, refactor, the gauntlet and an evidence report. The repo holds the main skill, the old-coder-api companion and a rate-limiter demo with gauntlet tooling. Installation is via npx skills add or a folder copy. MIT licensed.
README badge
Original SKILL.md
--- name: old-coder description: 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. --- # 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. ## The Loop SPEC to (human approves spec, not code) to RED to GREEN to REFACTOR to GAUNTLET to EVIDENCE, repeat per behavior.