StackMap
Subscribe
Explore / old-coder
AmazingAng

old-coder

Uncle Bob's strategy as a skill: the agent writes a SPEC you approve, then runs a gauntlet — tests, mutation, property-based, coverage, supply chain — and hands you an evidence report instead of code.

667 51 Python MITupdated 6 days ago
View on GitHubDispute this mapping →
Curator's take

The right skill when you've accepted you won't read the diff: you read two documents instead — a SPEC of concrete must and must-not examples before any code, and an EVIDENCE report with real numbers from one fresh run you can reproduce with a single command. Effort scales with risk, so a typo fix runs two checks while anything touching money, auth or concurrency runs mutation testing, property-based tests and hostile inputs. It's plain Markdown, so any instruction-following agent can use it. Read the honesty clause carefully: the gauntlet turns your spec into executable evidence, it cannot prove the spec is complete or authenticate its own checkers — the demo's own report caught an unsound mutation runner behind an earlier green state.

Mapped by ShipWithAI editors · links verified
README.md

old-coder: SPEC → GAUNTLET → EVIDENCE

Old Coder skill(老码农 skill)

中文说明 →

An old coder's strategy for the agent era: don't read the code — make it run the gauntlet.

A skill that makes coding agents prove their work. Instead of you reading every line, the agent pushes its code through a gauntlet of checks and hands you a test plan before coding and an evidence report after. You review those two documents, not the code.

It's plain markdown, so it works with any coding agent that follows instructions: Claude Code, Codex CLI, Cursor, Aider, or your own agent loop.

Installation

Install old-coder:

npx skills add https://github.com/amazingang/old-coder --skill old-coder

Or manually:

  • Claude Code — copy the skill into a skills folder, then invoke /old-coder or let it trigger on high-assurance requests:
    cp -r skills/old-coder ~/.claude/skills/
    # or copy it to <project>/.claude/skills/
    
  • Other agents — add skills/old-coder/SKILL.md to your AGENTS.md, rules file, or system prompt, and keep its references/ directory alongside it.

Optional companion: old-coder-api

This repository also includes a focused HTTP/JSON API design and review skill. Install it when you want compatibility, authorization, idempotency, pagination, rate-limit, and operability gates:

npx skills add https://github.com/amazingang/old-coder --skill old-coder-api

To install both skills:

npx skills add https://github.com/amazingang/old-coder --skill old-coder --skill old-coder-api

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 idea

From Uncle Bob (Robert C. Martin), on working with coding agents (original tweet):

My current strategy is to not read any of the code written by my agents. That’s the only way I can take advantage of their productivity. What I do instead is to surround the agents with extreme constraints. Unit tests, gherkin tests, QA procedures, quality metrics, mutation testing, test coverage, and a plethora of others. In the end, I have very high confidence in the code they produce because they’ve had to run the gauntlet of all of my constraints and tests.

If you're not going to read the code, the things you do read have to carry the trust instead.

How it works

flowchart LR
    SPEC["📋 SPEC<br/>agent writes a test plan,<br/>you approve it"]
    RED["🔴 RED<br/>write a test,<br/>watch it fail"]
    GREEN["🟢 GREEN<br/>write code until<br/>it passes"]
    REF["🧹 REFACTOR<br/>clean up,<br/>tests untouched"]
    G["🛡️ GAUNTLET<br/>run every check"]
    EV["📊 EVIDENCE<br/>you read the report,<br/>not the code"]
    SPEC --> RED --> GREEN --> REF --> G --> EV
    REF -. next behavior .-> RED

You read two documents:

  • SPEC (before any code) — concrete examples of what the code must and must not do, plus which tools the agent wants to install. Approving it is the single yes/no you give.
  • EVIDENCE (after the code) — real numbers from one final fresh run, rerunnable yourself with a single command.

The gauntlet in between:

Check The question it answers
Full test suite Did anything break?
Types + lint + complexity Any obvious mistakes? Any unreadable tangles?
Changed-line coverage Is every new line actually 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 actually run, outside the test harness?
Supply chain & secrets Did the agent quietly pull in risky packages, or leak a key?
Suite health Are the tests themselves stable, in any order?

Plus a menu of do

Continue your stack

What teams reach for next — and why each earns a place beside old-coder. Ranked by curator confidence.