trellis-break-loop

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

4|1|Updated Apr 29, 2026
One-click install
npx skills add https://github.com/ZipperCode/lingma2api --skill trellis-break-loop-zippercode
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: trellis-break-loop
Source: https://github.com/ZipperCode/lingma2api/tree/main/.opencode/skills/trellis-break-loop
Command: npx skills add https://github.com/ZipperCode/lingma2api --skill trellis-break-loop-zippercode

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 forcing a structured post-fix analysis that captures root causes and converts them into durable documentation and prevention mechanisms. ## 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) with a structured analysis template. - Prevention Planning: Maps each bug to concrete prevention mechanisms such as documentation, type-safe architecture, compile-time checks, runtime monitoring, and test coverage. - Knowledge Capture: Directs updates to .trellis/spec/guides/ thinking guides and syncs templates so insights persist beyond the chat session. - 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, identify similar risks across the codebase, and update the cross-layer thinking guide. ## Quick Start Analyze the bug I just fixed and update the relevant spec guides to prevent this class of bug from recurring.

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, reviews why earlier fix attempts failed, and defines prevention mechanisms like documentation, type safety, or test coverage. The analysis output is then captured into spec guides so the knowledge persists.

What root cause categories does this bug analysis framework use?

It uses five categories: missing spec, cross-layer contract mismatch, change propagation failure, test coverage gap, and implicit assumption. Each category maps to characteristic symptoms and example scenarios to guide classification.

When should I run a deep bug analysis instead of just fixing the bug?

Run it immediately after a bug is fixed, especially when the fix required multiple attempts or revealed cross-layer issues. The goal is to convert one-off debugging effort into systemic prevention before context is lost.

Does this analysis require a specific project structure?

Yes, it assumes a Trellis-style project layout with `.trellis/spec/guides/` thinking guides and a `src/templates/markdown/spec/` template directory. Knowledge capture steps target those paths directly.

What are the limitations of post-fix bug analysis?

The analysis only adds value if the recommended spec updates and tickets are actually completed and committed. It does not automatically detect similar bugs elsewhere; systematic expansion still requires manual code inspection.