investigate
SolidInvestigate code debugging and root-cause narrowing; use measurable gates before fixes.
Install
Quality Score: 81/100
Skill Content
Details
- Author
- Borda
- Repository
- Borda/AI-Rig
- Created
- 5 months ago
- Last Updated
- today
- Language
- Python
- License
- Apache-2.0
Similar Skills
Semantically similar based on skill content — not just same category
investigate
Use when a failure's cause is unknown — a bug, a failing test, "why is this broken", "it worked yesterday", a tripped circuit breaker (3 failed fixes), or any moment a fix is about to be attempted without a reproduced root cause.
investigate
Investigate, diagnose, RCA, "why is X slow/broken/down", "what changed" for any production symptom. Triggers on a free-text symptom + service, a Datadog incident/monitor/dashboard/log URL, a Slack alert permalink, a Statsig gate/experiment URL, or a Mixpanel/Snowflake/Looker question. Read-only — never modifies a monitor, dashboard, flag, or experiment, and never triggers a rollback or restart (recommends; the human executes). Pins an explicit time window on every query, correlates >=2 independent signals before naming a root cause, and states confidence (low/med/high) with anchored evidence and <=15-word verbatim quotes. Produces a timeline + hypothesis + a lowest-blast-radius next action.
investigate
Deep root cause analysis engine for defects whose cause is genuinely unknown. Runs an 8-phase diagnostic protocol — observe, reproduce, trace, hypothesize, prove, root cause, fix, prevent — using sequential-thinking MCP, multi-pass code reading, git forensics, competing hypotheses, and the 5 Whys, proving the cause with evidence before any fix. Returns a proven root-cause report; the fix runs only after that diagnosis is approved. Use when the user runs /investigate, or when a bug, crash, exception, stack trace, regression, flaky or intermittent failure, data corruption, memory leak, or unexplained slowness needs its root cause found and nobody knows why. Expensive — do not select it when the cause is already known, for a typo, syntax, import or config mistake, for a feature request or refactor, for "what does this code do", or for applying a fix the user already chose; handle those directly. For a live production outage, route to incident-commander first and investigate after service is restored.