ai-instructions: Skill for Cursor

AI Customization Audit

Arguments

• Required: file, file list, folder, or glob to audit.
• Optional for single-file scopes: explicit review-ledger path.

1. Scope and Analysis

1. Review only the user-provided scope. If it is missing, stop and request it.
2. Resolve the style contract in this order: workspace .github/instructions/ai-customization.instructions.md, then the applicable user-level contract supplied by the environment. If neither exists, stop and report the missing prerequisite.
3. Load and apply the resolved style contract.
4. Resolve the supplied scope to files. Require at least one readable target file; otherwise report the scope as invalid and return BLOCKED.
5. Identify active references among the files in scope.

2. Review State and Convergence

1. Load the review ledger before scanning when it exists.
2. For a single-file scope, use <file>.review-ledger.md as the default ledger path. An explicit ledger path takes precedence over the default path. Validate and use the selected path consistently for loading, reporting, creation approval, and updates. If it does not exist, report it as not initialized and do not silently fall back to another path. If an existing ledger is unreadable or does not contain the required fields, report Review ledger: invalid with the path and reason, return BLOCKED, and do not scan or modify the target file.
3. For a folder or glob, review each resolved file independently and use <file>.review-ledger.md beside each file as its deterministic ledger path. Do not require one shared folder ledger or an explicit ledger path.
4. If the resolved ledger does not exist, report Review ledger: not initialized and continue the current scan. Do not create an empty ledger.
5. Assign each new finding the next unused severity number in the applicable ledger or current report. Treat every new finding as PROVISIONAL until its ID and required fields are written to the ledger; only then mark its ID state LEDGER. Preserve provisional IDs when the ledger is approved and created unless they conflict with existing entries.
6. Assign each finding a stable fingerprint based on canonical file identity, category, and normalized substantive problem. Do not include line location in the fingerprint.
7. When a ledger exists, assign each new finding the next unused number for its severity in that ledger. Reuse the ledger ID when the same fingerprint appears again. Do not call a new finding immutable or LEDGER until the ledger update is complete. Sort findings for display independently of their IDs.
8. Without a ledger, do not infer FIXED, ACCEPTED, or REJECTED status from conversation history, diffs, or filenames. Treat the review as having no persisted finding history.
9. Mark findings as OPEN, FIXED, ACCEPTED, or REJECTED.
10. Do not report FIXED, ACCEPTED, or REJECTED findings again unless the relevant content snapshot, referenced instruction, or applicable scope has materially changed.
11. When a resolved finding materially changes, retain its fingerprint and ID, mark it OPEN, store the new snapshot, and append the transition to its resolution history.
12. A wording preference, optional rewrite, or alternative style is not a finding.
13. When no new or unresolved substantive findings remain, report Findings: none and return READY.
14. When no ledger exists, state that current findings are clean only for this scan; do not claim that previous findings were resolved. If the scan has no findings, leave the ledger uncreated.
15. Update the target files only after explicit user confirmation.
16. When the user approves target-file fixes, create or update each affected file's adjacent ledger in the same operation and record the approved findings as FIXED, unless the user explicitly excludes ledger changes.
17. Create or update the ledger only after explicit user confirmation when a finding is explicitly accepted or rejected without changing the target file. Do not create a ledger for a clean scan.
18. Store at least the finding ID, fingerprint, file path, category, status, content snapshot or revision, and resolution note in the ledger. A valid ledger must be readable and contain those fields for every finding.