/investigate
Systematic debugging skill. Use when encountering a bug, test failure, unexpected behavior, or when asked to "investigate", "debug", "diagnose", or "figure out why". Enforces root-cause-first discipline with structured hypothesis tracking.
$ npx -y skills add blueberrycongee/termcanvas --skill investigate --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/investigate
Context preview
The summary Claude sees to decide when to auto-load this skill.
Systematic debugging skill. Use when encountering a bug, test failure, unexpected behavior, or when asked to "investigate", "debug", "diagnose", or "figure out why". Enforces root-cause-first discipline with structured hypothesis tracking.
SKILL.md
investigate.SKILL.mdname: investigate
description: >-
Systematic debugging skill. Use when encountering a bug, test failure,
unexpected behavior, or when asked to "investigate", "debug", "diagnose",
or "figure out why". Enforces root-cause-first discipline with structured
hypothesis tracking.
Investigate
Systematic debugging workflow. Do not guess-and-fix — find the root cause first.
Phase 1: Collect
Gather all available evidence before forming any hypothesis.
1. Read the error message, stack trace, or symptom description exactly as given 2. Identify the affected code path — read the relevant source files 3. Check `git log --oneline -20` in the affected area for recent changes 4. If reproducible, reproduce the issue and capture the exact output 5. List what you know and what you do not know
Deliverable: a structured symptom summary with affected files, error output, and recent changes.
Phase 2: Hypothesize
Form up to 3 ranked hypotheses. For each:
- State the hypothesis in one sentence
- Identify the single cheapest check that would confirm or refute it
- Do NOT start fixing yet
Phase 3: Verify
Test hypotheses in rank order. For each:
1. Run the cheapest check identified in Phase 2 2. If confirmed — move to Phase 4 3. If refuted — record what you learned and move to the next hypothesis
**3-strike rule:** If all 3 hypotheses fail, step back and re-collect. Do not keep guessing. Re-read the code path more carefully, expand the search area, or check for environmental factors (config, dependencies, platform).
Phase 4: Fix
Only after root cause is confirmed:
1. Write the minimal fix that addresses the root cause 2. Do not refactor surrounding code 3. Do not add speculative defensive checks 4. Run the test suite to verify the fix and check for regressions
Phase 5: Verify and Report
1. Confirm the original symptom is resolved 2. Confirm no regressions were introduced 3. Summarize: root cause, fix applied, evidence of resolution
Rules
- Never skip Phase 1-3 and jump to fixing
- Never change tests to match broken behavior
- If the bug is in a dependency or environment, report it — do not patch around it silently
- If you cannot reproduce the issue, say so and explain what you tried
Read more
name: investigate description: >- Systematic debugging skill. Use when encountering a bug, test failure, unexpected behavior, or when asked to "investigate", "debug", "diagnose", or "figure out why". Enforces root-cause-first discipline with structured hypothesis tracking.
Investigate
Systematic debugging workflow. Do not guess-and-fix — find the root cause first.
Phase 1: Collect
Gather all available evidence before forming any hypothesis.
1. Read the error message, stack trace, or symptom description exactly as given 2. Identify the affected code path — read the relevant source files 3. Check `git log --oneline -20` in the affected area for recent changes 4. If reproducible, reproduce the issue and capture the exact output 5. List what you know and what you do not know
Deliverable: a structured symptom summary with affected files, error output, and recent changes.
Phase 2: Hypothesize
Form up to 3 ranked hypotheses. For each:
- State the hypothesis in one sentence
- Identify the single cheapest check that would confirm or refute it
- Do NOT start fixing yet
Phase 3: Verify
Test hypotheses in rank order. For each:
1. Run the cheapest check identified in Phase 2 2. If confirmed — move to Phase 4 3. If refuted — record what you learned and move to the next hypothesis
**3-strike rule:** If all 3 hypotheses fail, step back and re-collect. Do not keep guessing. Re-read the code path more carefully, expand the search area, or check for environmental factors (config, dependencies, platform).
Phase 4: Fix
Only after root cause is confirmed:
1. Write the minimal fix that addresses the root cause 2. Do not refactor surrounding code 3. Do not add speculative defensive checks 4. Run the test suite to verify the fix and check for regressions
Phase 5: Verify and Report
1. Confirm the original symptom is resolved 2. Confirm no regressions were introduced 3. Summarize: root cause, fix applied, evidence of resolution
Rules
- Never skip Phase 1-3 and jump to fixing
- Never change tests to match broken behavior
- If the bug is in a dependency or environment, report it — do not patch around it silently
- If you cannot reproduce the issue, say so and explain what you tried
Your terminals, on an infinite canvas. TermCanvas spreads all your terminals across an infinite spatial canvas — no more tabs, no more split panes. Drag them around, zoom in to focus, zoom out to see the big picture.
Repo: blueberrycongee/termcanvas
Other skills on termcanvas.
- /challenge
Adversarial review skill. Use when the user wants to stress-test an idea, argument, proposal, or opinion from multiple independent angles. Spawns parallel Hydra workers with orthogonal analytical methodologies.
Open skill - /code-review
Structured code review skill. Use when asked to "review this code", "review this PR", "check this diff", or when acting as a Hydra reviewer. Runs a multi-pass review with specialist focus areas and confidence-gated findings.
Open skill - /hydra
Use when a task should run through Hydra's Lead-driven workflow for multi-agent orchestration, or when an existing workflow must be inspected or cleaned up.
Open skill - /qa
QA testing skill with real browser automation. Use when asked to "test this site", "QA this page", "check for visual bugs", "verify the deploy", or when Hydra needs browser validation for UI changes. Requires the browse binary.
Open skill - /security-audit
Security audit skill. Use when asked to "audit security", "check for vulnerabilities", "security review", "pentest", or when evaluating code that handles auth, user input, secrets, or external data. Runs a phased scan covering OWASP Top 10 and STRIDE threat modeling.
Open skill - /using-termcanvas
Use when starting work in a TermCanvas-managed repo to route between direct work, Hydra, or a narrow TermCanvas skill.
Open skill

