risk-tiers
Skill0 starsChanged 43 days agoMITView on GitHub
Pick how much review a change needs by risk tier 0 to 4 (docs, feature code, schema or shared state, production data or irreversible actions, security surface). Use when asked how much review, testing or sign-off a change needs, or before merging anything that touches migrations, auth, deletes, publishing, spending or user data.
In this repository6 other files it gives its agents.
- templates/AGENTS.mdAGENTS.md
- failure-to-ruleSkill
- handoffSkill
- refute-reviewSkill
- release-gateSkill
- sprint-specSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 25
Do not audit a copy change like a migration.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Risk tiers
Verification depth matches risk. Classify by what the change can touch, not by how big it is. When a change spans tiers, the highest applies. When unsure, take the higher tier.
| Tier | Change | Required before merge | Human sign-off |
| 0 | Docs, copy, non-behavioral | Self-check, build and typecheck | Spot-check |
| 1 | Feature code: no schema, no production data | One independent refuting review, the lint gate, tests that ran (not skipped) | Integrator merges |
| 2 | Schema, persistent, shared or client-shipped state | Tier 1, plus a forward and rollback round trip on production-shaped data, a rehearsal against a copy of production, a committed rollback | Explicit yes before production |
| 3 | Production data writes, destructive actions, publishing, spending | Tier 2, plus the exact command or diff, a logged read-only count of what it touches, a known recovery path | Per-change approval by the human, never delegated |
| 4 | Security surface: auth, uploads, callbacks, parsing, permissions, privacy | The change's own tier, plus a review briefed with a threat model | Security review |
How to classify
- List what the change can touch: files, schema, stored data, shared state, credentials, users, money, published artifacts.
- Take the highest matching tier. A "small dry run" that writes one row is a write.
- Add your domain's top-risk row. Library or SDK: a public API break is Tier 3. Research or ML: a change that affects evaluation gates on a metric threshold on held-out data. Client-shipped state has no rollback after ship, so go forward-only, keep a kill switch, and treat it as Tier 2 at least.
- Re-tier when scope grows. Record the tier and the reason in the spec.
Rules
- Do not audit a copy change like a migration. Never ship a production-data change on one pass.
- Reviewers get capability that matches the tier: the strongest model and higher effort for Tier 2 and up, security, and ambiguous cross-cutting work, cheaper models for mechanical work.
- Tier 3 approval is per change and never delegated: show the exact command or diff and the read-only count of what it touches.
- To run the review, use the
refute-reviewskill or/agent-operating-kit:refute.
Answer as: "Tier N because <what it can touch>. Required: <checks>. Sign-off: <who>."
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.