systematic-debugging · ganyuanran — скилл для Claude Code: отладка и установка
Скилл помогает разбирать ошибки, сбои тестов и неожиданное поведение до правок. Он прослеживает причину до места, которое действительно нужно исправить.
npx skills add GanyuanRan/Aegis --skill systematic-debugging -a claude-codeЧто делает systematic-debugging
Сначала скилл предлагает воспроизвести сбой, изучить ошибку и недавние изменения, затем проследить проблемное значение до его источника. Он отделяет наблюдаемый симптом от доказанной причины и помогает найти владельца логики, где исправление будет уместным.
Перед правкой нужно оценить, затрагивает ли она общую логику, контракт или резервный путь; для сложных случаев скилл проверяет форму патча и его влияние на соседние части системы. Затем он предлагает проверить одну гипотезу минимальным воспроизведением или тестом и закрыть исправление проверкой с учётом риска. После трёх неудачных исправлений следует остановиться и пересмотреть архитектуру.
Для простого воспроизводимого дефекта в одном месте предусмотрен короткий путь диагностики, но он всё равно требует обосновать необходимость правки кода до редактирования. При проблемах интерфейса скилл предлагает подключить ui-ux-governance; для нестабильного воспроизведения — читать feedback-loop-construction.md только при признаках зависимости от времени или случайности. Это повод не принимать локально проходящий тест за доказательство правильного места исправления.
Какие задачи решает
- воспроизвести ошибку и отделить симптом от причины
- найти владельца проблемной логики
- проверить необходимость правки кода до редактирования
- проверить исправление на воспроизведении и соседнем случае
- пересмотреть архитектуру после трёх неудачных исправлений
Примеры запросов агенту
- Разбери сбой теста: воспроизведи его и найди первопричину до любых правок.
- Проследи, откуда приходит неправильное значение, и предложи минимальную проверку гипотезы.
- Проверь, действительно ли нужно менять код, прежде чем исправлять эту ошибку.
Как установить systematic-debugging
1Через Skills CLI (Vercel)
npx skills add GanyuanRan/Aegis --skill systematic-debugging -a claude-code2Вручную: положить файлы
~/.claude/skills/systematic-debugging/SKILL.mdПапка скилла целиком; для одного проекта — .claude/skills/systematic-debugging/
1Через Skills CLI (Vercel)
npx skills add GanyuanRan/Aegis --skill systematic-debugging -a codex2Вручную: положить файлы
.agents/skills/systematic-debugging/SKILL.mdДля всех проектов — ~/.agents/skills/
1Через Skills CLI (Vercel)
npx skills add GanyuanRan/Aegis --skill systematic-debugging -a cursor2Вручную: положить файлы
.cursor/skills/systematic-debugging/SKILL.mdCursor читает и .agents/skills/, и .claude/skills/
1GitHub CLI
gh skill install GanyuanRan/Aegis systematic-debugging2Вручную: положить файлы
.github/skills/systematic-debugging/SKILL.md1Через Skills CLI (Vercel)
npx skills add GanyuanRan/Aegis --skill systematic-debugging -a gemini-cli2Командой платформы
gemini skills install https://github.com/GanyuanRan/Aegis --path skills/systematic-debuggingВручную: положить файлы
.devin/skills/systematic-debugging/SKILL.mdСтарый путь .windsurf/skills/ тоже читается
Через Skills CLI (Vercel)
npx skills add GanyuanRan/Aegis --skill systematic-debugging -a opencodeClaude.ai
Упакуйте папку в zip и загрузите в Settings → Capabilities → Skills
По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов
Вопросы о systematic-debugging
Как установить systematic-debugging в Claude Code?
Выполните npx skills add GanyuanRan/Aegis --skill systematic-debugging -a claude-code. Файл скилла находится по пути ~/.claude/skills/systematic-debugging/SKILL.md.
Что делает systematic-debugging?
Скилл задаёт порядок диагностики: воспроизвести сбой, проследить причинную связь, определить владельца логики и проверить гипотезу до ремонта. Он также помогает оценить границы правки и проверить результат.
Что делать, если ошибка воспроизводится нестабильно?
Скилл предлагает обратиться к feedback-loop-construction.md, если есть признаки случайного или зависящего от времени воспроизведения. Затем нужно построить ограниченный цикл проверки.
Исходный текст
SKILL.md · MIT
--- name: systematic-debugging description: "Use when encountering a bug, test failure, or unexpected behavior, before proposing fixes" --- # Execute Bug, failure, or unexpected behavior: 1. **Isolate** — read error, reproduce, inspect the diff, and drill upward through diagnostic layers: L1 symptom → L2 logic → L3 system → L4 architecture → L5 cross-system contract → L6 platform → L7 spec gap. Layers are observation altitudes, not one causal chain; the causal shape at the stop altitude is classified explicitly before any root claim. Stop only when causal proof accounts for the recurrence generator or reaches a T-class boundary. 2. **Identify owner** — compare working behavior, trace the bad value, locate the canonical owner, and treat duplicate owners as a finding. 3. **Decide before editing** — Before fixing, run Patch-Shape Triage and Ripple Signal Triage when shared logic, contracts, fallbacks, adapters, producer/consumer seams, or source-of-truth boundaries are involved. Surface Change Necessity for any new source-code path or non-trivial source edit. Run Minimality Check for a new branch, fallback, adapter, owner, or compatibility path, and Pre-Edit Complexity Check for an overloaded owner or complexity growth. After Change Necessity selects `code-change` and before the first repair edit, own the TDD Route for the repair slice per `test-driven-development` (`off` default; `strict` on behavior/bugfix/shared/contract/persistence/permission/migration risk). 4. **Prove** — test one hypothesis with the smallest reproduction or verification. A failing test first is required only by a recorded `TDD Route: strict`; with `TDD Mode: off`, do not require a failing test or RED/GREEN cycle. Three failed fixes means stop and question architecture. 5. **Repair and close** — fix minimally at the canonical owner, verify in proportion to risk, review architecture, and close both repair and retirement tracks. If a symptom remains or shifts, reopen the causal model; do not assume it is a separate defect. Done: confidence ≥ B, causal status matches recurrence evidence or an external terminal, tracks explicit, no H signal, and required D evidence passes. ## Core invariant Find root cause and fix the bug class at its canonical owner. A minimal fix is not the smallest textual diff; it is the smallest sufficient owner-level repair. Apply the same causal-sufficiency standard to every bug. Trace relevant influences and justify exclusions; resolve repair-changing unknowns before retaining a solution. Experiments may precede closure. Evidence gaps, not apparent size or risk, determine investigation depth. ## Quick bug lane For an evidenced local, reproducible, single-owner bug with no patch-shape signal, keep the readback compact: `Symptom`, `Reproduction`, `Root Cause`, `Change Necessity`, `Fix Boundary`, and `Verification`. Skip the causal card only when the causal-proof owner's `Quick Exit Proof` passes. This reduces readback, not the causal coverage or evidence standard. Quick bug lane must surface Change Necessity before source edits. One sentence may cover the user-visible need, no-change/non-code option, why code must change, minimum boundary, and an explicit decision token such as `Decision: code-change`. If shared logic, a contract, fallback, duplicate owner, consumer patch, or cross-module behavior appears, leave this lane. `Aegis Visibility` names the evidence/owner/patch-shape/verification effect. Pass root cause, avoided misfix, boundary, evidence, complexity, and risk to `verification-before-completion`; no separate receipt. ## Diagnose before repair For UI/interaction defects, compose `ui-ux-governance` for relevant state and recovery rules at the user-visible seam. Keep reproduction/root-cause ownership here; a proposed manual check is not executed evidence. 1. Read the complete error/stack and record inputs, environment, versions, and success criteria. Reproduce the user's failed outcome on the correct object, through final delivery; successful parsing or green internal checks may hide the failure. Verify the repaired behavior and a relevant neighboring case, not a hardcoded example. Read-only diagnosis does not authorize repair. 2. Reproduce consistently. If unstable, read `feedback-loop-construction.md` **only when evidence shows intermittent or timing-dependent reproduction** and build a bounded loop. Shrink the repro to load-bearing elements as the test input, never the fix scope: still drill upward; test at the correct seam. 3. Inspect recent changes and compare a working example. Code is evidence; if authority, glossary, code, and tests disagree, compose `establishing-project-context` rather than silently redefining a term. 4. Instrument component boundaries, then trace the bad value toward its source. Read `root-cause-tracing.md` **only when the observed bad value is several calls or components downstream from its origin**. For task distortion, follow source → understanding → expression → execution → delivery to the first evidenced change in meaning. This identifies where divergence is observed, not a proven root; reuse sufficient current evidence. 5. State one hypothesis and falsify it with one-variable evidence. Do not stack speculative fixes. End each loop with `Goal | DeeperCause | Evidence | Risk/Unknown | Decision`. ### Canonical-owner and patch-shape gate Before editing, continue upward unless evidence proves the local site is the canonical owner when the candidate is any of these signals: - keyword, phrase, regex, negation-word list, or sample-text exception; - local guard, extra conditional, `try`/`catch`, early return, or one-off branch; - fallback, adapter, compatibility branch, prompt branch, or legacy path expansion; - consumer/caller/readiness/presentation-layer patch; - downstream logic re-parses raw text or re-infers action/state while typed intent, normalized state, contract, or another source-of-truth exists; - artifact/download/export/readback/cache patch without producer/owner proof. ```text PatchShape: CanonicalOwner: UpwardDrillSignal: Decision: fix owner | continue investigation | escalate ``` A locally green test does not erase triage; a renamed carrier is not a new direction. When a repair may reinterpret or retire existing semantics, responsibility, contract, or relationship, name the behavior to preserve, highest-risk counterexample, and material unknown. For each known explicit anchor or upstream/downstream reference, state its role and disposition: preserve, rebind to the canonical owner, retire with reason, or reject because of conflict. Leave unresolved relationships unknown; do not re-infer them downstream. Bind role before value and retire invalid responsibility, not evidenced carrier capability. This bounded reminder is not a behavior matrix, relationship graph, referential-integrity proof, or exhaustive discovery claim. It adds no artifact, TDD risk signal, or regression scope; the existing TDD route owner and configured/default mode still apply. If the diagnosis crosses L3, a patch-shape signal fires, a user disputes the root claim, a prior fix leaves a symptom, compound/root topology is plausible, two or more anchored manifestations of one incident exist, reproduction conditions diverge across occurrences, or an upstream producer/config/default/contract/spec remains unexcluded, read `root-cause-claim-contract.md` **before claiming a root cause**. It is the sole owner of the Pre-Claim Gate, causal-closure/falsifier proof, layer-ceiling proof, and Causal Topology Gate. ### Change Necessity This decision is behavior-triggered, not prompt-triggered. It applies to any new source-code path. Before that path or a non-trivial source edit, expose the `Change Necessity` decision (`no-change | docs/config-only | code-change | needs-clarification`); field detail lives in `advanced-debugging-governance.md`. ### Minimality and owner fit For any proposed branch, fallback, adapter, compatibility path, or new owner, run `Minimality Check` (fields in `advanced-debugging-governance.md`) with verdict `sufficient repair | local patch | needs first-principles review`, and retire invalid responsibility: a `local patch` needs a retention reason and retirement trigger. For a new non-ordinary repair surface, run the `Existence Check` in `docs/current/AEGIS_MINIMALITY_REFERENCE.md`. If retirement involves old code, external compatibility, or persistent-state risk, compose `anti-entropy-governance`; it chooses the retirement path but never grants destructive authority. Before editing an overloaded or mixed-purpose owner, complete `Pre-Edit Complexity Check` and `Pre-Edit Owner-Fit Decision` (templates in `advanced-debugging-governance.md`). Use `using-aegis/references/complexity-governance.md` for pressure signals. Do not add `new-responsibility` in place by default. If the safer boundary changes the approved shape, update the plan/spec first. ## Repair and proportional verification Repair each evidenced cause needed for the scoped outcome at its responsible owner; do not force independent causes into one owner or bundle “while here” work. Under strict TDD, create the smallest failing test first. With TDD off, a reproduction is diagnostic evidence, not a RED gate or a prerequisite for production edits. Verification must match the risk: - local single-owner repair: original reproduction plus focused regression; - shared/contract/cross-module repair: canonical owner plus affected consumers and compatibility boundary; - fallback/owner retirement: main-path, lingering-reference, negative, and boundary checks; - timing/concurrency repair: read `condition-based-waiting.md` **only when evidence identifies polling, sleeps, or race timing as part of the cause**; - invalid state crossing several trusted boundaries: read `defense-in-depth.md` **only after the root repair is known and evidence shows a second independent validation boundary is required**. Read `advanced-debugging-governance.md` **before another fix** for failed/ persistent / divergent repair or three failures; for unclear/disputed stop / Layer Stop Card / intervention; or plausible compound root. Closeout triggers: repair-added patch-shape; multi-site/one-regression; remaining pattern/anomaly/duplicate/wrong-owner/downstream repair; uninspected same-symptom fix; open recurrence/unsupported root status; missing compound topology-specific member/anti-disguise proof; outside-repo authority; unmigrated published-contract break; undefined spec; missing permission/info. They route H/T/D; detail is not causal proof. For non-trivial debugging with configured workspace support, use `<aegis-workspace-helper>` to `init`, `new-work`, `add-evidence`, and `check` the target project. Command details belong to long-task-continuation. Failed attempts use `<aegis-workspace-helper> add-attempt`; `add-evidence` is terminal-only. Fast bug fix or quick bug fix pressure does not skip this: if Ripple Signal Triage fires, record it before editing and verify the canonical owner plus affected downstream path. Records are advisory, not completion authority. ## Closure Always report: - **Repair** — cause, owner, smallest change, compatibility, verification. - **Retirement** — invalid responsibility status, carrier/capability disposition, retention reason/trigger, removal check. Confirm the reproduction, same-pattern handling, authority, complexity, and retirement. Prefix debug logs (e.g. `[DEBUG-a4f2]`); confirm one-grep removal before close. Confidence: A = direct regression evidence; B = strong evidence with bounded unknowns; C = partial and not resolved. `Trace Digest` may summarize audit evidence; never expose chain-of-thought or replace root-cause, rule-effect, and verification evidence.
© GanyuanRan · MIT · GanyuanRan/Aegis
Похожие скиллы
Все скиллы по теме «Тесты и QA» →Сначала — systematic-debugging от других авторов.