trellis-break-loop

Analyzes fixed bugs across five dimensions to produce prevention mechanisms and spec updates.

2|Updated Jun 2, 2026
One-click install
npx skills add https://github.com/42team-ru/teampilot --skill trellis-break-loop-42team-ru
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: trellis-break-loop
Source: https://github.com/42team-ru/teampilot/tree/main/.cursor/skills/trellis-break-loop
Command: npx skills add https://github.com/42team-ru/teampilot --skill trellis-break-loop-42team-ru

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 turns every completed debugging session into a structured root-cause analysis so the knowledge is captured in specs instead of being lost. ## Core Features & Use Cases - Five-Dimension Analysis Framework: Classifies the root cause (missing spec, cross-layer contract, change propagation, test coverage gap, implicit assumption), reviews why earlier fixes failed, and defines prevention mechanisms. - Systematic Expansion: Identifies similar issues elsewhere in the codebase, design flaws, and process improvements revealed by the bug. - Knowledge Capture into Specs: Updates .trellis/spec/guides/ thinking guides, syncs templates to src/templates/markdown/spec/, and commits the spec changes as the primary output. - 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, add a type-safe wrapper as prevention, and update the cross-layer thinking guide. ## Quick Start After fixing a bug, ask the AI to run the break-loop analysis on the bug just fixed and update the relevant spec guides.

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 fix attempts failed, and defines prevention mechanisms such as documentation, type-safe wrappers, or test coverage. Then capture the findings into persistent spec documents.

What is a root cause analysis framework for software bugs?

This framework uses five root cause categories: missing spec, cross-layer contract mismatch, change propagation failure, test coverage gap, and implicit assumption. Each bug is classified into one category, then mapped to prevention mechanisms like compile-time checks, monitoring, or code review checklists.

When should I run a post-debugging analysis?

Run it immediately after a bug is fixed and verified, while the debugging context is still fresh. It is most valuable for bugs that required multiple fix attempts or revealed cross-layer or cross-platform issues.

Does this analysis require any external tools or scripts?

No external dependencies are required. The analysis is a prompt-driven workflow that reads and updates Markdown spec files under .trellis/spec/ and syncs them to src/templates/markdown/spec/ using standard file edits and commits.

What are the limitations of post-fix bug analysis?

The analysis only creates value if the findings are actually written into specs and committed; insights left in chat are lost. It also depends on the quality of the debugging session, since shallow fixes produce shallow root-cause classifications.