菜单
Use for bugs, failing tests, bad runtime behavior, or unexpected regressions. Gather evidence locally, identify root cause, then fix and verify through the correct component commands.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | dr-systematic-debugging |
| version | 2026-03-26.1 |
| description | Use for bugs, failing tests, bad runtime behavior, or unexpected regressions. Gather evidence locally, identify root cause, then fix and verify through the correct component commands. |
NO FIX WITHOUT ROOT-CAUSE INVESTIGATION FIRST
NO NON-TRIVIAL FIX WITHOUT AN EXPLICIT REPRO
Load dr-repo-reference before running component-specific verification.
Load docs/AGENT_ROLES.md for non-trivial bugs.
Start with the smallest reliable reproduction:
git diff -- <path>
git log -- <path>
rg -n "<symbol>|<error>|<route>" portal dr-agent gateway installer
If relevant, inspect runtime state:
docker-compose ps
docker-compose logs --tail=200 portal
docker-compose logs --tail=200 postgres
Before editing, state:
Label diagnosis work as:
Observed: logs, diffs, tests, traces, or code factsInferred: root-cause explanation supported by those factsProposed: fix or next experimentConfidence: 0.0-1.0 with one-line reasonFalsifier: what result would disprove the current diagnosisReflection: weakest assumption and the next diagnostic checkFor non-trivial issues:
Use the canonical role behavior from docs/AGENT_ROLES.md.
Use subagents only when evidence gathering can run in parallel:
portal_explorer to map the failing portal pathwindows_agent_reviewer to check Windows-only agent constraintssecurity_reviewer if the bug crosses a security boundaryUse the component verification matrix from dr-repo-reference, narrowing to the failing component and test target.
dr-agent/, assume Linux-local intuition is unreliable until the Windows build path passesUse when asked to work in a continuous loop until done or truly blocked. Orchestrates pickup, planning, TDD execution, implementation waves when needed, debugging side-chains, verification, and resume behavior.
Use before planning when a feature or change request is underspecified. Resolve high-impact ambiguity around scope, consumers, security, failure handling, and acceptance criteria before writing the implementation plan.
Use for both preparing work for review and responding to review feedback. Keep review evidence local, concrete, and scoped to the real contract. Verify technically before agreeing or changing code.
Use before implementation. Merge design discovery and plan writing into one DR-specific flow: identify the consumer, inspect the repo, debate boundaries with partner and combatant, and produce an execution-ready plan that hands off cleanly into DR-native tasks, TDD, and implementation waves.
Use for the last mile: rerun verification, inspect diffs, commit or push if requested, and perform local docker-compose checks when needed. This is the DR local-tools replacement for MCP-style finish/deploy carryovers.
Use after planning and before implementation when you need a concrete, dependency-ordered task list. Turn the DR feature spec and plan into independently testable task slices with exact file paths and verification commands.