Claude-skill-registry d-symptom
Clarify and document bug symptoms. Creates ./.gtd/debug/current/SYMPTOM.md
git clone https://github.com/majiayu000/claude-skill-registry
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/d-symptom" ~/.claude/skills/majiayu000-claude-skill-registry-d-symptom && rm -rf "$T"
skills/data/d-symptom/SKILL.mdCore responsibilities:
- Listen to user's symptom description
- Ask clarifying questions to make symptoms precise
- Document expected vs actual behavior
- Get explicit confirmation before documenting </role>
Flow: Listen → Clarify → Mirror → Confirm → Document </objective>
<context> **Output:**
</context>./.gtd/debug/current/SYMPTOM.md
Precision Over Speed
A vague symptom leads to wrong diagnosis. Take time to clarify.
Observable vs Interpretation
Focus on what can be observed, not assumptions about cause:
- ✓ "API returns 500 when posting to /users"
- ✗ "Database connection is broken"
Reproducibility
If you can't reproduce it, you can't verify the fix.
</philosophy> <process>1. Listen to User
User will describe the symptom. Let them finish.
2. Clarify Through Questions
Ask questions to make the symptom precise:
-
What is the expected behavior?
- What should happen?
-
What is the actual behavior?
- What happens instead?
- Error messages? Wrong output? Nothing happens?
-
How to reproduce?
- Exact steps to trigger the symptom
- Required conditions or data
-
When does it happen?
- Always? Sometimes? Under what conditions?
-
Environment/Context:
- Which environment? (dev, staging, prod)
- Recent changes?
- Specific data or user?
Keep asking until you can describe the symptom precisely.
3. Mirror Phase
Summarize your understanding:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GTD:DEBUG ► CONFIRMING SYMPTOM ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ **Expected Behavior:** {What should happen} **Actual Behavior:** {What happens instead} **Reproduction Steps:** 1. {step 1} 2. {step 2} ... **Conditions:** - {condition 1} - {condition 2} **Environment:** {Environment details} ───────────────────────────────────────────────────── Is this correct? (yes/no/clarify)
Wait for explicit confirmation.
4. Document SYMPTOM.md
mkdir -p ./.gtd/debug/current
Write to
./.gtd/debug/current/SYMPTOM.md:
# Bug Symptom **Reported:** {date} **Status:** CONFIRMED ## Expected Behavior {What should happen} ## Actual Behavior {What happens instead} ## Reproduction Steps 1. {step 1} 2. {step 2} ... ## Conditions - {condition 1} - {condition 2} ## Environment - **Environment:** {dev/staging/prod} - **Version/Commit:** {if known} - **Recent Changes:** {if any} ## Additional Context {Any other relevant information}
</process>
<offer_next>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ GTD:DEBUG ► SYMPTOM DOCUMENTED ✓ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Symptom documented: ./.gtd/debug/current/SYMPTOM.md ───────────────────────────────────────────────────── ▶ Next Up /d-inspect — analyze code and form hypotheses ─────────────────────────────────────────────────────
</offer_next>
<forced_stop> STOP. The workflow is complete. Do NOT automatically run the next command. Wait for the user. </forced_stop>