joris887
joris887/exosuit
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/joris887/exosuit --skill debug-session命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Execute comprehensive backlog review. Analyzes story quality, Definition of Ready compliance, dependencies, zombie stories, and generates a backlog health report.
First-run framework setup. Detects existing project stack or guides new project creation from vision/braindump.
Use when the user has a complex idea that needs design exploration before story decomposition.
正在显示 SKILL.md
| name | debug-session |
| version | 2.9.1 |
| description | Use when the user reports a bug, error, or unexpected behavior that needs investigation. |
| trigger | manual |
| depends-on | [] |
| references | ["references/root-cause-tracing.md","references/condition-based-waiting.md","references/error-recovery.md"] |
| micro-components | {"phase-4":["record-failure"]} |
| disable-model-invocation | true |
| user-invocable | true |
| allowed-tools | Read, Glob, Grep, Bash, WebSearch |
| argument-hint | [error-description] |
Skill metrics: Emit a start event to the activity log:
echo "{\"type\":\"skill\",\"event\":\"start\",\"skill\":\"debug-session\",\"ts\":\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\"}" >> docs/sessions/.activity-log.jsonl
Debug session for: $ARGUMENTS
At each phase transition, write docs/sessions/.failure-state.md with YAML frontmatter so the Stop hook and /continue can programmatically detect incomplete workflows.
At workflow start (Phase 1 entry):
---
status: active
skill: debug-session
phase: "1"
phase_name: "Root Cause Investigation"
started_at: "[ISO-8601 timestamp from date -u +%Y-%m-%dT%H:%M:%SZ]"
story: "[from $ARGUMENTS — the error description]"
branch: "[from git branch --show-current]"
next_action: "Reproduce error and trace root cause"
files_modified: []
---
## Context
Error: [error description]
Root cause: not yet identified
Hypothesis: none
Fix attempts: 0
Files investigated: [list as investigation proceeds]
At each phase transition: Update the frontmatter fields: , , , and append to . Update the Context section with investigation progress (root cause, hypothesis, fix attempts).
Check if the error area is governed by an accepted ADR. If so, the fix MUST respect that decision — propose a fix within the ADR's constraints rather than working around the architectural choice. If the ADR itself is the root cause, flag it for supersession rather than silently violating it. Do NOT attempt any fix until the root cause is identified with evidence. "I think it might be X" without evidence is NOT identification. Show: where the bug is, why it happens, and what incorrect state or logic causes it. Search for known issues before deep analysis — someone may have already solved this: After 3 failed fix attempts: STOP. Return to Phase 1 and re-trace from scratch. The root cause identification was likely wrong. Consult `references/error-recovery.md` — search for `## Phase 3`.phasephase_namenext_actionfiles_modifiedOn successful fix (Phase 5 complete): Delete .failure-state.md — clean state means no failure to recover from.
Do NOT skip this phase. Do NOT jump to a fix.
Run the relevant test or command to reproduce:
# Run the failing test or trigger the error
If it cannot be reproduced, gather more context before proceeding.
git log --oneline -10
git diff HEAD~3
Did a recent change introduce this? Use git bisect for non-obvious regressions.
Apply the failure_diagnosis reasoning tool from .claude/skills/story-cycle/references/reasoning-tools.md:
For multi-component systems, trace across component boundaries — check API calls, database queries, event handlers.
See references/root-cause-tracing.md — search for ## Steps for the detailed backward trace procedure.
DO / DON'T:
package.json, requirements.txt, or equivalent"[dependency] [error message or key phrase]"Based on evidence from Phases 1-2, state:
| Situation | Action |
|---|---|
| 3+ fix attempts have failed | STOP. Question the approach. Are you fixing the right thing? |
| "Just try X and see if it works" | STOP. Form a hypothesis first. |
| Making multiple changes at once | STOP. One variable at a time. |
| "It's probably X" without evidence | STOP. Gather evidence. |
| Fix works but you don't understand why | STOP. Understand before committing. |
See references/condition-based-waiting.md — search for ## Patterns by Language and load only your language's section.
If the root cause was initially misdiagnosed or the fix required changing approach, invoke the record-failure micro-component from .claude/prompts/record-failure.md to record the pattern in docs/context/error-patterns.md. This helps future sessions avoid the same diagnostic mistakes.
git add <files>
git commit -m "fix(<scope>): <what was fixed>
Root cause: <explanation>
Co-Authored-By: Claude <noreply@anthropic.com>"
Skill metrics: Emit a completion event:
echo "{\"type\":\"skill\",\"event\":\"end\",\"skill\":\"debug-session\",\"outcome\":\"success\",\"ts\":\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\"}" >> docs/sessions/.activity-log.jsonl
Input: /debug-session "TypeError: Cannot read properties of undefined (reading 'map')"
Output: Phase 1 → traced to `fetchUsers()` returning `undefined` when API returns 404
Phase 3 → hypothesis: missing error handling for non-200 responses
Phase 4 → added guard clause + regression test
Phase 5 → commit: "fix(api): handle non-200 response in fetchUsers"
Next Steps:
→ /story-cycle "[next story]" — continue with the next story
→ /sprint-end — if the fix was the last item in the sprint
→ /handoff — if ending the session
For phase-specific error recovery, consult references/error-recovery.md — search for the relevant ## Phase N section.
General recovery:
references/condition-based-waiting.md. Replace arbitrary sleeps with condition polling.