frontier-skills

Your model is smart enough. Its work habits aren't.

Drop-in Agent Skills that make any coding agent plan, verify, and ship like a frontier model — plus a project scaffold that bakes the same discipline into every repo you start. Model-agnostic, zero dependencies, works with Claude Code or any agent that can read files.

The problem

Most agent disasters aren't intelligence failures. They're discipline failures:

• 🟢 "All tests pass!" — the tests were never run.
• 🔁 A bug gets "fixed" three times without ever being reproduced once.
• 💸 A mystery process gets restarted on a box that turns out to trade real money — because a stale "build finished" notification said it was fine.
• 🏗️ A hand-rolled project skeleton ships broken on day one, with no tests and no way for the next agent to pick it up.

Frontier models mostly avoid these through judgment. Smaller, cheaper, and older models don't have that judgment — but they follow explicit instructions well. So this repo converts the judgment into instructions: classification tables, first-matching-row decisions, forbidden-action lists, and fill-in templates that a much weaker model can execute mechanically. You keep the cheap fast model; you get the expensive model's work habits.

60-second start

git clone https://github.com/zhengbingquant/frontier-skills
cp -r frontier-skills/skills/* ~/.claude/skills/          # Claude Code, all projects
# or per project:  cp -r frontier-skills/skills/* your-project/.claude/skills/

That's it. Each skill's frontmatter description tells the agent exactly when to trigger it — no prompting needed. For claude.ai / the API, upload the folders as Agent Skills; for container harnesses, mount them into the skills path (commonly /mnt/skills); for any other agent, paste a SKILL.md into the system prompt and keep the folder readable.

Start a new project with the scaffold (stdlib-only, Python 3.10+):

python3 skills/new-python-project/scripts/new_project.py ~/my-tool \
    --name my-tool --description "One sentence about the tool."
cd ~/my-tool && make setup && make test && make run       # green before feature work

What changes

What's inside

The scaffold lives inside the new-python-project skill so one folder copy gives you both the procedure and everything it needs.

A taste of the rules

From plan-and-verify — the phase most agents skip:

Hard rule — verification is named before code is written: a plan is invalid unless it contains the exact command(s) you will run to prove the change works and what output you expect. "I will test it" is not a plan; .venv/bin/pytest tests/test_export.py -q expecting 2 passed is.

From live-system-guardrails — the rule that saves prod:

The prime rule: when uncertain, classify as LIVE. Misclassifying a dev box as live costs politeness; misclassifying a live system as dev can cost real money.

From the Definition of Done:

"Almost done" with any item missing is NOT done — report the gap instead of rounding up.

Want to see it in motion? A real bootstrap → plan → verify → report cycle, with every observed output, lives in examples/worked-example.md.

Design principles

1. Explicit over judgment. Every rule is executable by a materially weaker model: tables, exact commands, forbidden lists — no "use your best judgment".
2. Verification before code. Done is defined by observation, never inference.
3. Safe by default. Unknown environments are live; notifications are unverified; destructive actions need evidence, blast radius, and a rollback in writing.
4. Durable. No model names, prices, or product-of-the-week references — built to hold up no matter what's running it.
5. The repo is the memory. Generated projects carry their own agent contract, operating docs, checklist, and definition of done, so any agent or human picks them up cold.

Repo layout

frontier-skills/
├── README.md
├── LICENSE
├── .github/workflows/ci.yml   ← validates skills + scaffold contract on every push
├── examples/worked-example.md ← a real plan→verify→report cycle, outputs included
├── scripts/validate.py        ← repo self-check (frontmatter, links, generation)
└── skills/
    ├── plan-and-verify/
    │   ├── SKILL.md
    │   ├── references/debugging.md
    │   └── assets/{plan-template.md, report-template.md}
    ├── live-system-guardrails/
    │   ├── SKILL.md
    │   └── assets/system-profile-template.md
    └── new-python-project/
        ├── SKILL.md
        ├── scripts/new_project.py
        └── assets/
            ├── OPERATING_MANUAL.md
            ├── REVIEW_CHECKLIST.md
            ├── DEFINITION_OF_DONE.md
            └── template/          ← the project scaffold ({{placeholders}})

Files under assets/template/ intentionally contain {{placeholders}} and only become valid Python once instantiated by new_project.py.

Contributing

Issues and PRs welcome — especially new failure modes with the explicit rule that would have prevented them, and scaffold templates for other languages. Keep contributions model-agnostic and judgment-free (rules a weak model can follow mechanically). Before opening a PR, run python3 scripts/validate.py — CI enforces it plus the full scaffold contract (generate → install → test → lint → run) on multiple Python versions.

License

MIT — see LICENSE.

⭐ If these skills keep your agent honest — or your prod alive — a star helps other people find them.