systemic-issue-triage

# Systemic Issue Triage ## Activation Contract Use when triaging incoming issues, planning fixes for a backlog, or deciding how to respond to any bug report. The failure mode this skill exists to prevent: fixing symptoms one-by-one until the system becomes over-engineered machinery that grows exponentially and nobody can maintain. For a full-backlog audit REPORT (dispositions across every open issue/PR), use `backlog-triage`; this skill governs how the resulting fixes are designed, batched, and closed. ## Hard Rules - Classify by ROOT CLASS before touching code. Every issue lands in exactly one bucket: (A) superseded by an in-flight design change — name the change and the test that proves it; (B) duplicate of a known class — name the canonical tracker; (C) real new bug — assign to a root-cause CLUSTER, never a standalone fix; (D) feature request; (E) unclear — ask the reporter, don't guess. - Two or more issues sharing a root = ONE fix at the root, closing all of them with named test evidence. N issues never justify N patches. - Issues close against NAMED TESTS (supersession evidence), never against promises or "should be fixed now". - The over-engineering test before ANY fix: does it add a state, a verb, a config flag, a gate, or a parallel representation of existing truth? If yes, redesign — the correct fix usually DELETES or RELAXES something (13 states became 5; a dead-end became a one-line exit message). - A block whose fix is "name the executable exit in the messag...