refactor(claude): clean up audit prose style

.claude/skills/audit/SKILL.md

@@ -17,7 +17,7 @@ description: Run a deep, multi-lens review of existing code state (not a diff).
 /audit src/foo/ --lenses docs,tests # both scope and lenses
 ```
 
-If the user invokes `/audit` with no arguments, infer the primary source tree from the project layout (Rust: `crates/*/src/`; TS/JS: `src/` or `packages/*/src/`; Python: the package directory). Ask briefly only if ambiguous.
+If the user invokes `/audit` with no arguments, infer the primary source tree from the project layout (`crates/*/src/` for Rust, `src/` or `packages/*/src/` for TS/JS, the package directory for Python). Ask briefly only if ambiguous.
 
 ## Communicating with the user
 
@@ -36,29 +36,29 @@ All three pieces of context get fed into every agent prompt so they respect the
 
 ## Phase 2: Launch lens agents in parallel
 
-Send a single message with multiple `Agent` tool uses, each `subagent_type: general-purpose`. The default set is six lenses; if `--lenses <list>` was given, run only those (plus any opt-in lenses named in the list).
+Send a single message with multiple `Agent` tool uses, each `subagent_type: general-purpose`. The default set is six lenses. If `--lenses <list>` was given, run only those (plus any opt-in lenses named in the list).
 
 ### Model selection per lens
 
-The `Agent` tool accepts a `model: "sonnet" | "opus" | "haiku"` parameter. Pick deliberately - some lenses are pattern-matching (cheap), others are reasoning-heavy (expensive but worth it).
+The `Agent` tool accepts a `model: "sonnet" | "opus" | "haiku"` parameter. Pick deliberately, since some lenses are pattern-matching (cheap) and others are reasoning-heavy (expensive but worth it).
 
 | lens              | model    | why                                                                   |
 | ----------------- | -------- | --------------------------------------------------------------------- |
 | reuse             | sonnet   | pattern recognition across files, fits sonnet's strengths             |
-| quality           | sonnet   | structural critique, naming, dead code; sonnet is enough              |
+| quality           | sonnet   | structural critique, naming, dead code, sonnet is enough              |
 | efficiency        | **opus** | needs reasoning about hot paths, allocations, asymptotic patterns     |
 | errors            | **opus** | control-flow analysis, silent-failure detection wants careful reading |
-| api               | sonnet   | visibility analysis, type design - mostly mechanical                  |
+| api               | sonnet   | visibility analysis, type design, mostly mechanical                   |
 | bugs              | **opus** | correctness reasoning is the place not to skimp                       |
-| docs (opt-in)     | haiku    | "does the comment still match the code?" - cheap                      |
+| docs (opt-in)     | haiku    | "does the comment still match the code?", cheap                       |
 | tests (opt-in)    | sonnet   | gap analysis with semantic context                                    |
 | security (opt-in) | **opus** | high-stakes correctness, needs careful reading                        |
 | a11y (opt-in)     | sonnet   | pattern matching with semantic context                                |
 | deps (opt-in)     | haiku    | mostly file scanning                                                  |
 
-The validation agent in Phase 3 also runs on **opus** - false negatives drop real findings, so this is the wrong place to economize.
+The validation agent in Phase 3 also runs on **opus**: false negatives drop real findings, so this is the wrong place to economize.
 
-These are defaults; if a project's lens is unusually subtle (e.g. obscure embedded language, novel runtime), bump up.
+These are defaults. If a project's lens is unusually subtle (e.g. obscure embedded language, novel runtime), bump up.
 
 ### Default lenses
 
@@ -80,11 +80,11 @@ Duplicated logic, reinvented std / framework primitives, inline patterns that ma
 
 #### quality
 
-Structural and maintainability issues: redundant state (fields that duplicate each other, derived values cached unnecessarily, bools that encode the same thing as an adjacent enum), leaky abstractions (pub(crate) fields poked directly when a method would be cleaner), stringly-typed code, parameter sprawl, unnecessary comments (especially WHAT-not-WHY narration, section dividers, PR/commit/task references in code), nested conditionals 3+ levels deep that could flatten, dead code, brittle test fixtures. Skip anything a linter/formatter would catch - the gate handles those.
+Structural and maintainability issues: redundant state (fields that duplicate each other, derived values cached unnecessarily, bools that encode the same thing as an adjacent enum), leaky abstractions (pub(crate) fields poked directly when a method would be cleaner), stringly-typed code, parameter sprawl, unnecessary comments (especially WHAT-not-WHY narration, section dividers, PR/commit/task references in code), nested conditionals 3+ levels deep that could flatten, dead code, brittle test fixtures. Skip anything a linter/formatter would catch, since the gate handles those.
 
 #### efficiency
 
-Hot-path bloat (anything that runs per-frame / per-event / per-request / per-render): redundant allocations, repeated hashmap lookups, multiple tree walks where one would do, reconstructing immutable objects every call. Recurring no-op updates (state writes that trigger downstream invalidation even when the value didn't change). Unbounded growth in caches or maps. Overly broad operations (scanning entire collections to find one thing). Note "hot path" context per project - for GUI/game code it's paint/layout/event loops; for servers it's request handlers; for data pipelines it's per-record transforms.
+Hot-path bloat (anything that runs per-frame / per-event / per-request / per-render): redundant allocations, repeated hashmap lookups, multiple tree walks where one would do, reconstructing immutable objects every call. Recurring no-op updates (state writes that trigger downstream invalidation even when the value didn't change). Unbounded growth in caches or maps. Overly broad operations (scanning entire collections to find one thing). Note "hot path" context per project. For GUI/game code it's paint/layout/event loops. For servers it's request handlers. For data pipelines it's per-record transforms.
 
 #### errors
 
@@ -96,7 +96,7 @@ Public API surface appropriateness. `pub` on items that could be `pub(crate)` (c
 
 #### bugs
 
-Correctness issues: logic errors, off-by-one, missing bounds checks, wrong condition in if, incorrect loop termination, type confusion that compiles but is wrong, borrow patterns that compile but violate invariants (lifetimes too permissive / not permissive enough). Only flag with high confidence - "this might be wrong depending on inputs" is NOT a finding. Include language-specific bug profiles: Rust bugs often involve lifetimes/Send/Sync; JS/TS bugs often involve null/undefined, async Promise lifetimes, reference equality mistakes.
+Correctness issues: logic errors, off-by-one, missing bounds checks, wrong condition in if, incorrect loop termination, type confusion that compiles but is wrong, borrow patterns that compile but violate invariants (lifetimes too permissive / not permissive enough). Only flag with high confidence. "This might be wrong depending on inputs" is NOT a finding. Include language-specific bug profiles. Rust bugs often involve lifetimes/Send/Sync. JS/TS bugs often involve null/undefined, async Promise lifetimes, reference equality mistakes.
 
 ### Opt-in lenses
 
@@ -126,9 +126,9 @@ Dependency hygiene: duplicate deps at different versions, unused deps, feature f
 
 Once lens agents return, do NOT present findings to the user yet. Launch a single validation agent with all raw findings as input:
 
-> "Each finding below was flagged by a lens agent. For each one, confirm independently whether it's real by reading the referenced file(s) and the surrounding context. Classify each as: **confirmed** (high-confidence real issue), **misfire** (wrong reading of the code, semantics differ from what the agent thought), or **context-dependent** (real only under unstated assumptions - treat as misfire). Return the confirmed list, with the reasoning for any misfires you're dropping so the aggregator can double-check."
+> "Each finding below was flagged by a lens agent. For each one, confirm independently whether it's real by reading the referenced file(s) and the surrounding context. Classify each as: **confirmed** (high-confidence real issue), **misfire** (wrong reading of the code, semantics differ from what the agent thought), or **context-dependent** (real only under unstated assumptions, treat as misfire). Return the confirmed list, with the reasoning for any misfires you're dropping so the aggregator can double-check."
 
-This mirrors the confidence-scoring approach in Anthropic's `/code-review`. Misfires are noisy; validation keeps signal high.
+This mirrors the confidence-scoring approach in Anthropic's `/code-review`. Misfires are noisy. Validation keeps signal high.
 
 Skip validation only if the raw finding count is ≤3 and each one is obviously right (saves tokens when the audit turns up almost nothing).
 
@@ -136,10 +136,10 @@ Skip validation only if the raw finding count is ≤3 and each one is obviously
 
 Classify each confirmed finding into one of four tiers:
 
-- **Trivial fix** - small local change, clear improvement, no judgment call (e.g. "use existing helper at file.rs:42 instead of inline arithmetic").
+- **Trivial fix**: small local change, clear improvement, no judgment call (e.g. "use existing helper at file.rs:42 instead of inline arithmetic").
-- **Substantive fix** - real value, more than a few lines, clear scope (e.g. "merge two near-duplicate functions into one walker").
+- **Substantive fix**: real value, more than a few lines, clear scope (e.g. "merge two near-duplicate functions into one walker").
-- **Needs discussion** - chunky refactor, public API change, enum redesign, hot-path caching with lifetime gymnastics. Outcome shouldn't be assumed.
+- **Needs discussion**: chunky refactor, public API change, enum redesign, hot-path caching with lifetime gymnastics. Outcome shouldn't be assumed.
-- **Backlog item** - real but larger than cleanup. Should land in `TODO.md` (or equivalent) so it's not lost.
+- **Backlog item**: real but larger than cleanup. Should land in `TODO.md` (or equivalent) so it's not lost.
 
 This phase is **classification only**. Do NOT apply any fixes here, do NOT edit `TODO.md` here. Recording happens in the next phase, after the user has seen the proposed plan.
 
@@ -153,10 +153,10 @@ Before presenting anything, use `TaskCreate` to record one task per non-empty ti
 
 ### Tier order
 
-1. **Suggested backlog additions** - lock these in first. A single `TODO.md` append is cheap and ensures nothing is lost if a later code change goes sideways.
+1. **Suggested backlog additions**: lock these in first. A single `TODO.md` append is cheap and ensures nothing is lost if a later code change goes sideways.
-2. **Trivial fixes** - grouped by theme (e.g. "use existing helpers", "drop dead code"), one commit per theme.
+2. **Trivial fixes**: grouped by theme (e.g. "use existing helpers", "drop dead code"), one commit per theme.
-3. **Substantive fixes** - one commit per logical change. Commit message explains the why.
+3. **Substantive fixes**: one commit per logical change. Commit message explains the why.
-4. **Needs discussion** - present each as: issue, two options, tradeoff. Apply only if the user gives specific direction.
+4. **Needs discussion**: present each as: issue, two options, tradeoff. Apply only if the user gives specific direction.
 
 Skip any tier that has zero items.
 
@@ -179,8 +179,8 @@ Items are **numbered 1..N within the tier**, resetting each tier so the user can
 ```
 ### <Tier name> (<count>)
 
-1. file.rs:42 - <issue>. Fix: <one-line change>.
+1. file.rs:42, <issue>. Fix: <one-line change>.
-2. file.rs:88 - <issue>. Fix: <one-line change>.
+2. file.rs:88, <issue>. Fix: <one-line change>.
 3. ...
 
 Ready to apply? "Go ahead" for all, or tell me which numbers to skip.
@@ -191,7 +191,7 @@ For **Needs discussion**, expand each item:
 ```
 ### Needs discussion (<count>)
 
-1. file.rs:220 - <issue>.
+1. file.rs:220, <issue>.
    - Option a: <option>
    - Option b: <option>
    - Tradeoff: <one line>
@@ -233,11 +233,11 @@ After the final tier, give a brief summary: what was applied, what was backlogge
 - Stack findings from multiple lenses into one commit without clear grouping.
 - Invent findings to fill space if a lens comes up empty. "Nothing to flag" is a valid outcome and should be reported as such.
 - Re-raise items already in `TODO.md` / `BACKLOG.md`.
-- Run `/audit` against a codebase that was just audited - diminishing returns.
+- Run `/audit` against a codebase that was just audited (diminishing returns).
 
 ## Parallelism note
 
-All lens agents run in parallel (single message, multiple `Agent` tool uses). Six agents is the upper bound where parallelism still pays; above that, coordination overhead catches up. Keep opt-in lenses opt-in for this reason - running all 11 in parallel would be wasteful for most projects.
+All lens agents run in parallel (single message, multiple `Agent` tool uses). Six agents is the upper bound where parallelism still pays. Above that, coordination overhead catches up. Keep opt-in lenses opt-in for this reason. Running all 11 in parallel would be wasteful for most projects.
 
 ## When NOT to use this skill