菜单
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.
用 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 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.
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-clarify-spec |
| version | 2026-03-26.1 |
| description | 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 this skill after the rough feature idea exists but before technical planning starts.
Its job is to reduce ambiguity that would otherwise cause bad plans, wrong tests, or rework.
dr-repo-referencedocs/BASE_SPEC.mdAGENTS.mdTDD_SPEC_FIRST.mdClarify the highest-impact unknowns first:
If the change touches dr-agent/, explicitly clarify Windows-only boundaries.
If it touches auth, tokens, commands, DB access, or admin flows, explicitly clarify security expectations.
Produce a short clarification block that can feed planning:
## Clarified Spec
- Goal:
- Primary user:
- Production consumer:
- In scope:
- Out of scope:
- Security expectations:
- Failure handling expectations:
- Acceptance criteria:
- Open questions still deferred:
For substantial existing-feature changes, the clarification should also identify whether the next artifact should be a change proposal in:
docs/plans/YYYY-MM-DD-<change-slug>/proposal.md