fix : ai slop

.agents/skills/scrutinize/SKILL.md

@@ -17,17 +17,17 @@ Stand outside the change and ask whether it should exist at all, then verify it
 
 Run these in order. Do not skip ahead.
 
-### 1. Intent — what is this actually trying to do?
+### 1. Intent - what is this actually trying to do?
 
-- State the goal in one sentence, in your own words. If you cannot, the artifact is underspecified — say so and stop.
+- State the goal in one sentence, in your own words. If you cannot, the artifact is underspecified - say so and stop.
 - Ask: **is there a simpler, smaller, or more elegant way to achieve the same goal?** Consider:
   - Doing nothing (is the problem real / load-bearing?).
   - Using something that already exists in the codebase instead of adding new surface.
   - A smaller change that solves 90% of the goal with 10% of the risk.
   - Solving it at a different layer (config vs code, framework vs app, build vs runtime).
-- If a better alternative exists, name it explicitly with rationale. This is the most valuable thing you can output — surface it before the line-by-line review.
+- If a better alternative exists, name it explicitly with rationale. This is the most valuable thing you can output - surface it before the line-by-line review.
 
-### 2. Trace — walk the actual code path
+### 2. Trace - walk the actual code path
 
 - For each behavior the change claims, trace the path end-to-end through the real code, not just the lines in the diff:
   - Entry point → call sites → branches taken → state mutated → exit / return / side effect.
@@ -35,7 +35,7 @@ Run these in order. Do not skip ahead.
 - For a plan or design doc: trace the proposed flow against the existing system. Where does it touch reality? What does it assume that isn't true?
 - Note every place the trace surprises you (unexpected branch, dead code reached, state you didn't know existed). Surprises are signal.
 
-### 3. Verify — does it actually do what it claims?
+### 3. Verify - does it actually do what it claims?
 
 For each claim the change/plan makes, answer:
 
@@ -48,18 +48,18 @@ For each claim the change/plan makes, answer:
 
 Output one tight section per finding. Order by severity (blocker → major → nit). For each:
 
-- **Finding** — one sentence, specific. Cite `file:line` when applicable.
-- **Why it matters** — the consequence, not the principle.
-- **Evidence** — the trace step or input that exposes it.
-- **Suggested change** — concrete, minimal.
+- **Finding** - one sentence, specific. Cite `file:line` when applicable.
+- **Why it matters** - the consequence, not the principle.
+- **Evidence** - the trace step or input that exposes it.
+- **Suggested change** - concrete, minimal.
 
-Close with a one-line verdict: ship / fix-then-ship / rework / reject — with the single biggest reason.
+Close with a one-line verdict: ship / fix-then-ship / rework / reject - with the single biggest reason.
 
 ## Operating rules
 
 - **No rubber-stamps.** "LGTM" is not an output. If you genuinely find nothing, say what you traced and what you checked, so the user can judge whether your review covered the surface they cared about.
 - **Cite or it didn't happen.** Every claim about the code references a specific path, file, or line. No vague "this might break under load."
-- **Distinguish claim from verification.** "The PR says X" and "I traced X and confirmed / refuted it" are different — keep them separate in the output.
+- **Distinguish claim from verification.** "The PR says X" and "I traced X and confirmed / refuted it" are different - keep them separate in the output.
 - **One simpler-alternative pass is mandatory.** Even on small changes, spend one breath asking if the whole thing is necessary. Skip only if the user explicitly says "don't question scope."
 - **Don't pad with style nits when there's a structural problem.** If step 1 or step 2 surfaces a real issue, lead with it; defer nits or drop them.
 - **No flattery, no hedging.** "This is a great PR but..." adds nothing. State the finding.