Audit Decisions
Audit the decisions an implementing agent made, not its diff, a pure audit that traces...
Install
npx skills add dzhng/skills --skill audit-decisions -g -a claude-code -y- Repository
- dzhng/skills1.4k
- Category
- AI and agents
- Updated
- 3d ago
- License
- MIT
- Context cost
- Mediumabout 2,401 tokens
- Runs scripts
- No, instructions only
What it does
Audit the decisions an implementing agent made, not its diff, a pure audit that traces the session's history into a decisions ledger, changes no code, and never blocks an unsupervised run. Working code still embeds architecture the user never chose; surface it because future work inherits it. Use when the user wants to review the decisions the AI made on their behalf, before merging or committing AI-implemented work, when integrating a delegated subagent's pass, or when a fix "works" but might be a point fix.
Audit Decisions
Given a good decision, an agent implements it faithfully; wherever the task is underspecified, it makes the decision itself, silently, and the diff won't flag it. Reviewing thousands of changed lines doesn't scale, and it inspects the execution, which was probably fine. The audit that scales is of the decisions: surface every one the implementer made on its own, judge that list, and record the verdicts.
This is about architecture more than bugs. An implementation can work perfectly and still rest on decisions the user never made, a data shape, a storage location, a dependency, an API contract, a tradeoff of memory for speed, and every one of them is load-bearing for future work. The user needs to know them not because they're wrong, but because they now own them.
This is purely an audit, it is not about modifying code, and it can be called at any time. The job is to trace back: walk every step this session has taken, and every step each subagent took (a live implementer traces its own; otherwise reconstruct from its reports, transcripts, and diffs), and surface every single decision that was made on the user's behalf that was not in the original spec or prompt. The ledger of those decisions replaces reading the code as the user's review surface, that is the whole point. Acting on the verdicts (redoing an unsound decision, applying a provisional call) belongs to the caller: the implementing workflow mid-run, or the user after reading the report.
Two ways in, same audit:
- Called by a workflow (per pass or per slice): audit that pass, append its entries to the ledger, and return; the workflow presents the accumulated ledger when it hands back.
- Called directly by the user: audit the whole body of work in front of you (session, branch, or named change) and present the report immediately. Recommend; change nothing.
