菜单
基于 SR 设计文档中的指定 AR，或基于直接提供的 AR 原文/描述， 从代码实现角度审视并澄清未覆盖的细节，生成独立的 AR 范围文档作为后续详细设计和开发的唯一输入。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
配置驱动的 AAW 工作流 CLI 入口技能。读取 aaw CLI 返回的自描述工作单，按工作单调用子技能、执行 prompt、检查交付件并推进流程。
根据 task-split 生成的独立任务文件逐个开发 task，执行实现、为用例编写自动化测试代码并跑通、输出总结并更新任务文件和 overview 状态。Use when the user asks to 开发详细任务、实现独立任务、开发 task 文件、执行 T1/T2、继续开发带用例的任务。Also trigger when the user references a tasks/ directory with independent task files (T1-*.md, T2-*.md) and wants to implement one of them. Make sure to use this skill whenever the user mentions task files from task-split, wants to start coding based on detailed task files with test cases, or asks to continue development work from a tasks/ directory.
对代码仓中某个模块内与特定 SDD 需求、AR、功能点、影响范围或计划变更相关的部分进行 ASIS 逆向分析，并只更新同名前缀 `.context.md` 中的详细证据、检索过程、边界确认记录、ASIS 探索任务清单、分任务查证结果、主 Agent 复核吸收记录、ASIS 结论和阻塞项。当前置 TOBE 详细设计、门禁或 AICoding 需要基于代码证据确认现状事实、隐藏约束、依赖、风险、测试覆盖和实现行为时使用。ASIS 阶段不得创建或编辑正式《{AR编号}-{需求短名}-{模块名}模块详细设计说明书.md》；正式说明书只能由 TOBE 阶段基于 context 证据生成。必须存在 `.sdd/software_architecture.md`，并且只能以该文件作为模块边界识别依据；缺失时中断。
模块边界设计。基于已完成的功能设计（SR-design），识别受影响模块，逐模块定义边界（职责、上游依赖、下游暴露），绘制模块交互时序，并通过对抗式审查发现边界冲突（职责泄漏、循环依赖、边界破坏、重复能力）。输出 module-boundary-design.md。用于AAW工作流步骤3。Use when the user asks for 模块边界设计、module-boundary-design。
对当前 SDD 工作流指定的正式《{AR编号}-{需求短名}-{模块名}模块详细设计说明书.md》和独立《{AR编号}-{需求短名}-{模块名}模块测试用例设计.md》进行质量门禁检查，围绕证据链、边界链、执行链、验证链和风险链判断成果物是否足以进入后续 AICoding。当前需要确认详设和测试设计是否可进入 AICoding、发现阻断问题、生成整改清单、驱动回到 ASIS、TOBE 或测试设计补齐并多轮复检时使用。门禁阶段不得编辑正式说明书或测试设计正文；配套 `.context.md` 用于证据、过程复核和门禁记录，不得替代正式成果物中的开发和验证指导内容。
基于正式《{AR编号}-{需求短名}-{模块名}模块详细设计说明书.md》、同名前缀 `.context.md` 的 ASIS 测试覆盖现状和 TOBE 可测试性输入，生成独立《{AR编号}-{需求短名}-{模块名}模块测试用例设计.md》。本 skill 只输出最小充分测试用例集、覆盖矩阵、断言、建议位置和缺口；不得替 TOBE 补设计，不得拆分 AICoding 任务。
| name | ar-clarify |
| description | 基于 SR 设计文档中的指定 AR，或基于直接提供的 AR 原文/描述， 从代码实现角度审视并澄清未覆盖的细节，生成独立的 AR 范围文档作为后续详细设计和开发的唯一输入。 |
| triggers | [{"pattern":"(?:澄清|细化|审视|检查|review|分析|提取).*(?:AR|分配需求|需求条目)\n","description":"用户想要对某条 AR 进行实现层面的澄清，可来自 SR 设计文档，也可来自直接 AR 输入。"}] |
本 Skill 依赖 question-tracker MCP Server，提供以下工具：add_questions、answer_question、update_answer、get_status、finalize_questions。使用前请确保该 MCP Server 已注册到当前环境。
sr-design Skill 生成的功能/模块设计文档，包含需求背景、功能设计、AR 拆分与交互定义、需求追溯等章节。SR 派生模式下使用它作为 AR 来源。id 和可读 title：id 用作目录和流程变量，需简短、唯一、目录安全（如 AR-001）；title 用作人工阅读说明。AR-clarify.md），包含该 AR 的完整信息。后续详细设计和开发工作流以此文档作为唯一输入，不再依赖 SR 设计文档。你是 AR 范围文档的构建者。你的职责是：
核心原则：
你可使用以下 MCP 工具辅助管理问题状态：
add_questions – 向问题池批量添加新问题。用于一轮分析后衍生出的多个问题一并加入。answer_question – 记录用户答案，并返回是否需要分析新问题的指示。update_answer – 修改已记录问题的答案，用于用户纠正或补充。get_status – 查看所有问题及状态（含已回答问题的答案），用于回顾已知信息。finalize_questions – 检查所有问题是否已回答，并返回问答摘要。先确认 AR 的 id、title 和来源。若由 aaw-workflow 调用，以工作单中的 input.value 和路径为准；若存在可选输入 AR-source.md，先读取其中的 AR 原文、链接摘要或长描述；否则向用户询问：
请提供要澄清的 AR id、AR title，以及 AR 来源：
- SR 派生模式：提供 SR 设计文档路径和要澄清的 AR id/title
- 直接 AR 模式：提供 iDesigner AR 原文、链接摘要或自然语言描述
根据输入选择模式：
SR-design.md，且目标 AR 来自其中的"AR 拆分与交互定义"章节。SR-design.md，或用户明确要求从单条 AR 直接开始；此时以用户提供的 AR 原文/描述作为范围来源。SR 派生模式下，读取 SR 设计文档，定位该 AR 在文档中的所有相关内容：
直接 AR 模式下，整理用户提供的 AR 原文/描述，至少识别以下信息；无法识别的项进入澄清问题池，不得猜测：
向用户确认：
已定位到 AR [id] - [title]：
输入模式：[SR 派生 / 直接 AR]
承接模块：[模块名或待澄清]
核心职责：[已确认的描述]
来源范围：[SR 文档章节或 AR 原文摘要]
请确认这是要澄清的 AR 吗？
从 reference/AR-range-template.md 读取 AR 范围文档模板。了解模板的章节结构，明确后续需要从 SR 设计文档中提取哪些章节的内容，以及需要补充哪些澄清信息。
用户确认后，根据 AR 的承接模块名和功能描述，定位相关代码：
在对比时，遵循以下判断逻辑：
分析 SR 文档中该 AR 的描述和代码现状，找出最顶层的实现决策点——通常是"这个 AR 的核心实现方案是什么"或"接口/数据的改动范围在哪里"。调用 add_questions 将这个决策点加入问题池，然后立即进入 4.2 的展示流程。
核心机制：每次只从问题池中取出一个未回答的问题向用户展示。每个问题都应该是用户上一个答案的自然延伸。
提问模板（必须严格遵循）：
**当前现状**：[从代码/文档中发现的与当前决策点相关的现状描述]
**设计决策**：[需要用户决定的这个决策点是什么]
**可选方案**：
- A. [方案名称]：[方案描述及对实现的影响]
- B. [方案名称]：[方案描述及对实现的影响]
- C. (如有) [方案名称]：[方案描述及对实现的影响]
**我的推荐**：[基于项目现状、已有设计模式、架构约束推荐一个方案，并说明理由]
**你的选择**：
可选方案的构成原则：
每次提问前必须完成：
get_status 确认当前问题已经在问题池中，且状态为 pending收到用户回答后：
调用 answer_question 记录当前问题的答案。记录时需包含用户选择的方案及理由。
调用 get_status 获取所有已确认答案，对比是否存在矛盾。如果存在矛盾，向用户指出后由用户确认以哪个为准，使用 update_answer 修改被纠正的答案。
分析这个答案，检查它是否触发了以下维度的新决策点（逐项过，不跳）：
对于每个被触发的维度，只记录必须现在解决的决策点。对每个新决策点：
将本轮衍生出的所有新问题（如有）通过 add_questions 批量添加到问题池。
检查之前的问题是否被当前答案消解：如果某个在池中的问题因当前答案而变得不再需要讨论（例如用户选了方案 A，而问题 Z 只对方案 B 有意义），向用户确认该问题已被消解，用户确认后调用 answer_question 标记为 derived。
如果用户修改了之前的答案（通过 update_answer），全面重审问题池：被旧答案消解的问题是否需要重新打开，新答案是否消解了其他问题。向用户确认变更影响后，继续后续步骤。
调用 get_status 查看问题池，跳过已通过消解确认的问题，取出下一个未回答的问题（按添加顺序），使用上述提问模板向用户展示。
重复此过程，直到 get_status 返回的问题池中所有问题都已回答（状态为 answered 或 derived）。
当 get_status 显示所有问题已回答，且不存在矛盾时，调用 finalize_questions 获取问答摘要，向用户展示并请求最终许可。用户确认后开始生成 AR 范围文档。
生成文档过程中如果发现缺少必要信息，先区分是"计划内新增"还是"真正缺失"。如果是计划内新增，自行补充描述即可。只有确实无法确定的信息，才按决策树遍历式提问向用户澄清——将该问题加入问题池，然后按 4.2 的流程逐个展示，直到再次 finalize_questions 返回 status: "ready"，才能继续生成文档。
按模板输出完整文档，写入文件。若由 aaw-workflow 调用，写入工作单 output 指定路径，通常为 ./.sdd/{SR}/{AR}/AR-clarify.md；非编排场景下，写入当前 SR/AR 工作目录中的 AR-clarify.md。
文档写入后，先进行自查再进入审核循环：
自查：重新梳理 AR 来源内容、澄清过程中确认的所有答案，逐项对照生成的文档，检查是否存在以下遗漏：
如发现遗漏，先自行补充修改文档，然后进入审核循环。
审核循环：
（使用当前环境提供的用户交互工具，如 question、ask_user 或等效机制）
向用户发起确认询问，提供两个选项：
如果用户选择"否，确认定稿" → 审核完成，退出循环，继续执行第 6 步。
如果用户选择"是，需要修改" → 等待用户输入具体的修改意见。根据修改意见更新文档内容，重新写入文件。文档更新完成后，回到步骤 1，再次向用户发起确认询问。
此循环必须持续，直到用户选择"否，确认定稿"为止。
若不处于 aaw-workflow 编排中，请忽略此节。
本 skill 由 aaw-workflow 编排调用。交付件生成后：
aaw next --sr <SR号> --json 查看进度deliverables_exist: true → 直接 aaw done --sr <SR> <id>aaw-workflow 的 user_confirm 策略控制不记得 SR 号 → 先 aaw status --json