finding-to-audit

name	finding-to-audit
description	Promote a review finding into a pre-commit audit rule that catches the diff-inspectable issue class (import direction, pub widening, debug artifacts, dropped FFI output). Companion to bug-to-contract.

Finding-to-Audit

A single fix prevents one bug. An audit rule prevents the entire class without waiting for the next bug to surface.

Inputs

Input	What to collect
Review findings	Actionable findings that resulted in code changes — the reviewer's framing of the issue
Fix commits	Branch commits whose subject signals a fix: git log main..HEAD --oneline --grep="fix" -i, then git show <sha>

Procedure

1. Collect signals

For each finding or fix, note what the issue was and what changed.

2. Classify

Would a structured inspection of the diff have caught it?

• Yes → continue here.
• No, only runtime testing would → switch to bug-to-contract.

Examples that fit this skill:

• Import direction violation (lower module imports from higher)
• pub exposed beyond what the architectural rule allows
• Missing standard trait impl on a public type (e.g. Display, std::error::Error, Send/Sync on a public error)
• New behavior added but no test reads its outputs
• Hardcoded constant that should be a parameter
• Debug artifact (dbg!, trace println!, commented-out code)
• FFI output channel silently dropped
• Public enum without #[non_exhaustive] where future variants are expected

3. Identify the host audit skill

Concern	Host
General code-quality / pre-commit checklist	done-check (add a section, or extend an existing one)
FFI safe-wrapper rules	rust-ffi-rule (or language-specific equivalent)
Other domain-specific audit	The matching skill

If no host fits, scaffold a new audit skill rather than forcing the rule into an unrelated one.

4. Draft the rule

Use the host's existing format. For done-check:

### N. <Item name>

<rule description: what to check, in 1–2 sentences>

**Concern conditions:**

- <specific diff-inspectable signal>
- ...

**N/A:** <when the rule does not apply>

The rule must be diff-inspectable — verifiable against git diff output, file paths, or grep, without running the code. If the check requires execution, it belongs in bug-to-contract.

5. Edit the host skill

Add the rule directly. Renumber if needed and update any output tables in the host file.

6. Backfill check

If the same issue class has surfaced more than once historically, strengthen the rule (tighter conditions, additional concern signals) rather than relying on a single occurrence.

Principles

• General over specific. The rule catches the bug class, not the reviewer's exact wording.
• Diff-inspectable only. Anything requiring code execution belongs in bug-to-contract.
• Extend before adding. Strengthening an existing audit item is preferable to creating a new section unless the topic is orthogonal to all existing items.