investigate
Skill2 starsChanged 8 months agoMITView on GitHub
Deep investigation of bugs, performance issues, or unexpected behavior. TRIGGER THIS SKILL when users report bugs, errors, performance regressions, unexpected behavior, or ask to investigate, debug, diagnose, or find the root cause of any issue — whether they say "why is this broken", "investigate this bug", "find the root cause", "debug this issue", "this is failing and I don't know why", "performance degraded", or share error messages and stack traces. Do NOT trigger for feature requests, code reviews, refactoring, or general code questions.
We split this skill into the rules it gives an agent
6 rules. 0 are common, 5 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 110 edited versions we read keep these.
5
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 47
Wait for both agents to complete.
- Distinctive: line 109
Wait for all four agents to complete.
- Distinctive: line 136
Wait for all hypothesis agents to complete.
- Very specific: line 219
Wait for both agents to complete.
- Distinctive: line 234
Create the smallest possible test case that reproduces the issue.
- Distinctive: line 241
IMPORTANT: If any tests fail during investigation, they must be fixed.
“Common” is measured: kept by at least 6 in 10 of the 110 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Deep Investigation
Thorough investigation of issues with root cause analysis and recommendations.
OUTPUT: Detailed report with findings, root cause, and recommendations.
Arguments
$ARGUMENTS- Issue description, error message, or area to investigate
Phase 1: Define the Problem (Parallel: Hypotheses + Data Gathering)
Launch two parallel agents immediately. Both can work simultaneously since forming hypotheses from the issue description is independent from gathering raw data.
Agent 1 - Hypotheses Formation:
Analyze the issue description:
$ARGUMENTSForm 3-5 ranked hypotheses about what might be causing this issue. For each hypothesis, state:
- The suspected cause
- Why this is plausible given the symptoms
- What evidence would confirm or refute it
Return a numbered list of hypotheses with supporting reasoning.
Agent 2 - Data Gathering:
Gather all available data about:
$ARGUMENTSCollect in parallel where possible:
- Error messages and stack traces (search logs, output files, CI artifacts)
- Recent changes to affected areas (
git log --oneline -30 -- path/to/affected/)- Related issues or discussions (search issue trackers if available)
- Current state of affected code paths (read the relevant source files)
- Environment and configuration state
Return all raw findings organized by category.
Wait for both agents to complete. Combine their outputs to form the investigation plan for Phase 2.
Phase 2: Evidence Collection (Parallel: 4 Independent Agents)
Launch four parallel agents, one per evidence dimension. These are completely independent investigations that share no dependencies.
Agent 1 - Code Analysis:
Investigate the code paths related to:
$ARGUMENTSUsing the hypotheses: [insert hypotheses from Phase 1]
Analyze:
- All code paths involved in the issue (read source files, trace call chains)
- Recent changes to affected areas (
git log -p --since="2 weeks ago" -- path/to/affected/)- Dependencies and their versions
- Integration points between components
- Any relevant design patterns or architectural decisions that could contribute
For each hypothesis, note which code evidence supports or contradicts it. Return detailed code-level findings with exact file paths and line numbers.
Agent 2 - Log and Error Analysis:
Analyze logs and error output related to:
$ARGUMENTSSearch for:
- Error patterns matching the reported symptoms (use Grep across log files)
- Timestamp correlations (what happened before, during, and after the error)
- Frequency and distribution of errors
- Stack traces and their common frames
- Warning messages that might indicate preconditions
Return a timeline of events and all error patterns found, with file locations.
Agent 3 - Test Behavior:
Investigate test behavior related to:
$ARGUMENTSPerform:
- Run existing tests for affected areas and capture results
- Write a minimal exploratory test that attempts to reproduce the issue
- Check test coverage of the affected code paths
- Look for flaky tests or tests with known issues in the affected area
- Try to create the smallest possible reproduction case
Return test results, reproduction status, and any newly written test code.
Agent 4 - External Factors:
Investigate external factors related to:
$ARGUMENTSCheck:
- Database state and schema (if applicable)
- Third-party service status and API changes
- Configuration differences between working and broken environments
- Environment variables and their values
- Infrastructure or platform changes (OS updates, dependency updates, CI changes)
- Network conditions or connectivity issues
Return all external factor findings, noting which factors changed recently.
Wait for all four agents to complete. Merge all evidence into a unified evidence set.
Phase 3: Root Cause Analysis (Parallel: Hypothesis Testing)
Launch one parallel agent per hypothesis from Phase 1. Each agent independently evaluates a single hypothesis against the full evidence set from Phase 2.
For each hypothesis, launch an agent:
Evaluate hypothesis: "[Hypothesis N description]"
Against collected evidence: [Insert merged evidence from Phase 2]
Perform:
- List all evidence that supports this hypothesis
- List all evidence that contradicts this hypothesis
- Attempt to definitively prove or disprove it (run targeted commands, read specific code, write a focused test)
- If the code path can be traced, follow it from entry point through data transformations, decision points, to exit/error point
- Rate confidence: HIGH / MEDIUM / LOW with justification
Distinguish between:
- Proximate cause: The immediate trigger
- Root cause: The underlying issue
- Contributing factors: Things that made it worse
Return: verdict (confirmed/refuted/inconclusive), confidence level, all supporting evidence, and the causal chain if confirmed.
Wait for all hypothesis agents to complete. Select the hypothesis with the strongest evidence as the root cause. If multiple hypotheses are confirmed, determine whether they are independent issues or parts of the same causal chain.
Phase 4+5: Documentation and Recommendations (Parallel: 2 Agents)
Launch two parallel agents. The report structure and the recommendations are independent deliverables that draw from the same evidence.
Agent 1 - Investigation Report:
Write a complete investigation report for:
$ARGUMENTSUsing root cause: [insert root cause from Phase 3] Using evidence: [insert evidence from Phase 2] Using hypothesis results: [insert results from Phase 3]
Format:
# Investigation Report: [Issue Title] **Date:** [date] **Investigator:** Claude Code **Status:** Complete ## Summary [One paragraph summary of the issue and root cause] ## Problem Statement [What was reported/observed] ## Investigation Steps ### Step 1: [What was checked] **Finding:** [What was discovered] ### Step 2: [What was checked] **Finding:** [What was discovered] ... ## Root Cause [Detailed explanation of the root cause, distinguishing proximate cause, root cause, and contributing factors] ## Evidence - [Evidence 1 with file:line references] - [Evidence 2 with file:line references] ## Contributing Factors - [Factor 1] - [Factor 2] ## Appendix ### Code References - `file1.kt:123` - [description] - `file2.kt:456` - [description] ### Timeline - [timestamp] - [event] - [timestamp] - [event]
Agent 2 - Recommendations and Prevention:
Based on root cause: [insert root cause from Phase 3] And evidence: [insert evidence from Phase 2]
Produce two deliverables:
1. Prioritized Actions:
- Critical - Must do immediately to resolve the issue
- Important - Should do soon to prevent recurrence
- Nice to have - Consider for future resilience
For each action, include specific code changes, file paths, and implementation details.
2. Prevention Plan:
- Testing improvements (specific tests to add, coverage gaps to fill)
- Monitoring and alerting (what metrics to watch, what thresholds to set)
- Code review focus areas (patterns to watch for in future reviews)
- Documentation updates (what to document, where)
Return both deliverables with concrete, actionable items.
Wait for both agents to complete. Merge the recommendations into the report under a ## Recommendations section.
Investigation Techniques Reference
These techniques may be used by any agent during any phase:
Binary Search (Git Bisect)
git bisect start
git bisect bad HEAD
git bisect good <known-good-commit>
# Test each commit until culprit foundMinimal Reproduction
Create the smallest possible test case that reproduces the issue. Prefer an automated test over manual steps.
Compare Working vs Broken
Diff configurations, code versions, and environments between working and broken states.
Test Failure Policy
IMPORTANT: If any tests fail during investigation, they must be fixed. There is no such thing as a "pre-existing" test failure - all test failures must be resolved before the task is considered complete. The task always completes with completely passing tests.
Completion Criteria
- Problem clearly defined
- Evidence collected from all four dimensions (code, logs, tests, external)
- All hypotheses evaluated with evidence-backed verdicts
- Root cause identified with confidence level
- Report written with full code references and timeline
- Recommendations provided with specific, actionable items
- ALL tests pass (no exceptions for "pre-existing" failures)
Other versions124 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 124
- garrytan/gstack★ 139ksame name
- recharts/recharts★ 28ksame name
- gitkraken/vscode-gitlens★ 10ksame name
- vercel/eve★ 5.8ksame name
- rilldata/rill★ 3ksame name
- DenchHQ/DenchClaw★ 1.7ksame name
- DenchHQ/ironclaw★ 1.7ksame name
- ceedaragents/cyrus★ 882same name
- cyrusagents/cyrus★ 882same name
- rommapp/argosy-launcher★ 704same name
114 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use ios-clean, ios-fix and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
Saqlain-811Skillios-clean
Remove the DebugBridge SPM package and all #if DEBUG wiring from an iOS app. (gstack)
Also in 5 projects that use this
Saqlain-811Skillios-fix
Autonomous iOS bug fixer. (gstack)
Also in 5 projects that use this
seek888Skillpair-agent
Pair a remote AI agent with your browser. One command generates a setup key and prints instructions the other agent can follow to connect. Works with OpenClaw, Hermes, Codex, Cursor, or any agent that can make HTTP requests. The remote agent gets its own tab with scoped access (read+write by default, admin on request). Use when asked to "pair agent", "connect agent", "share browser", "remote browser", "let another agent use my browser", or "give browser access". (gstack) Voice triggers (speech-to-text aliases): "pair agent", "connect agent", "share my browser", "remote browser access".
Also in 10 projects that use this
ShreyRaviSkilllanding-report
Read-only queue dashboard for workspace-aware ship. Shows which VERSION slots are currently claimed by open PRs, which sibling Conductor workspaces have WIP work likely to ship soon, and what slot /ship would pick next. No mutations — just a snapshot. Use when asked to "landing report", "what's in the queue", "show me open PRs", or "which version do I claim next". (gstack)
Also in 7 projects that use this
seek888Skillopen-gstack-browser
Launch GStack Browser — AI-controlled Chromium with the sidebar extension baked in. Opens a visible browser window where you can watch every action in real time. The sidebar shows a live activity feed and chat. Anti-bot stealth built in. Use when asked to "open gstack browser", "launch browser", "connect chrome", "open chrome", "real browser", "launch chrome", "side panel", or "control my browser". Voice triggers (speech-to-text aliases): "show me the browser".
Also in 8 projects that use this
ShreyRaviSkillsetup-gbrain
Set up gbrain for this coding agent: install the CLI, initialize a local PGLite or Supabase brain, register MCP, capture per-remote trust policy. One command from zero to "gbrain is running, and this agent can call it." Use when: "setup gbrain", "connect gbrain", "start gbrain", "install gbrain", "configure gbrain for this machine". (gstack)
Also in 6 projects that use this
- +2 more from Saqlain-811
- +2 more from ShreyRavi
- +1 more from seek888
In this repository9 other files it gives its agents.
- alphaxiv-paper-lookupSkill
- auto-researchSkill
- code-explainerSkill
- debugSkill
- frontend-designSkill
- guided-learningSkill
- opentuiSkill
- pdfSkill
- slide-deckSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

