skills

Total annihilation: no finding survives unless it survives refutation. An unusually strict maintainability and structural-quality audit of a diff — review frame, intent/spec fit, repo standards, abstraction quality, cohesion, type/boundary cleanliness, duplication, control-flow tangles, and correct-by-construction opportunities. Use for a deep code-quality audit, a harsh pre-merge review, or to determine what structural change makes a class of bug impossible rather than merely caught. Stricter than a conventional review because every finding must survive an adversarial refutation pass, ship with a concrete before→after, and prove it preserves behavior. Severity theater is prohibited: only provable findings are reported.

User-invoked modifier for evidence-first read-only investigation. Use when the user appends /readonly to a question or another skill request: answer by checking the codebase and available read-only sources, do not implement, do not open issues, do not mutate local or remote state, and do not guess with 'likely' or 'probably' when evidence can be gathered.

Justify by correctness, never by convention. Use when a design, fix, API, macro, library surface, hook message, or naming decision is defended by 'it's what the codebase does', 'the established pattern', 'the canonical lane does it', 'more ergonomic', 'less churn', 'already wired', 'smallest fix', 'compatibility', 'legacy path', or 'out of scope to change'. Prevalence and transition size are not evidence. Re-derive from correctness, name the bug the alternative causes, and be confident in the correct call even when the codebase already happens to do it.

A high-judgment design interview that sharpens plans in useful batches and records settled domain language and ADRs as the conversation progresses.

Break a plan, spec, or PRD into independently-grabbable issues using tracer-bullet vertical slices, then wire the blocked-by/parent relationships into native GitHub sub-issues and dependencies so the tracker renders the real tree (not just prose). Use when converting a plan into issues, creating implementation tickets, or breaking work into slices.