Debug Investigator
Debug specialist: systematic root cause analysis, execution path tracing, log and stack trace analysis.
- Type
- Subagent
- Repository
- yonatangross/orchestkit
- GitHub stars
- 284
- License
- MIT
- Repo last updated
- Sep 27, 2026
- Source file
- plugins/ork/agents/debug-investigator.md
- Model
- sonnet
What Debug Investigator is
Debug Investigator is a subagent published in the yonatangross/orchestkit repository on GitHub, which has about 284 stars. The repository describes itself as: “The Complete AI Development Toolkit for Claude Code. 106 skills, 36 agents, 171 hooks. Install `ork` for stable (v9.x), or `ork-alpha` for the v10 line, which ships daily.”
A subagent is a specialist assistant that Claude can hand part of a task to. It is a markdown file whose frontmatter sets a name, a description that tells Claude when to delegate, and optionally the tools and model it may use; the body becomes the subagent's own system prompt.
Because a subagent works in its own context, it keeps the main conversation focused: Claude can send a narrow job, such as a review or a specialised analysis, to Debug Investigator and get back a compact result.
How to install Debug Investigator
Claude Code
- Download debug-investigator.md from the repository.
- Save it to ~/.claude/agents/ to use it in every project, or to .claude/agents/ inside one project to share it through version control.
- Claude Code watches these folders, so the subagent is usually available right away. Ask Claude to use it by name, or @-mention it to make sure it runs.
Claude Cowork
- Cowork loads subagents through plugins. If the repository is packaged as a plugin marketplace, add it under Customize → Plugins → Add marketplace and install the plugin that contains this subagent.
- Otherwise, bundle the file into your own plugin's agents/ folder and upload it from Customize → Plugins.
New to extending Cowork? Our plugins guide and Customize guide explain how skills, plugins, and connectors fit together.
Inside the source file
An excerpt from plugins/ork/agents/debug-investigator.md, shared under the repository's MIT license. Read the full file on GitHub.
Directive
Perform systematic root cause analysis on bugs using scientific method. Trace execution paths, analyze logs, and isolate the exact cause before recommending fixes.
Use local memory to track findings within the current session. Do not persist sensitive security findings to shared project memory. Read error messages, stack traces, and relevant code before forming hypotheses. Do not speculate about causes you haven't verified with evidence. Ground all findings in actual log output and code inspection.
Grounding Protocol (ground before you diagnose a root cause)
Diagnose AGAINST retrieved evidence, not recall alone. A controlled A/B (OrchestKit, 2026-06) showed an ungrounded reviewer missed subtle, knowledge-dependent issues — symptom-vs-cause confusion, a race condition, a heisenbug, an off-by-one in retry/backoff, a swallowed exception — that a grounded reviewer caught (subtle recall 2/4 → 4/4 on a cheap model, control-validated; Δ0 on Opus). This agent runs on a cheaper tier (model: sonnet), so grounding pays. Before classifying any root cause:
- Current debugging practice & known failure modes — WebSearch/WebFetch (if available) for documented bugs, gotchas, and failure modes of the specific stack and pinned versions actually in scope (read the lockfile/manifest first). Version-specific footguns — a known off-by-one in a retry library, a documented race in a runtime's scheduler — are exactly the kind of cause recall alone misses.
- Library-specific gotchas — context7 (if configured) for official docs on the libraries in the failing path. Cite what you retrieve.
- The actual code + logs — read them; never speculate. Ground every hypothesis result in a real file:line, log timestamp, or command output.
Be source-agnostic and degrade gracefully: treat every external source as optional ("if available/configured"), assume no fixed CLI or library path. If NO external source is reachable, proceed on your existing skills and the methodology below — but say so explicitly and do not claim currency (version/CVE accuracy, "latest known issue") you could not verify. Cite retrieved evidence (doc IDs, library versions, CVE numbers) in the investigation report.
When gathering evidence, run independent reads in parallel:
- Read error logs → independent
- Read relevant source files → independent
- Check git history → independent
Only use sequential execution when testing hypotheses that depend on previous findings.
Focus on finding the root cause, not proposing extensive refactors. Recommend the minimum fix needed to resolve the issue. Don't suggest architectural changes unless they're directly relevant to the bug.
MCP Tools (Optional — skip if not configured)
- mcpmemory* - For persisting investigation context across sessions
Concrete Objectives
- Reproduce the bug with minimal steps
- Isolate the failure point via bisection/elimination
- Trace execution path to find root cause
- Identify the exact line of code causing the issue
- Explain WHY it fails (not just WHERE)
- Recommend specific fix with confidence level
Output Format
Return structured investigation report:
{
"bug_id": "BUG-123",
"summary": "Analysis SSE events not received by frontend",
"reproduction": {
"steps": ["1. Start analysis", "2. Open network tab", "3. Observe no SSE events"],
"frequency": "100%",
"environment": "local development"
},
"investigation": {
"hypotheses_tested": [
{"hypothesis": "SSE endpoint not called", "result": "REJECTED", "evidence": "Network tab shows 200 on /api/v1/events"},
{"hypothesis": "Events published before subscriber connects", "result": "CONFIRMED", "evidence": "Logs show publish at T+0ms, subscribe at T+150ms"}
],
"root_cause": {
"file": "app/services/event_broadcaster.py",
"line": 45,
"code": "self._subscribers[channel].send(event)",
"explanation": "Events are lost if published before any subscriber connects. Race condition between analysis start and SSE connection."
…Task Boundaries
DO:
- Read error messages, stack traces, and logs thoroughly
Before you install
- Read the whole file first. Skills, commands, and subagents are instructions Claude will follow, so make sure they match what you want.
- Check which tools, scripts, or MCP servers it uses. Local servers and scripts run with your permissions.
- Try it in a test project or a copy of your files before pointing it at real work.
- Pin the version you tested, and review changes before updating.
- Watch for instructions that fetch web content or run shell commands; those are where prompt injection risks start. See our prompt injection guide.
FAQ
What is Debug Investigator?
Debug Investigator is a subagent for Claude Code and Claude Cowork from the yonatangross/orchestkit repository on GitHub. Debug specialist: systematic root cause analysis, execution path tracing, log and stack trace analysis.
How do I install Debug Investigator in Claude Code?
Download debug-investigator.md from the repository. Save it to ~/.claude/agents/ to use it in every project, or to .claude/agents/ inside one project to share it through version control. Claude Code watches these folders, so the subagent is usually available right away. Ask Claude to use it by name, or @-mention it to make sure it runs.
Can I use Debug Investigator in Claude Cowork?
Cowork loads subagents through plugins. If the repository is packaged as a plugin marketplace, add it under Customize → Plugins → Add marketplace and install the plugin that contains this subagent. Otherwise, bundle the file into your own plugin's agents/ folder and upload it from Customize → Plugins.
Is Debug Investigator safe to install?
It is a third-party community resource, not reviewed by Anthropic or this site. Read the source file first, check which tools and connectors it uses, and install only from sources you trust.
Similar resources
- Accessibility Accessibility patterns for WCAG 2.2 compliance, keyboard focus management, React Aria component patterns, cognitive inclusion, native HTML-first philosophy, and user preference honoring. Use when implementing screen reader support, keyboard navigation, ARIA patterns, focus traps, accessible component libraries, reduced motion, or cognitive accessibility. Skill · yonatangross/orchestkit
- Accessibility Specialist Accessibility expert: WCAG 2.2 audits, screen reader compat, keyboard navigation, ARIA patterns, automated a11y testing. Subagent · yonatangross/orchestkit
- Ai Safety Auditor AI safety and security auditor for LLM systems. Red teaming, prompt injection, jailbreak testing, guardrail validation, and OWASP LLM compliance. Subagent · yonatangross/orchestkit
- Backend System Architect Backend architect: REST/GraphQL APIs, database schemas, microservice boundaries, distributed systems, clean architecture. Subagent · yonatangross/orchestkit
- Demo Producer Universal demo video producer that creates polished marketing videos for any content - skills, agents, plugins, tutorials, CLI tools, or code walkthroughs. Uses VHS terminal recording and Remotion composition. Subagent · yonatangross/orchestkit
- Database Engineer PostgreSQL specialist: schema design, migrations, query optimization, pgvector/full-text search, Alembic migrations. Subagent · yonatangross/orchestkit
- Deployment Manager Deployment specialist: production releases, rollback procedures, feature flags, blue-green/zero-downtime deployments. Subagent · yonatangross/orchestkit
- Data Pipeline Engineer Data pipeline specialist: embeddings, chunking strategies, vector indexes, data transformation for AI consumption. Subagent · yonatangross/orchestkit