A set of 34 skills for Claude Code, built for enterprise codebases. The idea behind it: autonomy does not come from better implementation prompts, it comes from moving the human decision out of the middle and to the edges - spec and acceptance criteria before, review and an evidence package after, and a ledger instead of a question in between. Because a question raised mid-implementation has exactly two causes: missing context, or a spec that was already undecided. Four of the rules install as hooks, which makes them enforced rather than requested.
The problem
An agent that asks mid-implementation costs more than the answer is worth: the run stops, and the human has to think their way back into a context they left two hours ago. Look at the questions one by one and they always have the same two causes. Either the agent does not know how this repository does things, or the question was already open in the spec and merely got passed along.
Both can be settled beforehand, but not with longer prompts. It takes artifacts: a map of the repository with the commands that actually apply there, a spec with acceptance criteria and a blast radius, and a place for a decision the agent makes on its own.
The uncomfortable part is enforcement. A rule that sits in the context window as prose is a suggestion, and compliance drops as the session gets longer, which is precisely the condition unattended work creates.
Constraints
Every skill description is loaded in every turn: the set has a context budget
No assumption about repository layout, from NX down to a single package
Hooks and permissions belong in the target repository, because they check its blast radius
No dependency on outside plugins that can change underneath you
Decisions
A ledger instead of a question
The agent decides and writes down the decision, the alternative, the reason and the reversal cost
Stopping to ask, the way you would expect of a careful colleague
Asking is only polite when somebody is there. At night it is an abort. So the decision goes into `docs/specs/<id>.assumptions.md` and the run continues; the list gets checked at review, where checking is cheap. The part that matters is the reversal cost on every entry: it tells the human which decisions they actually have to look at and which they can flip with one sentence.
Hooks instead of prose
Four rules as installable hooks, per target repository
Describing the rules in the skills and trusting them
The rules that hurt during unattended work are exactly the ones a model softens under pressure: touch nothing outside the blast radius, take no shortcut that fakes a green gate, make no claim without evidence. As a hook, the harness checks that instead of the model. Installation is per repository rather than global, because a hook has to know this repository's blast radius; the bundled allowlist lets a run get through without switching permissions off altogether.
One place for the shared rules
Everything shared lives in `agentic-guardrails`, and the others reference it by name
Each skill carrying the rules it needs itself
With 34 skills, a copied rule is a rule that drifts into 34 versions, and eventually the agent reads two contradictory sentences about the same thing. The second reason is the context budget: the model-invoked descriptions are loaded in every turn, about 8.4 KB together. What is written once costs once.
Read the commands instead of guessing them
`repo-cartograph` writes workspace kind, gates, boundaries and the changed-set command into a map
Assuming a layout and trying `npm test`
A guessed gate command is worse than none: it runs, it is green, and it checked something other than what the run touched. So the map is surveyed once and read by everyone else: NX, Turborepo, pnpm, npm and yarn workspaces, Lerna, Rush, single package, polyrepo, Maven, Gradle, .NET, Go, Cargo. Where there is no affected tooling, a ladder takes over, from `git diff` through manifest attribution to "a root config change runs everything". With a frontend and a backend, each repository gets its own map, and the connection between them is recorded as a seam.
A postmortem after every interruption
`autonomy-postmortem` takes every interruption apart and adds one line to the trend
Answering the question and moving on
Without that step the set stays as autonomous as it was on the day it was installed. With it, every interruption permanently removes a whole class of interruptions, because the cause moves to where it belongs: missing context into the repo map or the glossary, an undecided spec into the template the next one is written from.
What I built
Three primitives in exactly one place: assumption ledger, repair budget, evidence
Four rules as hooks, because prose in the context window is only a suggestion
repo-cartograph detects the workspace kind and writes gates and boundaries into a map every other skill reads
The morning review: a board for the overview, the intervention in conversation
