/audit-rules

description: "Mine your distilled knowledge corpus — memory feedback rows, rules backlogs, always-on indexes — for recurring corrections that deserve promotion to numbered standing rules. Clusters by theme, verifies every quote at its source file, ranks by cross-session recurrence (>=2 distinct sessions), and writes a rule ONLY on explicit approval. Opt-in. Trigger: '/audit rules', 'mine my corrections', 'promote my rules', 'audit my rules'."
argument-hint: "[promote <labels>]"
allowed-tools: Read, Glob, Grep, Bash, Write, Edit

/audit rules — User-Rule Mining Sub-Audit

Canonical invocation: **`/audit rules`** (argument forms ride the umbrella too: `/audit rules promote R1 R3`). The direct `/audit-rules` form is retained for compatibility and is not advertised.

Mine the corpus your corrections have already accumulated in — memory `feedback_*` rows and their indexes, the rules backlog, staged `/audit style` output — for candidates that have earned promotion to numbered rules in `rules/user-rules.md`. This is a DEPTH pass on one shape (recurring user corrections → standing-rule candidates); `/audit knowledge` remains the breadth pass that dispositions everything. Evidence-gated end to end: a candidate that cannot show dated, at-source verified receipts across ≥2 distinct sessions does not get proposed, and nothing writes a rule except an explicit per-run approval naming the candidates.

Runtime Gate — Bash capability precondition

**Before Step 0:** check that the `Bash` tool is available. This skill needs it (corpus greps, the digest regeneration in Step 7). **No Cowork counterpart of this skill exists** — do not offer one. If Bash is NOT available, say so and ask: **"Stop here?"** (`y` / `n`)

• **`y` / no response** — exit cleanly; nothing scanned, nothing written.
• **`n`** — proceed in DEGRADED read-only mode: Steps 0–5 (analysis + report) using Read/Grep only,

and Step 7 (promotion mechanics) is unavailable — state that plainly in the report rather than reporting any promotion as done.

**Opt-in only, never cadence-fired:** like `/audit style` and `/audit usage`, this sub-audit runs only on explicit invocation. No SessionStart nudge, activity threshold, or cadence may fire it.

Step 0: Config + Harvest Surfaces

Read `~/.claude/aria-knowledge.local.md`; resolve `knowledge_folder`. If unconfigured, stop: "aria-knowledge is not configured. Run /setup to get started."

**If invoked as `promote <labels>`** (e.g. `/audit rules promote R1 R3`): skip harvest entirely. Resolve the labels from the **newest staged block** this skill previously wrote in `{knowledge_folder}/intake/rules-backlog.md` (Step 6's `stage` disposition persists candidates WITH their R-labels exactly so a later session can approve without re-harvesting). If no staged block exists, say so and offer a fresh run. On resolution, jump to Step 7 for the named candidates only.

Harvest surfaces, in priority order:

1. `{knowledge_folder}/rules/user-rules.md` — the existing rule set (dedupe + amendment target). 2. `{knowledge_folder}/intake/rules-backlog.md` — staged candidates, including `/audit style`'s receipt-gated output (that skill is this one's transcript-mining FEEDER; this skill never mines transcripts itself). 3. The user-memory directory for the current project (`~/.claude/projects/<cwd-encoded>/memory/`): `MEMORY.md` and the `feedback_*.md` topic files. 4. Any additional always-on index files that carry feedback rows — discovered by following the `@`-import chain from the project's CLAUDE.md lineage plus `[[link]]`/markdown-link references from `MEMORY.md` rows, **depth-bounded to 2 hops**. Anything deeper is out of harvest scope and the Step 5 scan-health section says so. Never a hardcoded path list — index layouts are user-specific. 5. `{knowledge_folder}/intake/insights-backlog.md` — **corroboration only, never a primary candidate source** (an insight alone is below the Step 4 bar until a second instance corroborates), and read only for entries newer than the boundary stamped in `{knowledge_folder}/logs/rule-audit-log.md` (created lazily; the boundary advances only on a stage/promote disposition, never on cancel).

Step 1: Harvest Correction Candidates

Scan the surfaces for the correction signature: a dated verbatim user quote attached to a behavioral instruction; a hard-prohibition clause ("NEVER…", "ALWAYS…") paired with an incident; a row naming two or more instances; a backlog entry typed as a rule candidate.

**Cluster by THEME, not by row.** Rows that cross-link each other or describe one behavior from different angles form ONE candidate (measured origin: the strongest candidate in this skill's reference run spanned three memory rows describing one turn-close behavior).

Step 2: Dedupe

Against `rules/user-rules.md` **by substance, not title** — a candidate duplicating an existing rule is DECLINED with that rule cited. Against the plugin-managed `working-rules.md` — duplicating a numbered universal rule is likewise a decline-with-citation. **Partial overlap yields the `amend` disposition**, naming the exact rule (or memory row) and clause it would amend.

Step 3: Verify at Source (the citation gate)

For every quote a candidate relies on, **open the topic file and confirm the quote and its date.** An index row's slug or one-line summary is never evidence — a slug is an address, not an assertion, and index rows go stale against their topic files. If a row and its topic file disagree, the candidate carries the topic file's version, flagged, and the disagreement itself is surfaced in the report.

Classify each candidate:

• **TRANSCRIPTION** — the user can be quoted saying it, verbatim and dated. Recordable with

attribution on approval.

• **DERIVED** — generalized from incidents rather than stated by the user. Its writeup MUST state a

falsifier the user can evaluate, and its approval framing says plainly that it is derived.

Step 4: Rank + t