diagnose

Diagnose hard bugs and performance regressions through an evidence-driven feedback loop.

5|Updated May 21, 2026
One-click install
npx skills add https://github.com/TrebuchetDynamics/pi-package-goal --skill diagnose-trebuchetdynamics
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: diagnose
Source: https://github.com/TrebuchetDynamics/pi-package-goal/tree/main/skills/diagnose
Command: npx skills add https://github.com/TrebuchetDynamics/pi-package-goal --skill diagnose-trebuchetdynamics

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve?

Diagnose helps you systematically track down the root cause of hard bugs and performance regressions by forcing a reproducible feedback loop before you hypothesize or change code.

Core Features & Use Cases

  • Reproduction-first discipline: Build a deterministic pass/fail signal (test, script, trace replay, harness) and refuse to proceed without it.
  • Ranked, falsifiable hypotheses: Generate 3–5 predictions and verify each by instrumenting only what distinguishes them.
  • Regression safety: Create a failing regression test at the correct seam before applying the fix, then confirm the original scenario no longer reproduces.
  • Evidence-driven handoffs: Hand off to TDD, architecture improvement, prototype harnesses, or extension helpers when the right loop or seam doesn’t exist yet.
  • Built-in references: Use quick paths for common local Codex storage failures and for auditing Pi goal logs across repositories.

Quick Start

Run the diagnose loop by asking Pi to diagnose the failure and provide (or help you derive) a reproducible repro command or failing test signal.

Frequently Asked Questions about diagnose

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I debug a flaky test or performance regression systematically?

Debug flaky tests and performance regressions by building an evidence-driven diagnosis loop that establishes a deterministic pass/fail signal before hypothesizing or changing code. Generate ranked falsifiable predictions, instrument specifically to distinguish them, and verify the fix.

What is root-cause-analysis for hard bugs when reproduction is difficult?

Root-cause-analysis for hard bugs uses a reproduction-first discipline, requiring a deterministic repro command, trace replay, or disposable harness to establish a clear signal. It refuses to proceed with hypothesis testing until a reliable trigger exists.

How do I create a regression test at the correct seam before applying a bug fix?

Create a failing regression test at the correct seam to capture the bug before applying a fix. Once the original scenario no longer reproduces, the test passes, ensuring the regression is verified and preventing future recurrences.

What's the best way to verify falsifiable hypotheses during debugging?

Verify falsifiable hypotheses during debugging by generating three to five ranked predictions and instrumenting only what distinguishes them. This evidence-driven approach targets specific variables within the diagnosis feedback loop to isolate the root cause.

Does this debugging approach work for failures requiring minimization or differential runs?

Yes, this debugging approach applies to scenarios requiring minimization, trace replay, differential runs, or disposable harnesses. It establishes a deterministic signal across failing, throwing, flaky, or slow behaviors.

When should I hand off to TDD or architecture improvement during root-cause-analysis?

Hand off to TDD, architecture improvement, or prototype harnesses during root-cause-analysis when the right diagnosis loop or test seam does not exist yet. This enables evidence-driven handoffs to establish the necessary deterministic feedback signal.