trellis-break-loop

Analyzes fixed bugs across five dimensions to prevent recurring bug classes.

Updated Apr 14, 2026
One-click install
npx skills add https://github.com/exhyy/face-crop --skill trellis-break-loop-exhyy
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: trellis-break-loop
Source: https://github.com/exhyy/face-crop/tree/main/.claude/skills/trellis-break-loop
Command: npx skills add https://github.com/exhyy/face-crop --skill trellis-break-loop-exhyy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often fix a bug, move on, and then hit the same class of bug again because the root cause and prevention lessons were never captured. This Skill performs a structured post-fix analysis that turns one-off debugging into permanent knowledge recorded in project specs. ## Core Features & Use Cases - Root Cause Classification: Categorizes each bug into one of five categories (missing spec, cross-layer contract, change propagation failure, test coverage gap, implicit assumption) with a comparison table. - Failure Retrospective: Analyzes why earlier fix attempts failed, distinguishing surface fixes, incomplete scope, tool limitations, and mental model errors. - Prevention & Knowledge Capture: Produces a prioritized prevention-mechanism table and mandates immediate updates to .trellis/spec/guides/ thinking guides, template syncing, and committing the spec changes. - Use Case: After fixing a bug where an API returned timestamps in seconds instead of milliseconds, run this analysis to classify it as an implicit-assumption bug, document prevention mechanisms, and update the cross-layer thinking guide so the class of bug never recurs. ## Quick Start Analyze the bug we just fixed using the break-loop framework and update the relevant spec guides with the prevention lessons.

Frequently Asked Questions about trellis-break-loop

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

FAQPage Schema
How do I prevent the same bug from happening again after fixing it?▼

Run a structured post-fix analysis that classifies the root cause category, reviews why earlier fixes failed, and defines prevention mechanisms such as documentation, type safety, or test coverage. The findings are then captured into project spec guides so the lesson persists.

What is a root cause analysis framework for software bugs?▼

This framework classifies bugs into five categories: missing spec, cross-layer contract issues, change propagation failures, test coverage gaps, and implicit assumptions. Each category maps to specific prevention mechanisms like checklists, type-safe wrappers, or integration tests.

When should I run a bug retrospective analysis?▼

Run it immediately after a bug is fixed, especially if multiple fix attempts failed before succeeding. The analysis is most valuable while the debugging context is fresh, and it ends with concrete spec updates rather than just a chat summary.

Does this analysis require a specific project structure?▼

Yes, it is designed for projects using the Trellis workflow with a `.trellis/spec/` directory containing thinking guides. It updates those guides, syncs templates to `src/templates/markdown/spec/`, and expects the spec changes to be committed.

Why do bug fixes fail repeatedly in the same codebase?▼

Repeated failures usually come from surface fixes that address symptoms, incomplete scope that misses related call sites, tool limitations like weak type checking, or a mental model stuck in one layer. Analyzing each failed attempt reveals which pattern applies.