菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use 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 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.
Use when resuming work in this repo after a pause or starting a fresh session on in-flight changes. Reconstruct the current state, open risks, relevant files, completed verification, and next actions.
| name | dr-code-review |
| version | 2026-03-31.1 |
| description | 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. |
Include:
For non-trivial reviews, also include:
Observed: concrete findings from code or verificationInferred: risk or behavior conclusionProposed: requested change or rebuttalConfidence: 0.0-1.0 with one-line reasonFalsifier: what would prove the review conclusion wrongReflection: weakest assumption and the next checkHelpful commands:
git diff --stat
git diff
Portal:
cd portal && go test ./...
cd portal && golangci-lint run ./...
Agent:
cd dr-agent && GOOS=windows go test ./...
cd dr-agent && GOOS=windows golangci-lint run ./...
Do this in order:
When responding to non-trivial comments, label your reasoning with Observed, Inferred, and Proposed.
Do not agree with review feedback before verification. The required pattern is:
For larger review items, prefer one issue at a time:
GOOS=windows constraintsFor non-trivial review disputes:
Use the canonical role behavior from docs/AGENT_ROLES.md.
For larger reviews, use narrow read-only subagents:
reviewersecurity_reviewer for security-sensitive changesUse the model and reasoning defaults from docs/CODEX_AGENT_POLICY.md rather than treating all review work as equal-cost and equal-depth.
For larger reviews, use narrow read-only subagents:
reviewer for correctness, regressions, and missing testssecurity_reviewer for security-sensitive diffswindows_agent_reviewer for dr-agent/ changesportal_explorer when the portal execution path is unclearDo not use subagents for tiny, obvious review fixes.