.claude/skills/d-inspect/SKILL.md
Inspect code and propose root cause hypotheses. Creates ./.gtd/debug/current/HYPOTHESES.md
npx skillsauth add Hoang604/get-thing-done d-inspectInstall 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: Load Symptom → Trace Code → Form Hypotheses → Rank by Confidence </objective>
<context> **Required files:**./.gtd/debug/current/SYMPTOM.md — Must existOutput:
./.gtd/debug/current/HYPOTHESES.mdAgents used:
research — During code tracing
</context>Don't fixate on the first idea. Generate 3-5 competing hypotheses.
Rate each hypothesis honestly:
Each hypothesis needs supporting evidence from code analysis.
</philosophy> <process>Read ./.gtd/debug/current/SYMPTOM.md.
if ! test -f "./.gtd/debug/current/SYMPTOM.md"; then
echo "Error: No symptom documented. Run /d-symptom first."
exit 1
fi
Trigger: Immediately after loading symptom.
Fill prompt and spawn:
<objective>
Analyze root cause for symptom_file: ./.gtd/debug/current/SYMPTOM.md
</objective>
<investigation_checklist>
1. Identify Entry Points (triggers)
2. Trace Execution Flow (conditions, branches)
3. Examine Suspect Areas (logic gaps, state)
4. Check Dependencies (config, DB)
</investigation_checklist>
<output_format>
Ranked Hypotheses (3-5):
- Description
- Evidence (File:Line)
- Confidence Level
- Verification Method
</output_format>
Task(
prompt=filled_prompt,
subagent_type="researcher",
description="Investigating root cause"
)
Write to ./.gtd/debug/current/HYPOTHESES.md:
# Root Cause Hypotheses
**Analyzed:** {date}
**Status:** PENDING VERIFICATION
## Summary
Based on code analysis, here are the most likely root causes:
---
## Hypothesis 1: {Short description}
**Confidence:** High (75%)
**Description:**
{Detailed explanation of what you think is wrong}
**Evidence:**
- {Observation 1 from code}
- {Observation 2 from code}
- {Supporting fact}
**Location:**
- Files: `{file1}`, `{file2}`
- Lines: {line ranges}
**Verification Method:**
{How to confirm/reject this hypothesis}
---
## Hypothesis 2: {Short description}
**Confidence:** Medium (50%)
{Same structure as above}
---
## Hypothesis 3: {Short description}
**Confidence:** Low (25%)
{Same structure as above}
---
## Code Analysis Notes
{Any additional observations, patterns, or concerns}
<offer_next>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
GTD:DEBUG ► HYPOTHESES GENERATED ✓
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Hypotheses documented: ./.gtd/debug/current/HYPOTHESES.md
Total hypotheses: {N}
Highest confidence: {X}%
─────────────────────────────────────────────────────
▶ Next Up
/d-verify — verify hypotheses with debug logs
─────────────────────────────────────────────────────
</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.