trellis-break-loop

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

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

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 gap, implicit assumption), reviews why earlier fixes failed, and derives prevention mechanisms. - Structured Output Template: Produces a standardized Markdown bug analysis 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 cross-layer API format mismatch, run this analysis to classify the cause, add a contract checklist to the relevant thinking guide, and create a ticket for a type-safe wrapper. ## 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 safety, or tests. Then capture the insights into persistent spec documents rather than leaving them in chat.

What is a root cause analysis framework for software bugs?

This framework uses five categories: missing spec, cross-layer contract, change propagation failure, test coverage gap, and implicit assumption. Each fixed bug is mapped to one category, then expanded into prevention mechanisms and systematic improvements.

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 especially valuable when multiple fix attempts failed or when the bug crossed layer boundaries.

Does this analysis require a specific project structure?

The knowledge capture step targets a Trellis-style layout with `.trellis/spec/guides/` thinking guides and template syncing to `src/templates/markdown/spec/`. Projects without that structure can still use the analysis framework and adapt the documentation targets.

What are the limitations of post-fix bug analysis?

The analysis only creates value if the identified spec updates and tickets are actually committed, not just listed as TODOs. It also depends on accurate recall of the debugging session, so running it long after the fix reduces quality.