diagnose

Diagnose hard bugs and performance regressions through a structured reproduce-hypothesise-fix workflow.

1|2|Updated Nov 25, 2017
One-click install
npx skills add https://github.com/asarchami/dotfiles --skill diagnose-asarchami
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: diagnose
Source: https://github.com/asarchami/dotfiles/tree/main/dot_config/opencode/skills/diagnose
Command: npx skills add https://github.com/asarchami/dotfiles --skill diagnose-asarchami

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve? Hard bugs and performance regressions resist casual debugging because developers jump to fixes without a reliable reproduction signal. This Skill enforces a disciplined six-phase loop — build a feedback loop, reproduce, hypothesise, instrument, fix with regression test, and clean up — so root causes are found systematically instead of guessed. ## Core Features & Use Cases - Feedback loop construction: Ten ranked strategies for building a fast, deterministic pass/fail signal, from failing tests and CLI invocations to Playwright scripts, fuzz loops, and git bisect harnesses. - Ranked hypothesis testing: Generates 3-5 falsifiable hypotheses with explicit predictions before testing, then instruments one variable at a time using delve breakpoints or tagged slog logs. - Go debugging toolchain: Covers go test -run patterns, -count for flakiness, -race detection, delve, pprof benchmarks, and GODEBUG environment variables. - Use Case: A Go service intermittently returns wrong order data. The Skill guides you to build a 100-iteration test loop that reproduces the flake at a high rate, rank hypotheses about caching vs. concurrency, instrument with tagged logs, and land a regression test at the correct seam. ## Quick Start Ask the agent to diagnose the bug where the export endpoint intermittently returns stale data and have it build a reproduction loop first.

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 that only fails sometimes?

Raise the reproduction rate instead of chasing a clean repro: loop the trigger 100 times with go test -count=100, parallelise, add stress, or inject sleeps to narrow timing windows. A 50%-flake bug is debuggable; a 1% flake is not, so keep increasing the rate until hypotheses can be tested against it.

How do I find the root cause of a performance regression in Go?

Establish a baseline measurement first using go test -bench with pprof CPU profiles, then bisect between versions. For performance work, measure before fixing — logs are usually the wrong tool, and GODEBUG=gctrace=1 helps when GC behavior is suspect.

What is the best way to use git bisect for bug hunting?

Use git bisect run with a script that executes go test -run <pattern> and checks the exit code, turning bisection into an automated feedback loop. This works when the bug appeared between two known commits and you have a deterministic pass/fail signal.

Why should I write the regression test before the fix?

Writing the test first proves it actually exercises the real bug pattern at a correct seam — you watch it fail, apply the fix, then watch it pass. If no correct seam exists, that absence is itself a finding indicating the architecture needs a refactoring to make the bug lockdown possible.

What should I do when a bug cannot be reproduced locally?

Stop and say so explicitly rather than hypothesising blind. Ask the user for environment access, a captured artifact such as an API response dump or stack trace, or permission to add temporary instrumentation — or use the human-in-the-loop script template to structure manual reproduction.