systemic-issue-triage

Classifies bug reports by root cause and batches fixes that shrink the codebase.

Updated Aug 25, 2026
One-click install
npx skills add https://github.com/CarlosWilliamsR/SketchOS --skill systemic-issue-triage-carloswilliamsr
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: systemic-issue-triage
Source: https://github.com/CarlosWilliamsR/SketchOS/tree/main/.config/opencode/skills/systemic-issue-triage
Command: npx skills add https://github.com/CarlosWilliamsR/SketchOS --skill systemic-issue-triage-carloswilliamsr

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams drowning in issue backlogs often fix symptoms one-by-one, producing over-engineered systems that grow exponentially and become unmaintainable. This Skill enforces root-cause triage so every fix shrinks the system instead of growing it. ## Core Features & Use Cases - Root-class classification: Every issue lands in exactly one bucket — superseded by an in-flight change, duplicate of a known class, real new bug assigned to a root-cause cluster, feature request, or unclear. - Clustered fix batching: Two or more issues sharing a root get one fix at the root, closing all of them with named test evidence rather than N separate patches. - Over-engineering gate: Any fix that adds a state, verb, config flag, or parallel representation is rejected in favor of deletions or relaxations. - Use Case: When a flood of community bug reports arrives after a release, triage each one against the decision gates, group them into clusters, and ship one deletion-heavy fix batch that closes the whole cluster with named tests. ## Quick Start Triage the open issues in this repository by root cause and propose a batched fix plan with named test evidence for each closure.

Frequently Asked Questions about systemic-issue-triage

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I triage a large backlog of bug reports efficiently?

Classify each issue by root class first: superseded by an in-flight change, duplicate of a known class, real new bug, feature request, or unclear. Then group real bugs sharing a root cause into clusters and design one fix per cluster instead of one patch per issue.

How to avoid over-engineering when fixing bugs?

Apply the over-engineering test before any fix: if it adds a state, verb, config flag, gate, or parallel representation of existing truth, redesign instead. The correct fix usually deletes or relaxes something, keeping the system smaller after the fix than before.

When should multiple issues be closed by a single fix?

When two or more issues share the same root cause, they get one fix at the root that closes all of them. Each closure must cite a named test as evidence, never a promise that the issue should be fixed now.

Why does a bug reproduce in production but pass in tests?

The test may have been taught to agree with the defect. Check whether the commit introducing the bug also modified a test helper, fixture, or corpus to satisfy it, or whether a test row asserts the defective behavior as intended, and remove that pinning test.

What should I check before deleting a command or user-facing verb?

Grep the user-facing string repo-wide, not just the symbol call graph, because help text, refusal messages, and sanctioned-exit lists may reference it. Expect the real scope to exceed the design-time inventory by two to five times and report the delta.