feature-troubleshoot
Systematic debugging mode with hypothesis-driven investigation. Use when user reports a bug, encounters an error, or needs help debugging a problem.
安装与使用
请根据来源仓库和你的 AI 工具说明安装此技能。先阅读技能文件和依赖要求,再添加到工作流。
查看来源 ↗使用指南技能说明
Troubleshooting Command
You are executing the SYSTEMATIC TROUBLESHOOTING workflow - a methodical debugging process that prevents spinning wheels through hypothesis-driven investigation.
Contents
- Problem Context
- What Makes This Different
- Workflow Overview
- Phase Details
- Ask For Help Mechanism
- Error Handling
Problem Context
$ARGUMENTS
If no specific problem was provided above, you will help the user define the problem clearly.
What Makes This Different
Ad-hoc debugging: Try things randomly, hope something works Systematic troubleshooting (this command): Form hypotheses, gather evidence, verify fixes
Key capability: "Something is broken" → investigate → "Root cause identified and fixed"
This provides structured debugging rather than trial and error.
Relationship to Feature-Audit
| Command | Mode | Purpose |
|---|---|---|
/feature-audit |
Proactive | "Verify this works as expected" |
/feature-troubleshoot |
Reactive | "This is broken, help me fix it" |
Both complement each other - audit can prevent issues, troubleshoot resolves them.
Workflow Overview
This command orchestrates a 5-phase workflow:
| Phase | Name | Purpose |
|---|---|---|
| 1 | Problem Definition | Clearly define what's wrong and expected behavior |
| 2 | Hypothesis Formation | Generate possible causes ranked by likelihood |
| 3 | Investigation | Gather evidence to test hypotheses |
| 4 | Resolution | Apply fix based on evidence |
| 5 | Verification | Confirm the fix works and problem is resolved |
Phase Details
Phase 1: Problem Definition
- Gather problem details from user
- Establish expected vs actual behavior
- Identify when the problem started (if known)
- Document reproduction steps
- Scope the problem
Phase 2: Hypothesis Formation
See: hypothesis.md
- Generate possible causes
- Rank by likelihood
- Identify evidence needed to test each
- Create investigation plan
- Track hypothesis status
Phase 3: Investigation
See: investigation.md
- Systematically test hypotheses
- Gather evidence (logs, code reading, testing)
- Update hypothesis rankings based on evidence
- Use audit-style log injection if needed
- Ask for help if stuck
Phase 4: Resolution
See: resolution.md
- Propose fix based on evidence
- Get user approval
- Apply the fix
- Document what was changed
Phase 5: Verification
See: verification.md
- Verify the fix works
- Confirm original problem is resolved
- Check for regressions
- Document resolution
Ask For Help Mechanism
To prevent spinning wheels, this workflow includes an "ask for help" mechanism.
When to Trigger
Ask the user for help when:
- No progress on hypothesis - Investigated 3+ hypotheses with no root cause found
- Conflicting evidence - Evidence doesn't match any hypothesis
- Access limitations - Can't access needed logs, systems, or data
- Domain knowledge gap - Problem requires specific domain expertise
- Time threshold - Significant time spent without progress
How to Ask
## Seeking Additional Input
I've investigated [N] hypotheses but haven't identified the root cause.
### What I've Tried
1. [Hypothesis 1] - Ruled out because [evidence]
2. [Hypothesis 2] - Ruled out because [evidence]
3. [Hypothesis 3] - Inconclusive, need more data
### What Would Help
- [ ] Access to [specific logs/system]
- [ ] Information about [specific question]
- [ ] Someone with [domain] expertise
- [ ] Permission to [specific action]
### Questions for You
1. Have you seen this issue before?
2. Any recent changes that might be related?
3. Can you provide [specific information]?
4. Should we escalate to [team/person]?
Troubleshooting Session Storage
For complex issues, store session data:
docs/troubleshooting/
└── [session-id]/
├── session.json # Problem definition, hypotheses, status
├── evidence/ # Captured logs, screenshots, test results
└── resolution.md # Final resolution documentation
Integration Points
-
Use with feature-audit: If you need runtime evidence, trigger
/feature-auditfor specific verification - Works with code-archaeologist: For understanding unfamiliar code during investigation
-
Complements feature workflow: Can debug issues found during
/feature-ship
Error Handling
| Error | Resolution |
|---|---|
| Problem too vague | Ask clarifying questions in Phase 1 |
| No hypotheses match | Generate new hypotheses, ask for help |
| Can't reproduce | Ask for more specific reproduction steps |
| Fix doesn't work | Return to Phase 2, form new hypotheses |
| Multiple root causes | Address each systematically |
Philosophy: "Debug with Evidence, Not Intuition"
This workflow ensures:
- Problems are clearly defined before debugging
- Investigation is systematic, not random
- Hypotheses are tested with evidence
- Fixes are verified, not assumed
- Knowledge is preserved for future issues
No more spinning wheels. No more "try this and see."
Let's identify the problem and fix it systematically!
使用示例
查看来源仓库中的使用示例与配置说明。
查看来源 ↗来源历史
- 收录时间
- 2026-01-20
- 索引更新时间
- 2026-01-26
- Branch
- main
收录与同步日期属于本站记录。源码修改历史请查看来源仓库。
GitHub ↗chat Comments (0)
Sign in to join the discussion and leave a comment.
No comments yet. Be the first to share your thoughts!