.claude/skills/d-symptom/SKILL.md
Clarify and document bug symptoms. Creates ./.gtd/debug/current/SYMPTOM.md
npx skillsauth add Hoang604/get-thing-done d-symptomInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Core responsibilities:
Flow: Listen → Clarify → Mirror → Confirm → Document </objective>
<context> **Output:**./.gtd/debug/current/SYMPTOM.md
</context>A vague symptom leads to wrong diagnosis. Take time to clarify.
Focus on what can be observed, not assumptions about cause:
If you can't reproduce it, you can't verify the fix.
</philosophy> <process>User will describe the symptom. Let them finish.
Ask questions to make the symptom precise:
What is the expected behavior?
What is the actual behavior?
How to reproduce?
When does it happen?
Environment/Context:
Keep asking until you can describe the symptom precisely.
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.
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}
<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>
testing
manual trigger by user, do not auto invoke
tools
manual trigger by user, do not auto invoke
development
Trace execution paths and document how code actually behaves. Use when you need to understand how features work, walk through code flows, explain component behavior, trace where data comes from, understand relationships between components, or audit for orphaned events and dead code.
testing
Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.