oh-my-issueslisted

# oh-my-issues Turn an issue backlog into a roadmap. Issues are symptom data, not units of work — the unit of work is the architectural defect that produces them. The end state is `open issues == open plans`, 1:1. ## Core principle Stop closing issues one at a time. Group symptoms that share a single architectural fix into a cluster, give the cluster one canonical home (a plan-master issue + a `plans/0X-*.md` design doc), close every child with a standardized redirect, and ship one PR per cluster that closes all children atomically. New incoming bugs get appended to the matching master as a "Round N" comment, not opened as new tracked issues. This compounds three ways: architectural fixes retire whole symptom families, the plan's test matrix institutionalizes prevention in CI, and standardized triage makes residual inflow cheap. ## When to use - The repo has 20+ open issues and many feel like duplicates or platform-specific symptoms of the same defect. - The user asks to "triage", "consolidate", "cluster", "dedupe", "group", or "make a plan from" the issue list. - A new bug is filed and the user wants to know whether it belongs to existing work. - The user wants to ship a focused PR that resolves a cluster of related issues. ## When NOT to use - Fewer than ~15 open issues: just close them. - Issues are genuinely independent (no shared root causes): one fix per issue is correct. - The repo lacks `plans/` discipline and the user does not want to introduce one — propose