bug-echo
A Claude Code skill that runs after a fix lands, infers the anti-pattern from your diff, validates the pattern against the pre-fix file, and scans the rest of the codebase for sibling instances. Each match is read in context and classified BUG / OK / REVIEW.
Companion: bug-prospector — runs before a fix to find bugs you haven't seen yet. The two skills cover opposite halves of the bug-finding loop.
bug-echo and pattern-based linters are complementary, not competitive: linters check every file against pre-built rules on every save; bug-echo runs once per fix to scan for siblings of a bug that just demonstrated itself. A thorough audit uses both.
Built while shipping Stuffolio, an iOS/macOS app currently at build 33. Free, open source, Apache 2.0.
~7 min read · scan the TL;DR if you only have 30 seconds
Newer to Claude Code?
A skill is a markdown file Claude Code knows how to run. When you type /bug-echo after a bug fix, Claude follows the instructions in this skill, reads your diff, scans for sibling patterns, and writes you a classified report. You don't have to memorize anything — the skill tells Claude what to do, you read the report.
TL;DR
- What: A Claude Code skill that runs after a bug fix, infers the anti-pattern from the diff, and scans the codebase for sibling instances. Each match classified BUG / OK / REVIEW with file:line citations.
- Why: The pattern bug-echo scans for is one that just demonstrated itself in your codebase. After-the-fact pattern matching beats catalog matching because the pattern was selected by reality, not by a rule author guessing.
- Install: Two
/plugin commands in Claude Code; then /bug-echo is available in any project.
- Try first: After your next bug fix, run
/bug-echo. It reads the diff, self-validates the inferred pattern, and scans in ~2 minutes on a typical Swift codebase.
- Example output: a real sibling-bug scan on Stuffolio. Also: describe-mode example on TypeScript (synthesized).
- See it work: Real example: caught a 2-week-old sibling bug in 2 minutes.
- Maturity: v1.2.0; used through real App Store submission cycles; works on any language for pattern construction, with platform-conditional handling currently Swift-specific.
- New in v1.2.0: recon scout — the skill now counts candidates before running the full ceremony and matches report shape to actual signal (0 / 1-5 / 6+ buckets). Cuts ~39% of historical runs to a one-line note or inline rated table instead of a full file write.
What bug-echo is for vs what linters are for
bug-echo and linters are complementary — they catch different bugs at different times in your workflow.
Pattern-based linters (SwiftLint, ESLint, custom rule sets) check every file against a pre-built catalog on every save. The catalog reflects what someone thought was a bug at the time the rule was written. Linters are fast, cheap, and catch a real class of style and pattern violations that bug-echo would never run for (you wouldn't fire a sibling scan for every missing @MainActor). They will find issues bug-echo won't.
bug-echo flips the direction. It runs once per fix, in response to a bug that just demonstrated itself in your codebase, fifteen minutes ago, in production code you wrote. The fix is the proof. After-the-fact pattern matching is dramatically more accurate than catalog matching because the pattern was selected by reality, not by a rule author guessing. It will find sibling instances of bugs your linter has no rule for — because the bug was novel enough to need fixing in the first place.
The trick that makes this practical: bug-echo self-validates the inferred pattern against the pre-fix version of the file before scanning. If the pattern doesn't match the bug it was extracted from, the skill stops rather than scanning with a bad search. You never get findings from a misinterpreted diff.
