lxyerlxyer/multi-agent-collaboration-system/.agents/skills/break-loop/SKILL.md

break-loop

Skill1 starsChanged 7 months agoMITView on GitHub

Deep post-fix bug analysis across five dimensions: root cause categorization, fix failure analysis, prevention mechanisms, systematic expansion, and knowledge capture. Updates .trellis/spec/ guides with lessons learned to prevent recurring bugs. Use when a debugging session completes, after fixing a tricky bug, when the same class of bug keeps recurring, or when you want to capture debugging insights into project documentation.

In this repository16 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- .cursor/rules/macs-protocol.mdcCursor rule
- before-devSkill
- brainstormSkill
- check-cross-layerSkill
- checkSkill
- create-commandSkill
- finish-workSkill
- improve-utSkill
- integrate-skillSkill
- onboardSkill
- record-sessionSkill
- startSkill
- update-specSkill

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 4 are distinctive, and 5 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
When debug is complete, use this skill for deep analysis to break the "fix bug -> forget -> repeat" cycle.
line 8
Distinctive:
If you tried multiple fixes before succeeding, analyze each failure:
line 30
Distinctive:
IMPORTANT: After completing the analysis above, you MUST immediately:
line 118
Distinctive:
Update spec/guides: - Don't just list TODOs, actually update the relevant files:
line 120
Very specific:
If it's a cross-platform issue → update cross-platform-thinking-guide.md
line 121
Very specific:
If it's a cross-layer issue → update cross-layer-thinking-guide.md
line 122
Very specific:
If it's a code reuse issue → update code-reuse-thinking-guide.md
line 123
Very specific:
If it's domain-specific → update backend/*.md or frontend/*.md
line 124
Very specific:
Sync templates: - After updating .trellis/spec/, sync to src/templates/markdown/spec/
line 126

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Break the Loop - Deep Bug Analysis

When debug is complete, use this skill for deep analysis to break the "fix bug -> forget -> repeat" cycle.

Analysis Framework

Analyze the bug you just fixed from these 5 dimensions:

1. Root Cause Category

Which category does this bug belong to?

Category	Characteristics	Example
A. Missing Spec	No documentation on how to do it	New feature without checklist
B. Cross-Layer Contract	Interface between layers unclear	API returns different format than expected
C. Change Propagation Failure	Changed one place, missed others	Changed function signature, missed call sites
D. Test Coverage Gap	Unit test passes, integration fails	Works alone, breaks when combined
E. Implicit Assumption	Code relies on undocumented assumption	Timestamp seconds vs milliseconds

2. Why Fixes Failed (if applicable)

If you tried multiple fixes before succeeding, analyze each failure:

Surface Fix: Fixed symptom, not root cause
Incomplete Scope: Found root cause, didn't cover all cases
Tool Limitation: grep missed it, type check wasn't strict
Mental Model: Kept looking in same layer, didn't think cross-layer

3. Prevention Mechanisms

What mechanisms would prevent this from happening again?

Type	Description	Example
Documentation	Write it down so people know	Update thinking guide
Architecture	Make the error impossible structurally	Type-safe wrappers
Compile-time	TypeScript strict, no any	Signature change causes compile error
Runtime	Monitoring, alerts, scans	Detect orphan entities
Test Coverage	E2E tests, integration tests	Verify full flow
Code Review	Checklist, PR template	"Did you check X?"

4. Systematic Expansion

What broader problems does this bug reveal?

Similar Issues: Where else might this problem exist?
Design Flaw: Is there a fundamental architecture issue?
Process Flaw: Is there a development process improvement?
Knowledge Gap: Is the team missing some understanding?

5. Knowledge Capture

Solidify insights into the system:

Update .trellis/spec/guides/ thinking guides
Update .trellis/spec/backend/ or frontend/ docs
Create issue record (if applicable)
Create feature ticket for root fix
Update check skills if needed

Output Format

Please output analysis in this format:

## Bug Analysis: [Short Description]

### 1. Root Cause Category
- **Category**: [A/B/C/D/E] - [Category Name]
- **Specific Cause**: [Detailed description]

### 2. Why Fixes Failed (if applicable)
1. [First attempt]: [Why it failed]
2. [Second attempt]: [Why it failed]
...

### 3. Prevention Mechanisms
| Priority | Mechanism | Specific Action | Status |
|----------|-----------|-----------------|--------|
| P0 | ... | ... | TODO/DONE |

### 4. Systematic Expansion
- **Similar Issues**: [List places with similar problems]
- **Design Improvement**: [Architecture-level suggestions]
- **Process Improvement**: [Development process suggestions]

### 5. Knowledge Capture
- [ ] [Documents to update / tickets to create]

Core Philosophy

The value of debugging is not in fixing the bug, but in making this class of bugs never happen again.

Three levels of insight:

Tactical: How to fix THIS bug
Strategic: How to prevent THIS CLASS of bugs
Philosophical: How to expand thinking patterns

30 minutes of analysis saves 30 hours of future debugging.

After Analysis: Immediate Actions

IMPORTANT: After completing the analysis above, you MUST immediately:

Update spec/guides - Don't just list TODOs, actually update the relevant files:
- If it's a cross-platform issue → update cross-platform-thinking-guide.md
- If it's a cross-layer issue → update cross-layer-thinking-guide.md
- If it's a code reuse issue → update code-reuse-thinking-guide.md
- If it's domain-specific → update backend/*.md or frontend/*.md
Sync templates - After updating .trellis/spec/, sync to src/templates/markdown/spec/
Commit the spec updates - This is the primary output, not just the analysis text

The analysis is worthless if it stays in chat. The value is in the updated specs.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free