ronniepinnellronniepinnell/casper/skills/judgment/SKILL.md

judgment

Skill1 starsChanged 4 months agoMITView on GitHub

Index and installer for the judgment toolkit — six procedure skills (/refute /door /gate /drift /altitude /premortem) and three mechanical hooks (claim-evidence, spec-citation, scope-creep) that bank frontier-model judgment as forced procedure any model can run. Use to see the toolkit, pick the right tool, or install the hooks into a project.

1 other project uses a version of this.

Adopted by

Most recently taken up by

Kamicyus/skill-forgetheir own version, first seen Jul 8, 2026

Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
Kamicyus/skill-forge★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository16 other files it gives its agents.
- altitudeSkill
- audit-skillsSkill
- backfillSkill
- calibrateSkill
- doorSkill
- driftSkill
- escalateSkill
- fix-poolSkill
- gateSkill
- merge-trainSkill
- precedentSkill
- premortemSkill
- refuteSkill
- sweepSkill
- thinkSkill
- verdictSkill

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 3 are distinctive, and 4 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
If your workflow has its own lifecycle commands (planning, task, commit), wire these tools in at the matching moments — the weave below …
line 44
Very specific:
Create .claude/judgment.json from hooks/judgment/judgment.json.example, set enabled: true per gate, list the project's protected globs.
line 66
Very specific:
Add the three entries to the project's .claude/settings.json hooks block (exact JSON is in each script's header comment).
line 68
Very specific:
Add .claude/.judgment-state/ and .claude/.spec-cited to .gitignore.
line 70
Very specific:
All three hooks are inert without .claude/judgment.json — safe to ship in shared config.
line 72
Distinctive:
Don't stack ceremony: most moments need exactly one of these, and two-way-door decisions need none.
line 78
Distinctive:
Every skill in the map above — /judgment is the index and router.
line 94

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

/judgment — The Toolkit Map

Capability doesn't transfer between models via vibes or prompt phrasing. It transfers via forced procedure (skills) and mechanical gates (hooks). This toolkit is the accumulated correction history made executable: every time a model burns you, the fix lands here, and every project inherits it.

The map

Command	One-liner	Reach for it when…
`/refute`	Try to break the claim before believing it	anything is declared done/fixed/working
`/door`	Reversible? pick fast. Irreversible? enumerate lock-in	schema, IDs, contracts, stack picks, naming
`/gate`	No plan without a numeric abort condition	plan time; long work; "is this good enough?"
`/drift`	Spec vs code-as-built — which one is lying?	surprises; before building on a spec
`/altitude`	Fix at the cause's layer, not the symptom's	any bug; especially recurring bugs
`/premortem`	It already failed — write the report first	before locking designs, launches, migrations
`/think`	Forced thinking moves (invert, second-order, base-rate…)	stuck, or the answer came too easily
`/verdict`	Append-only judgment ledger	any verdict worth remembering
`/calibrate`	Score how past confidence aged	monthly / milestone close
`/escalate`	Queue the hard call, ship the rest; `burn` to adjudicate	one-way door w/o precedent; borderline gate; spec-vs-code standoff
`/precedent`	Grep prior rulings: follow or explicitly distinguish	before any /door call or decision in a ruled-on domain
`/sweep`	Massive audit fan-out → verify → graded synthesis	"audit everything" moments

Hooks (zero-LLM, fire mechanically — see hooks/judgment/):

Hook	Event	Catches
`claim-evidence.sh`	PreToolUse:Bash	done-claims in commits with no test/evidence
`spec-citation.sh`	PreToolUse:Edit\|Write	protected-path edits without citing the spec
`scope-creep.sh`	PostToolUse:Edit\|Write	file-touch count exploding past stated task

Deep docs: MANUAL.md at the repo root (thesis, authoring guide, skill-vs-hook decision tree) and per-field checklists in domains/: stats · ml-cv · code · process. If your workflow has its own lifecycle commands (planning, task, commit), wire these tools in at the matching moments — the weave below shows where.

The standard lifecycle weave

PLAN     /door on the big choices → /premortem the plan → /gate the risks
BUILD    spec-citation + scope-creep hooks run silently in the background
FIX      /altitude before writing the fix
VERIFY   /refute the claim → /gate check → claim-evidence hook enforces at commit
AUDIT    /drift sweeps, periodically or when surprised

Chain rule of thumb: door → premortem → gate going in; altitude → refute coming out. /drift is the standing audit between them.

/judgment install

To wire the hooks into the current project:

Copy hooks/judgment/*.sh into the project (or reference them from the shared checkout) and chmod +x.
Create .claude/judgment.json from hooks/judgment/judgment.json.example, set enabled: true per gate, list the project's protected globs.
Add the three entries to the project's .claude/settings.json hooks block (exact JSON is in each script's header comment).
Add .claude/.judgment-state/ and .claude/.spec-cited to .gitignore.

All three hooks are inert without .claude/judgment.json — safe to ship in shared config; each project opts in.

Routing (`/judgment <situation>`)

Given a described situation, name the ONE tool that fits and invoke it. Don't stack ceremony: most moments need exactly one of these, and two-way-door decisions need none.

Install extras

Ledger merge driver — .claude/verdicts.log is append-only and conflicts trivially; make git auto-union it:
```
echo ".claude/verdicts.log merge=union" >> .gitattributes
```
Calibration cadence — schedule /calibrate monthly (cron/routine or a recurring ticket). Corrections it produces must land back in your config (domain line, gate default, demotion) — see MANUAL.md §6.

Composes with

Every skill in the map above — /judgment is the index and router; each companion skill's own "Composes with" section wires it to its neighbors.
The root MANUAL.md (the one deep doc for this toolkit) — the discovery entry point into this family.

Download now (ZIP)

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

What did you use it for? e.g. Reviewing pull requests in a Rails app

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.

Check your setup, free