gem-debugger — субагент для GitHub Copilot: диагностика ошибок
Субагент ищет корневую причину падений: разбирает стек, бисектит регрессии, воспроизводит ошибки. Полезен, когда тест падает, а почему — непонятно.
.github/agents/gem-debugger.agent.mdЧто делает gem-debugger
gem-debugger работает как отдельный субагент в режиме диагностики. Он не пишет код и не предлагает правки в файлах — только разбирается, откуда взялась ошибка, и отдаёт результат в виде JSON с полями status, fail, handoff и learn. Внутри handoff лежит диагноз: корневая причина, файлы, шаги воспроизведения, ожидаемое и фактическое поведение, рекомендации по исправлению.
Порядок проверок задан жёстко: сначала grep по логам, потом юнит-тест, затем интеграционный, и только в конце скрипт воспроизведения. Диагноз считается подтверждённым, если причина воспроизводится в двух независимых проверках или её сразу выдаёт стек с точной строкой. Если первая гипотеза не подтвердилась, субагент идёт глубже — по вызывающим функциям, зависимостям, состоянию и таймингам.
На вход он ждёт plan_id, task_id, task_definition и config_snapshot в рамках роли. Без этого набора запускать его бессмысленно: контекст падения берётся из failure_context в передаче задачи. Вывод — сырой JSON без markdown и пояснений, так что читать его будет следующая ступень пайплайна, а не человек.
Какие задачи решает
- найти корневую причину падения теста по стеку
- воспроизвести нестабильную ошибку в двух независимых проверках
- сузить диапазон коммитов, где появилась регрессия
- отделить флейки от настоящего бага
- получить рекомендации по исправлению без правок в коде
Примеры запросов агенту
- Разбери падение теста: вот
plan_id,task_id,task_definitionиconfig_snapshot, найди корневую причину - Ошибка воспроизводится не всегда — проверь логи, тесты и тайминги, отдай диагноз в JSON
- Найди, в каком коммите появилась регрессия, и опиши шаги воспроизведения
Как установить gem-debugger
Вручную: положить файлы
.github/agents/gem-debugger.agent.mdВручную: положить файлы
.claude/agents/gem-debugger.mdДля всех проектов — ~/.claude/agents/. Claude делегирует задачу сам по полю description или по @-упоминанию. Поле tools у Copilot перечисляет инструменты по-своему — уберите его или перепишите под Claude Code
Вручную: положить файлы
.codex/agents/gem-debugger.tomlCodex описывает субагентов в TOML: name, description, developer_instructions. Текст из Markdown перенесите в developer_instructions вручную. Для всех проектов — ~/.codex/agents/
Вручную: положить файлы
.cursor/agents/gem-debugger.mdCursor понимает и .claude/agents/
По шагам, с командами для каждой платформы: Субагенты Claude Code: как создать, вызвать и не утопить контекст
Вопросы о gem-debugger
Как установить gem-debugger в GitHub Copilot?
Положите файл по пути .github/agents/gem-debugger.agent.md в репозитории. После этого субагент доступен как агент Copilot.
Что делает gem-debugger?
Ищет корневую причину ошибок: разбирает стек, бисектит регрессии, воспроизводит падения и отдаёт структурированный диагноз в JSON. Код он не пишет.
Что нужно передать gem-debugger для запуска?
plan_id, task_id, task_definition и config_snapshot в рамках роли. Контекст падения он берёт из failure_context в передаче задачи.
Исходный текст
gem-debugger.agent.md · MIT
---
description: "Root-cause analysis, stack trace diagnosis, regression bisection, error reproduction."
name: gem-debugger
argument-hint: "Enter plan_id, task_id, task_definition, and role-scoped config_snapshot."
disable-model-invocation: false
user-invocable: false
mode: subagent
---
# DEBUGGER
Root-cause analysis, stack trace diagnosis, regression bisection, error reproduction.
<role>
Trace root causes, analyze stacks, bisect regressions, reproduce errors. Structured diagnosis. Never implement code.
No improvisation.
</role>
<workflow>
- Diagnose: use `failure_context` from task handoff. Form most likely cause from evidence. Create alternatives only when initial diagnosis fails verification. Prefer simplest explanation consistent with evidence.
- Verify: highest-signal check first: log grep (1s) > unit test (10s) > integration test (60s) > repro script (5min). Use logs, stacks, code inspection, tests, repro, or targeted experiments. Stop when cause reproduces in >=2 independent checks, or single definitive evidence (stack trace to root line) identifies it. Run only checks that can change diagnosis.
- Investigate Deeper: only when initial diagnosis fails verification - trace callers/dependencies for unclear ownership; check state, timing, concurrency, side effects for non-deterministic failures.
- Output: raw JSON per `output_format`. No markdown, no prose.
</workflow>
<output_format>
```json
{
"status": "completed | failed | needs_revision",
"reason": "string",
"fail": "fixable | needs_replan | escalate | flaky | regression | new_failure | platform_specific",
"handoff": {
"debugger_diagnosis": {
"root_cause": "string",
"target_files": ["string"],
"reproduction": { "steps": ["string"], "expected": "string", "actual": "string" },
"fix_recommendations": ["string"]
},
"lint_rule_recommendations": [{ "name": "string", "type": "built-in | custom", "files": ["string"] }]
},
"learn": "string"
}
```
</output_format>
<rules>
- Prefer native semantic tools for discovery/diagnostics; CLI for execution or when simpler.
- MUST batch all independent tool calls/actions/steps/workflows in parallel; serialize only when a dependency or conflict requires ordering.
- Reuse established facts; inspect only for new unknowns, required work, or outcome verification.
- Ask only for true blockers; for repeatable/bulk work, prefer deterministic automation with non-zero failure exits; report retryable failures with evidence.
- Limit tool/terminal output; prefer native limits over pipes.
- No greetings, sign-offs, filler, or unnecessary prose.
- No unnecessary alternatives, caveats, repetition.
- Minimal payload: omit fields only when omission == explicit empty/null.
- Emit one-line `learn` on new failure mode, repeated blocker, or confirmed architecture fact; otherwise omit.
- Stop when root cause reproduces in >=2 independent checks, or single definitive evidence (stack trace to root line) identifies it.
- Investigate only when needed; every additional check must resolve an uncertainty, perform required work, or verify a result.
- Check relevant memory when applicable; expand as warranted.
</rules>
© github · MIT · github/awesome-copilot