Graphify-Aware Recurring Bugs

Overview

A stack trace shows where a bug surfaced, not everywhere its root cause reaches. Grepping around the crash site misses related call sites that share the same underlying problem, which is exactly how the same root cause gets logged as three unrelated "new" bugs over time. graphify already builds a queryable structural map of a codebase; this skill puts that map to work specifically during bug investigation, not just general code Q&A.

Core principle: a recurring bug should be recognized as recurring, and its known-good fix reused, not re-discovered as new. graphify is the linker that recalls the past occurrence; KNOWN_ISSUES.md is where the fix that worked is actually recorded.

Gate: does this apply?

Check for graphify-out/graph.json at the project root before doing anything else in this skill.

• Missing → this skill is a complete no-op. Don't suggest building a graph mid-investigation (that's a real side effect, leave it to /craftsman:init's ask-first note, or to the user deciding to run graphify . themselves). Proceed with normal root-cause investigation.
• Present → continue below.

During root-cause investigation

This slots into the evidence-gathering step of root-cause investigation (Phase 1 of the superpowers systematic-debugging skill, where that plugin is installed), run this before falling back to raw grep:

1. graphify query "<symptom or affected function/file>", get a scoped subgraph of related code. This is both cheaper in tokens than grepping the whole codebase and more thorough than reading only the stack trace, since it surfaces callers/dependents that share the same code path.
2. If the query surfaces other call sites of the same function/module implicated in the bug, treat them as suspects too, a bug in a shared helper usually isn't confined to the one call site that happened to trigger it first.