Agent systems · July 2026

Thin skills, sharp tools

I rebuilt my agent orchestration from five prose rulebooks into three tiny guides and two CLIs. The guides tell the model when and why. The CLIs make the right move the only easy one — on any harness.

The journey

v1 · guardrails 5 skills + hook scripts policing every tool call Codex only v2 · rulebooks 5 long skills + eval harness overlapping prose rules Codex only v3 · judgment 3 thin skills + 2 CLIs mechanics live in tools every harness, one bundle

The three skills, and the tool each one drives

A skill is a guide under 400 words — a limit my own test suite enforces. It tells the model when to act and what done looks like, then points at a CLI for everything procedural. The model reads the tool's help the first time it needs it, and never carries the mechanics in context.

skill

compass

Settles direction. Quick disposable prototypes, one question at a time, decision recorded on the shelf.

→ drives decision-shelf
skill

relay

Delivers bounded work. A clear brief in, one compact receipt back — never a transcript.

→ drives delivery
skill

cairn

Preserves context between sessions in places that already own it — issue, PR, shelf, memory.

→ reads and updates both
compass prototype · ask · decide decision-shelf new · find · bridge records decisions relay brief → work → receipt delivery checks · receipt runs and drafts selected record, bridge → failing tests receipt + head → record's Bridge cairn pause / resume owned homes issue · PR · shelf · memory one marker, right home pause with proof, resume against live state
The loop: compass records a decision, the record becomes failing tests, relay delivers against them, the receipt lands back on the record. Cairn keeps it resumable at any point.

What the CLIs replace

Every row on the left used to be a written rule the model had to remember — and sometimes didn't. Now it's behavior built into a command. A rule you can't forget because it isn't a rule anymore.

The rule I used to writeWhat the tool does now
"Search the shelf first and resume the matching decision record instead of creating a duplicate."
decision-shelf new refuses to create a record when a matching one exists, and prints the one to resume.
"Keep the acceptance criteria in the decision doc in sync with the tests."
decision-shelf bridge generates failing tests straight from the record — one red test per criterion.
"Work out which checks this repo documents, run all of them, and never hide a skipped one."
delivery checks discovers them from package.json, Makefile, Cargo, or Go, runs each, and reports pass, fail, or blocked.
"Note which commit the test results came from, and re-verify if the branch moves."
delivery receipt stamps the exact head SHA on the evidence and prints a loud DIRTY flag for uncommitted work.
"Keep skills short. Don't let prose creep back in over time."
skills doctor audits every installed skill and flags any guide over 400 words.

Under the hood

Neither CLI is clever, and that's the point. Every command reads state that already exists — git, the repo's own config, the shelf — and turns it into one honest output. One row per command:

What it readsThe commandWhat you get
The git remote (which project is this?) and one decision question
decision-shelf new "…"
One HTML recordoutside every repo, outlives every session
A selected record's acceptance criteria
decision-shelf bridge
Failing tests, one per criterionthe spec, executable — red until each is truly met
package.json scripts · Makefile · Cargo.toml · go.mod
delivery checks
pass / fail / blockedevery documented check accounted for
Head SHA, branch, diff vs main, check results — live from git
delivery receipt
A closeout draft pinned to that commitDIRTY flag if the tree isn't committed
Every SKILL.md installed in any harness home
skills doctor
Advisories for any guide over 400 wordsthe thin set polices itself

The refusals, live

# the tools saying no is the whole point
$ decision-shelf new "Pick a queue library"
decision-shelf: a matching record already exists — resume it instead of duplicating

$ delivery checks
pass    npm test
fail    npm run lint

$ delivery receipt
# Receipt: TASK
- **Evidence:** pass — npm test, at head 93c0ce8… (DIRTY working tree)

Still on the shelf

The bundle isn't everything I run — it's the orchestration core. A handful of standalone utilities survived the prune because each earns its place: it triggers only when asked and does one job.

utility

repo-triage

What's next, what's blocked, what's dirty — across repos, branches, and worktrees, without implementing anything.

utility

skill-maintenance

Audits, archives, and restores skills reversibly. It's what carried out the prune itself.

utility

tdd

Red-green-refactor discipline on demand — the natural partner for the failing tests that bridge generates.

utility

debug-tools

Diagnoses agent workflow failures: unwanted tool calls, stale input, missing proof, slow steps.

utility

chronicle

Recent screen history, on explicit request — context for "what was I just looking at."

Everything redundant went to a dated archive, one mv away from restoration: three security checklists, UI style packs, and browser manuals whose knowledge the connected tools already carry.

One bundle, every harness

The whole set lives in a single marker-backed bundle that the installer symlinks into each harness's skill home. One copy to maintain, zero drift, and the shelf and receipts live outside every repo — so a Codex session picks up exactly where a Claude Code session left off.

~/.agents/orchestration-skills one marker-backed bundle ~/.claude/skills Claude Code $CODEX_HOME/skills Codex ~/.agents/skills any future harness symlinks — install · doctor · uninstall

By the numbers

3skills, down from 5
2CLIs carry the mechanics
811words of skill prose, total
<400words per skill, test-enforced
46tests, all green
1bundle for every harness

Built July 2026 · @dylanmccavitt/skills v3 · guided by the Claude 5 context-engineering shift from rules to judgment: fewer instructions, better interfaces, progressive disclosure.