decision-audit
Skill9 starsChanged 3 months agoMITView on GitHub
Post-build decision ledger and pride gate: list meaningful agent choices and assumptions after work has landed, with why, alternatives, and confidence; flag debt and edge cases; do not change code until the user says revise now. Use when the user invokes /decision-audit or asks for a post-execution decision audit or choice autopsy.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- Haple/system-onetheir own version, first seen Oct 20, 2026
- gnurio/nurijanian-skillstheir own version, first seen Apr 20, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- gnurio/nurijanian-skills★ 112same name
- Haple/system-one★ 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 repository43 other files it gives its agents.
- accessibility-auditSkill
- add-documentationSkill
- add-error-handlingSkill
- address-github-pr-commentsSkill
- agent-risk-reviewSkill
- agent-work-receiptSkill
- automation-roi-auditSkill
- blind-spot-passSkill
- code-reviewSkill
- commit-changes-mainSkill
- commit-same-branchSkill
- commitSkill
- create-pr-mainSkill
- debug-issueSkill
- define-agent-goalSkill
- design-agent-loopSkill
- fix-compile-errorsSkill
- fix-git-issuesSkill
- gauntlet-loopSkill
- generate-api-docsSkill
- generate-pr-descriptionSkill
- git-sync-workspaceSkill
- instruction-ablationSkill
- light-review-existing-diffsSkill
- lint-fixSkill
- lint-suiteSkill
- merge-open-prsSkill
- optimize-performanceSkill
- pathfinderSkill
- prompt-eval-debugSkill
- refactor-codeSkill
- requirement-to-implementationSkill
- run-all-tests-and-fixSkill
- scoped-auditSkill
- security-auditSkill
- seo-auditSkill
- setup-new-featureSkill
- structure-promptSkill
- tddSkill
- thermo-nuclear-code-quality-reviewSkill
- update-memory-bankSkill
- update-readmeSkill
- write-unit-testsSkill
The file
We split this skill into the rules it gives an agent
12 rules. About 0 are common, 12 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈12
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 28
Run phases in order. Do not publish the ledger until evidence is gathered.
- Distinctive: line 33
If no scope hint, default to the full session or current branch when a repo is present.
- Distinctive: line 34
If the user invokes mid-task with no finished work yet, say so and stop or ask whether to wait.
- Distinctive: line 42
Files: only artifacts in scope that still reflect the chosen design
- Distinctive: line 44
Do not invent decisions that have no support in conversation or diff.
- Distinctive: line 60
Keep the ledger short enough to review.
- Distinctive: line 70
Do not invent facts. If nothing is known, say so explicitly.
- Distinctive: line 74
Ask the human two explicit yes/no questions.
- Distinctive: line 87
Do not start edits, commits, destructive git, or PR creation in this turn.
- Distinctive: line 121
No secrets, tokens, PII, or PHI in the ledger body.
- Distinctive: line 122
Do not invent decisions or debt without evidence.
- Distinctive: line 136
Always ask the pride gate: Ask whether the human is proud of the branch and would stand behind it in production.
≈ “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
Decision audit
Role
You produce a post-execution decision ledger for work already completed in scope. You surface meaningful choices and assumptions the agent made, not a line-by-line code review. You end with a pride gate and a halt: do not change code, commit, or open a PR in the same turn. Ledger approval is not revise permission; wait for revise now (with targets).
When to use
Use when the user invokes /decision-audit, asks for a decision audit, choice ledger, or pride gate after a build, or wants a judgment autopsy of what the agent chose. For productivity and value accounting, use agent-work-receipt. For diff quality before approve, use code-review or light-review-existing-diffs. For pre-build assumption surfacing, use blind-spot-pass or define-agent-goal.
Audit charter
Audit judgment after the agent has already chosen. List meaningful decisions only. Do not invent choices without evidence. Do not change code until revise now.
Workflow
Run phases in order. Do not publish the ledger until evidence is gathered. Do not revise code in this turn.
Phase 0: Intake
- Parse a scope hint from the user message (e.g. "decision audit for the auth refactor on branch-1").
- If no scope hint, default to the full session or current branch when a repo is present.
- If the user invokes mid-task with no finished work yet, say so and stop or ask whether to wait. Do not hallucinate a ledger of completed decisions.
Phase 1: Evidence
Gather read-only evidence:
- Conversation: what the user asked for, what the agent chose, what was rejected or deferred
- Git (when a repo is present):
git status,git diff,git logto ground landed choices - Files: only artifacts in scope that still reflect the chosen design
Do not invent decisions that have no support in conversation or diff. Prefer "none recorded" for alternatives when the session never considered them.
Phase 2: Ledger
List meaningful choices only. Include architecture, API shape, library picks, error-handling strategy, naming that locks an API, skipped tests, deferred work, and similar judgment calls. Skip trivial formatting noise and mechanical renames unless they lock a public contract.
For each choice, populate:
| Field | Content |
| Decision | What was chosen |
| Why | Short rationale grounded in evidence |
| Alternatives | What else was considered, or none recorded |
| Confidence | high / med / low |
| Locality | example-local (fits this case only) or generalizable |
Keep the ledger short enough to review. Prefer fewer high-leverage rows over a dump of every micro-choice.
Phase 3: Debt and edges
From the same evidence, list:
- Known debt tied to the choices (TODOs left in, shortcuts, missing tests)
- Unhandled edge cases the choices imply
- Blast notes (what else might break or need follow-up if these choices stand)
Do not invent facts. If nothing is known, say so explicitly.
Phase 4: Pride gate
Ask the human two explicit yes/no questions. Do not soft-sell ship readiness:
- Are you proud of this branch (or scoped work)?
- Would you stand behind it in production as it is?
Record that answers are for the human; do not answer for them.
Phase 5: Halt
End with this handshake (adapt wording only if needed; keep the meaning):
Approve or edit this ledger before I revise. Ledger approval is not revise permission. Say revise now (with targets) to change code.
Do not start edits, commits, destructive git, or PR creation in this turn. If the user says "just fix it" without revise now, stay on the audit contract and remind them of the halt phrase.
Deliverable template
# Decision audit
## 1. Decision ledger
| Decision | Why | Alternatives | Confidence | Locality |
|----------|-----|--------------|------------|----------|
| ... | ... | none recorded / ... | high/med/low | example-local / generalizable |
## 2. Debt and edge cases
- Known debt: ...
- Unhandled edges: ...
- Blast notes: ...
## 3. Pride gate
1. Proud of this branch / scoped work? (yes/no for the human)
2. Stand behind it in production as it is? (yes/no for the human)
## 4. Halt
Approve or edit this ledger before I revise. Ledger approval is not revise permission. Say **revise now** (with targets) to change code.Populate every section. Prefer a compact table or short bullets over vague prose.
Safety
- Audit only: no new implementation, commits, PR creation, or destructive commands unless the user explicitly says revise now (with targets) in a follow-up that authorizes changes.
- No secrets, tokens, PII, or PHI in the ledger body; redact if present in context.
- Do not invent decisions or debt without evidence.
Distinction from other commands
agent-work-receipt: productivity, time estimates, and value tiers after a session. This skill audits judgment (choices, confidence, pride gate), not output accounting.code-review/light-review-existing-diffs: diff quality and approve/reject signals. This skill is a choice autopsy, not a line-by-line review.blind-spot-pass: pre-build four-quadrant fog map of the ask. This skill runs after execution.define-agent-goal: forward six-part Goal before autonomous work. This skill is backward decision review after work.
Guardrails
- Ledger of choices, not a line-by-line review. List meaningful choices (architecture, API shape, libraries, deferred work) with why, alternatives, and confidence.
- Stay audit-only until revise now. Deliver the audit and wait for an explicit revise now (with targets).
- Ground decisions in evidence. Cite session or git evidence, or mark confidence low / none recorded.
- Always ask the pride gate. Ask whether the human is proud of the branch and would stand behind it in production.
- Stop when nothing has landed. State nothing finished, stop or ask whether to wait; do not hallucinate a ledger.
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.

