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

8 stars

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

$curl -o ~/.claude/skills/diagnose/SKILL.md --create-dirs "https://raw.githubusercontent.com/drvoss/everything-copilot-cli/main/skills/development/diagnose/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/diagnose/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How diagnose Compares

Feature / AgentdiagnoseStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/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

8
from drvoss/everything-copilot-cli

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

8
from drvoss/everything-copilot-cli

Use when you need multiple branches checked out at once — create isolated working directories for parallel development without cloning the repository repeatedly

triage

8
from drvoss/everything-copilot-cli

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

8
from drvoss/everything-copilot-cli

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

8
from drvoss/everything-copilot-cli

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

8
from drvoss/everything-copilot-cli

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

8
from drvoss/everything-copilot-cli

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

8
from drvoss/everything-copilot-cli

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

8
from drvoss/everything-copilot-cli

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

8
from drvoss/everything-copilot-cli

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

8
from drvoss/everything-copilot-cli

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

8
from drvoss/everything-copilot-cli

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.