Case files / PAN-110

PAN-110Live

Skills that keep their scars

A set of Claude Code skills for repo shape, AWS, Android and security, kept in git. Projects log traps as they hit them. A trap seen twice, or one that cost an hour, is promoted into the skill itself.

Control flow

  1. Hit: a trap costs a project time
  2. Log: repo and shared trap log
  3. Sync: merged at each milestone
  4. Promote: a person decides what is rule (human gate)
  5. Prove: a throwaway app, stamped and built

Human gate: A person decides what gets promoted into a skill · Stack: Claude Code skills · Git · Python · PowerShell · Seed species: Husk

Problem

An agent starting a new project knows what its playbook knows. If the playbook was written once, from one project that worked, it is wrong as soon as the second project does something differently, and every trap the first project paid for is paid for again.

How it works

The skills cover repo shape and gates, AWS, a plain Linux host, security, and Android. They live in git and load straight into every session.

Each project writes a trap down the moment it bites: in its own CLAUDE.md, with the consequence, and in a shared trap log. If a fix contradicts something a skill ships, the skill is patched in the same unit of work.

At each milestone the project’s traps are synced into the log and de-duplicated. A trap seen in two projects, or one that cost more than an hour, is a candidate for promotion into the skill itself. An audit script lists the candidates. A person decides what becomes rule.

After a promotion, a gate stamps a throwaway app from the skill and builds it, about four minutes, to prove the skill still produces something that works.

Results

  • About 315 traps logged so far, 166 of them from one project.
  • Trap syncs land at each phase commit, so the skill moves with the work rather than after it.

What broke

The first Android skill was right for one project and wrong for the next: version pins moved, a database library started to need a newer compile SDK, and a trap that cost an afternoon in one repo cost an afternoon again in the next. The fix was the loop, not a better draft.

Limitations

Promotion depends on the milestone rhythm being kept. The eval sets exist but are run by hand.

Next

Run the skill evals on every promotion, not only when someone remembers.

Open the living case file