القائمة
基于 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