oh-my-issues

A workflow for turning a sprawling GitHub issue backlog into a compact roadmap by clustering issues around their root causes. Its governing idea is that issues are symptom data, not units of work; the real unit of work is the architectural defect that produces them, and the target end state is a 1:1 relationship where open issues equal open plans. Instead of closing issues one at a time, it groups symptoms that share a single architectural fix into a cluster, gives each cluster one canonical home (a plan-master issue plus a plans/0X-*.md design doc), closes each child with a standardized redirect comment, and ships one PR per cluster that closes all children atomically.

It defines three modes. The cluster pass is the initial reduction: read every open issue's body and full comment thread, cluster by root cause rather than surface, name each cluster as an architectural problem whose title implies a fix, open one master per cluster with a defect description, child list, fix sequence, and a regression-preventing test matrix, mirror each master as a design doc, close every child as not planned, and verify only masters remain. Triage handles a new incoming bug in steady state by pattern-matching it against existing masters and appending a Round N comment rather than opening a new tracked issue. Bundle ships a cluster with one PR that lists every child as Closes #N and adds the plan's test matrix to CI.

Use it when a tracker has accumulated dozens of overlapping reports, or when asked to triage, consolidate, cluster, dedupe, or build a plan series from open issues; it advises against use for fewer than roughly 15 issues or genuinely independent issues. It includes gh CLI primitives for resolving the repo, getting an accurate issue-only open count (since GitHub counts PRs as issues), listing bodies without silent --limit truncation, and fetching per-issue comment threads, plus the exact standardized redirect wording and naming guidance that separates surface titles from architectural ones.