A bug triage skill: four investigators and an evidence check

Debugging with one agent tends to lock onto the first theory. Here four subagents look at the same report from different sides at once, and a verifier in a fresh context accepts a root cause only when evidence ties it to the symptom and the repro reproduces it.

7 steps in 4 stages · 7 subagents · a kit of 12 files

Free. Built in your browser; nothing is uploaded. No API key, no account.

How it runs

Steps in the same stage start at the same time. Each subagent gets only what its incoming edges carry, and a step in a fresh context never sees the reasoning of the steps before it. A gate decides whether the work passes, and a failed gate re-runs the work it checks.

  1. Stage 1
    • Split · Planner

      sonnet · Read

  2. Stage 24 in parallel
    • Stack Trace Analyzer · Worker

      haiku · Read, Grep, Glob, Bash

    • Log / Metric Correlator · Worker

      haiku · Read, Grep, Glob, Bash

    • Commit Inspector · Worker

      haiku · Read, Grep, Glob, Bash

    • Minimal Repro Builder · Worker

      haiku · Read, Grep, Glob, Bash

  3. Stage 3
    • VERIFIER (Fresh Context) · Checker

      opus · Read, Grep, Glob · fresh context

      Gate: At least one hypothesis is connected to the symptom by evidence, and the repro reproduces it.

  4. Stage 4
    • Final answer · Writer

      sonnet · Read

Use it when

  • You paste a bug report or stack trace and want a diagnosis, not a guess.
  • The cause could be in the code, the logs or a recent change.
  • You want a test plan that proves the fix.

Change these first

  • Drop the log investigator if your bugs come without logs.
  • Narrow the workers' Bash to the commands you allow, for example Bash(git log:*).

Need a workflow built for your team? Fixed-price packages

What you get

An orchestrating SKILL.md, one Claude Code subagent per step with its own tools and model, and the same skill as a Cursor rule. Your agent runs it with its own subagents; nothing on this site calls a model.

bug-triaging-graph-skill-kit.zip12 files
  • .claude/skills/bug-triaging-graph/SKILL.mdorchestrator
  • .claude/skills/bug-triaging-graph/graph.skill.mdgraph source
  • .claude/agents/bug-triaging-graph-splitter.mdsubagent
  • .claude/agents/bug-triaging-graph-stack-trace.mdsubagent
  • .claude/agents/bug-triaging-graph-logs-metrics.mdsubagent
  • .claude/agents/bug-triaging-graph-commits.mdsubagent
  • .skill-graph/.gitignoresupport
  • .cursor/rules/bug-triaging-graph.mdcCursor rule
  • README.mdreadme
  • + 3 more subagents
.claude/skills/bug-triaging-graph/SKILL.md
---
name: bug-triaging-graph
description: "Triages a bug report with four parallel investigators, re-checks the evidence in a fresh context, and writes a root-cause diagnosis with a test plan."
---

# bug-triaging-graph

Triages a bug report with four parallel investigators, re-checks the evidence in a fresh context, and writes a root-cause diagnosis with a test plan.

This skill is a graph: each step has its own prompt and context, and only the payloads named below move between steps.

## Plan

Run the stages in order. Every model step runs in its own subagent; do not do a step's work yourself. Only command steps and approvals are yours to run. Steps in the same stage do not depend on each other: start them together, in one message with several subagent calls.

The input (`goal`) is the user's goal: their request, word for word, handed on under `### goal`. Ask for it if the user has not given one.

### Stage 1 · 1 step

- **SPLIT** (`splitter`) → subagent `bug-triaging-graph-splitter`
  - Hand it: the user's goal.
  - Expect: `subtask_json` (json).
  - Contract check (`subtask_json`): save its output to `.skill-graph/bug-triaging-graph/splitter.json`, then run `node -e "const fs=require('fs');const d=JSON.parse(fs.readFileSync(process.argv[1],'utf8'));const k=['stack_trace','logs_metrics','commits','repro'];const ok=d!==null&&typeof d==='object'&&Array.isArray(d)===false;const m=ok?k.filter((x)=>Object.hasOwn(d,x)===false):k;if(m.length>0){console.error('Missing keys: '+m.join(', '));process.exit(1)}" .skill-graph/bug-triaging-graph/splitter.json` with Bash. Exit code 0 passes.
  - If a contract check fails: re-run this step once with its previous answer and the error output. If it fails again, stop and show the user the output.

### Stage 2 · 4 steps in parallel

- **Stack Trace Analyzer** (`stack_trace`) → subagent `bug-triaging-graph-stack-trace`
  - Hand it: only the `stack_trace` value from the JSON of SPLIT (`splitter`).
  - Expect: `hypotheses` (markdown).
- **Log / Metric Correlator** (`logs_metrics`) → subagent `bug-triaging-graph-logs-metrics`
  - Hand it: only the `logs_metrics` value from the JSON of SPLIT (`splitter`).
  - Expect: `hypotheses` (markdown).
- **Commit Inspector** (`commits`) → subagent `bug-triaging-graph-commits`
  - Hand it: only the `commits` value from the JSON of SPLIT (`splitter`).
  - Expect: `hypotheses` (markdown).
- **Minimal Repro Builder** (`repro`) → subagent `bug-triaging-graph-repro`
  - Hand it: only the `repro` value from the JSON of SPLIT (`splitter`).
  - Expect: `hypotheses` (markdown).


… 37 more lines in the kit

Or let Claude adapt it

Add Skill Graph to Claude Code as a connector, then ask. Claude loads this starter, changes it for your project, checks it and hands you the kit.

Set up the connector

Ask Claude

Use Skill Graph: get the bug-triaging-graph template, adapt it to this project, validate it until it has no errors, and compile it for Claude Code.

The graph file

The whole workflow is one Markdown file, graph.skill.md: the steps and edges in the frontmatter, one prompt per step below it. The guide explains every field.

graph.skill.md · 154 lines
---
name: bug-triaging-graph
description: Triages a bug report with four parallel investigators, re-checks the evidence in a fresh context, and writes a root-cause diagnosis with a test plan.
spec: skill-graph/1
topology:
  nodes:
    - id: goal
      type: input
      label: BUG REPORT
    - id: splitter
      type: orchestrator
      label: SPLIT
      model: sonnet
      tools:
        - Read
    - id: stack_trace
      type: worker
      label: Stack Trace Analyzer
      model: haiku
      tools:
        - Read
        - Grep
        - Glob
        - Bash
    - id: logs_metrics
      type: worker
      label: Log / Metric Correlator
      model: haiku
      tools:
        - Read
        - Grep
        - Glob
        - Bash
    - id: commits
      type: worker
      label: Commit Inspector
      model: haiku
      tools:
        - Read
        - Grep
        - Glob
        - Bash
    - id: repro
      type: worker
      label: Minimal Repro Builder
      model: haiku
      tools:
        - Read
        - Grep
        - Glob
        - Bash
    - id: verifier
      type: verifier
      label: VERIFIER (Fresh Context)
      isolated_context: true
      model: opus
      tools:
        - Read
        - Grep
        - Glob
      gate: At least one hypothesis is connected to the symptom by evidence, and the repro reproduces it.
      on_fail: retry
      max_retries: 1
    - id: merger
      type: synthesizer
      label: FINAL ANSWER
      model: sonnet
      tools:
        - Read
  edges:
    - from: goal
      to: splitter
    - from: splitter
      to:
        - stack_trace
        - logs_metrics
        - commits
        - repro
      contract: subtask_json
    - from:
        - stack_trace
        - logs_metrics
        - commits
        - repro
      to: verifier
      contract: hypotheses
    - from: verifier
      to: merger
      contract: root_cause
contracts:
  subtask_json:
    format: json
    description: One key per worker id; each value is that worker's task.
  hypotheses:
    format: markdown
    description: A numbered list; every item has its evidence and a confidence of high, medium or low.
  root_cause:
    format: markdown
    description: Only the items that passed verification, then the rejected ones with the reason.
---

# Node Prompts & Edge Contracts

## @node: splitter
You are the triage lead. Split the bug report into four investigation tasks.

Input:
{{goal}}

Output strictly as JSON with one key per worker: `stack_trace`, `logs_metrics`, `commits`, `repro`. Each value is the exact task for that worker.

## @node: stack_trace
Analyze ONLY the stack trace and error: the failing frame, the inputs that reach it, and why it throws.

Your task: {{splitter.stack_trace}}

Return findings as a numbered list. For each one give the evidence (file, line, quote or source) and a confidence of high, medium or low.

## @node: logs_metrics
Correlate ONLY logs and metrics: when it started, what changed at that time, and which users or requests are affected.

Your task: {{splitter.logs_metrics}}

Return findings as a numbered list. For each one give the evidence (file, line, quote or source) and a confidence of high, medium or low.

## @node: commits
Inspect ONLY recent commits and config changes that touch the failing path, and rank them by likelihood.

Your task: {{splitter.commits}}

Return findings as a numbered list. For each one give the evidence (file, line, quote or source) and a confidence of high, medium or low.

## @node: repro
Build ONLY a minimal reproduction: the smallest steps or script that trigger the bug.

Your task: {{splitter.repro}}

Return findings as a numbered list. For each one give the evidence (file, line, quote or source) and a confidence of high, medium or low.

## @node: verifier
You are an independent debugger. Check that the evidence actually connects each hypothesis to the symptom; reject the rest.

You only see the raw worker outputs below, not their reasoning. Drop any claim without concrete evidence, merge duplicates, and mark what you rejected and why.

Original input: {{goal}}

Worker outputs:
{{workers.output}}

## @node: merger
Write the diagnosis: root cause, evidence, fix, and a test plan that reproduces the bug before the fix and passes after it.

{{verifier.output}}