diagnose
Use when a bug or performance issue is still fuzzy — build the fastest feedback loop first, rank the leading hypotheses, and instrument only what narrows the search
Best use case
diagnose is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Use when a bug or performance issue is still fuzzy — build the fastest feedback loop first, rank the leading hypotheses, and instrument only what narrows the search
Teams using diagnose should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/diagnose/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How diagnose Compares
| Feature / Agent | diagnose | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Use when a bug or performance issue is still fuzzy — build the fastest feedback loop first, rank the leading hypotheses, and instrument only what narrows the search
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Diagnose Diagnose is for problems that are still poorly shaped. Before deep debugging, build the smallest feedback loop that proves whether each change helps or hurts. A fast loop usually does more for bug finding than another round of guesswork. ## When to Use - The symptom is real, but the shortest reliable repro is still unclear - A bug, regression, or performance issue needs a faster test loop before fixing - Multiple causes seem plausible and you need to rank them instead of chasing all of them - The system is large enough that targeted instrumentation beats broad logging ## When NOT to Use | Instead of diagnose | Use | |---------------------|-----| | You already have a stable repro and need root-cause discipline | `systematic-debugging` | | The failure is a compiler, type, or dependency error | `fix-build-errors` | | The issue is security-sensitive | `security-scan` or `pr-security-review` | ## The 6-Step Loop ### 1. Build the feedback loop first Create the fastest signal that tells you whether you are closer to the answer: - a narrow failing test - a single command that reproduces the symptom - a benchmark or script with stable inputs If a proposed fix does not improve that loop, it is too early to trust it. ### 2. Reproduce Capture the exact symptom, input, and environment. Shrink it until it is cheap to rerun. ### 3. Rank 3-5 hypotheses Do not hold one vague hunch in your head. Write a short ranked list: 1. most likely 2. plausible alternative 3. annoying edge case Then test them in order, demoting the ones the evidence weakens. ### 4. Instrument narrowly Add only the probes needed to separate the top hypotheses. Prefer: - one focused log or metric - one temporary assertion - one small trace around the suspect boundary Avoid "log everything" unless you have no tighter cut. ### 5. Fix and add the regression check Once one hypothesis is confirmed, make the smallest durable fix and lock it in with the same feedback loop that exposed it. ### 6. Clean up and record the root cause Remove temporary probes and write down: - what the real failure was - which signal exposed it - what regression check now protects it ## Common Rationalizations | Rationalization | Reality | |----------------|---------| | "I'll know the bug when I see it." | Without a loop, every change feels equally plausible. | | "I need more logs everywhere." | Untargeted logs create noise faster than clarity. | | "I only have one theory." | Rank multiple hypotheses so the next test actually rules something out. | ## Red Flags - The repro still depends on manual luck - You are editing code before defining the loop that will prove the fix - Logs keep growing, but no hypothesis gets ruled out - You cannot explain why hypothesis #1 beats hypothesis #2 ## Verification - [ ] The feedback loop is fast enough to run repeatedly - [ ] 3-5 concrete hypotheses were ranked - [ ] Instrumentation was targeted, not broad and permanent - [ ] The final fix is covered by a regression check ## See Also - [`systematic-debugging`](../systematic-debugging/SKILL.md) — deeper 4-phase root-cause workflow once the loop exists - [`performance-optimization`](../performance-optimization/SKILL.md) — measurement-driven performance work - [`tdd-workflow`](../tdd-workflow/SKILL.md) — turn the repro into a durable failing test
Related Skills
verification-before-completion
Use before claiming any task is done — run the exact command that proves the fix works, read the output, and only then report success.
using-git-worktrees
Use when you need multiple branches checked out at once — create isolated working directories for parallel development without cloning the repository repeatedly
triage
Use when a single issue needs structured triage — classify it, reproduce if needed, request missing information, and leave a durable brief or close-out note in the tracker.
to-issues
Use when a plan, spec, or PRD must become an actionable backlog — break it into thin dependency-aware issues that each deliver a verifiable vertical slice
sprint-workflow
Use when starting a new feature, refactor, or multi-step dev task — runs the full sprint cycle (Think → Plan → Build → Review → Test → Ship → Monitor) using Copilot CLI's plan/autopilot modes.
sprint-retro
Use at the end of a sprint to run a data-driven retrospective — analyzes session history and git metrics to surface what shipped, what slowed you down, and concrete improvements.
security-audit
Use when a codebase needs a formal security audit beyond a quick scan — applies OWASP Top 10 and STRIDE threat modeling from a CSO perspective to surface systemic vulnerabilities.
release
Use when a sprint or feature is complete and ready to ship — tags the version, generates GitHub Release notes, runs rollout or smoke verification, and publishes to npm/PyPI/Docker registries.
prompt-optimizer
Use when a rough prompt, vague idea, or task description needs to become a finished copy-pasteable prompt for a chat-based LLM - rewrite it into one ready-to-send prompt with no blanks, no placeholders, and a clear output shape.
outside-voice
Use when you need an independent second opinion before, during, or after implementation — run challenge, consult, or review mode in a direct builder-to-builder voice
llm-wiki
Use when research or domain knowledge keeps getting rediscovered across sessions — build a supplementary markdown wiki that compounds synthesized knowledge without replacing GitHub or committed project guidance
interview-me
Use when a request is underspecified and you need to discover what the user actually wants before writing a plan, spec, or code - ask one question at a time, attach your current hypothesis, and stop only after the intent is explicitly confirmed.