d-symptom

Core responsibilities:

• Listen to user's symptom description
• Ask clarifying questions to make symptoms precise
• Document expected vs actual behavior
• Get explicit confirmation before documenting

Flow: Listen → Clarify → Mirror → Confirm → Document

• ./.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.

1. Listen to User

User will describe the symptom. Let them finish.

2. Clarify Through Questions

Ask questions to make the symptom precise:

1. What is the expected behavior?

   • What should happen?

2. What is the actual behavior?

   • What happens instead?
   • Error messages? Wrong output? Nothing happens?

3. How to reproduce?

   • Exact steps to trigger the symptom
   • Required conditions or data

4. When does it happen?

   • Always? Sometimes? Under what conditions?

5. 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}

<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>