trellis-break-loop

Analyzes fixed bugs to identify root causes and capture prevention mechanisms into specs.

Updated Sep 5, 2026
One-click install
npx skills add https://github.com/jiozhaoyue/ST-BgLoader --skill trellis-break-loop-jiozhaoyue
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: trellis-break-loop
Source: https://github.com/jiozhaoyue/ST-BgLoader/tree/main/.cursor/skills/trellis-break-loop
Command: npx skills add https://github.com/jiozhaoyue/ST-BgLoader --skill trellis-break-loop-jiozhaoyue

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often fix a bug and move on, only to hit the same class of bug again later. This Skill breaks the fix-forget-repeat cycle by guiding a structured post-fix analysis that turns one-off debugging into permanent prevention mechanisms and documented knowledge. ## Core Features & Use Cases - Root Cause Classification: Categorizes bugs into five types (missing spec, cross-layer contract, change propagation failure, test coverage gap, implicit assumption) to reveal systemic patterns. - Bayesian Reasoning Framework: Provides a five-step hypothesis updating method with priors, evidence reliability ranking, and confidence thresholds for ambiguous debugging situations. - Knowledge Capture Workflow: Converts analysis into concrete actions such as updating thinking guides, syncing spec templates, and creating follow-up tickets. - 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, then update the cross-layer thinking guide so the whole team avoids the same mistake. ## Quick Start Analyze the bug we just fixed using the break-loop framework and update the relevant spec guides with the prevention mechanisms.

Frequently Asked Questions about trellis-break-loop

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

FAQPage Schema
How do I do a root cause analysis after fixing a bug?▼

Classify the bug into one of five categories: missing spec, cross-layer contract, change propagation failure, test coverage gap, or implicit assumption. Then document why earlier fixes failed, define prevention mechanisms, and update your team's spec guides with the lessons learned.

What is the fix-forget-repeat cycle in debugging?▼

It is the pattern where teams fix a bug, forget the lesson, and later repeat the same class of bug. Breaking it requires post-fix analysis that captures root causes into documentation, tests, and structural prevention mechanisms rather than just patching the symptom.

How does Bayesian reasoning help with debugging?▼

Bayesian reasoning assigns prior probabilities to competing root cause hypotheses, then updates them based on evidence reliability. It prevents anchoring on the first guess and pushes you to seek discriminating evidence that distinguishes between top hypotheses before committing to a fix.

When should I run a post-fix bug analysis?▼

Run it immediately after a bug is fixed, especially if the fix required multiple attempts or revealed cross-layer issues. The analysis is most valuable while context is fresh, and its output should be committed spec updates rather than chat-only discussion.

What are the limitations of post-hoc bug analysis?▼

Post-hoc analysis only helps after a bug has already occurred and depends on honest documentation of failed fix attempts. It cannot replace upfront prevention like strict typing or integration tests, and its value is lost if insights are not actually written into specs.