trellis-break-loop

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

Updated Jun 9, 2026
One-click install
npx skills add https://github.com/gyc-12/Archipelago --skill trellis-break-loop-gyc-12
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: trellis-break-loop
Source: https://github.com/gyc-12/Archipelago/tree/main/.cursor/skills/trellis-break-loop
Command: npx skills add https://github.com/gyc-12/Archipelago --skill trellis-break-loop-gyc-12

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 a completed debugging session into a structured root-cause analysis so the knowledge is captured in specs instead of being forgotten. ## Core Features & Use Cases - Five-Dimension Analysis Framework: Classifies the root cause (missing spec, cross-layer contract, change propagation failure, test coverage gap, implicit assumption), reviews why earlier fixes failed, and defines prevention mechanisms. - Structured Output Template: Produces a standardized Markdown bug analysis report with prioritized prevention actions (P0/P1) and systematic expansion of similar risks. - Knowledge Capture into Specs: Directs immediate updates to .trellis/spec/guides/ thinking guides, syncs templates to src/templates/markdown/spec/, and commits 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 the prevention mechanism, 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 do a root cause analysis after fixing a bug?

Run this analysis immediately after the fix. It classifies the bug into one of five root cause categories, reviews why earlier fix attempts failed, and outputs a structured Markdown report with prioritized prevention mechanisms.

What are the common root cause categories for software bugs?

The framework defines five categories: missing spec, cross-layer contract mismatch, change propagation failure, test coverage gap, and implicit assumption. Each category maps to different prevention mechanisms such as documentation, type safety, or integration tests.

When should I use this bug analysis workflow?

Use it after a debugging session is complete and the fix is confirmed, especially if the bug required multiple fix attempts or revealed a recurring pattern. It is not a debugging tool itself and does not help locate the bug.

Does this analysis update documentation automatically?

The workflow instructs the AI to update the relevant thinking guides under .trellis/spec/guides/, sync changes to src/templates/markdown/spec/, and commit the spec updates. The analysis text alone is treated as incomplete without these spec changes.

What prevention mechanisms can a bug analysis produce?

The framework covers six prevention types: documentation, architecture changes, compile-time checks, runtime monitoring, test coverage, and code review checklists. Each is prioritized in the output report with a status tracker.