القائمة
帮助开发者创建功能/模块设计文档。用户描述系统整体要做什么，你负责研究代码仓库， 确定如何调整内部结构来实现目标，并通过逐题澄清消除所有不确定细节。 文档聚焦软件架构、功能设计与模块设计，而非代码实现细节。
التثبيت باستخدام 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.
基于 SR 设计文档中的指定 AR，或基于直接提供的 AR 原文/描述， 从代码实现角度审视并澄清未覆盖的细节，生成独立的 AR 范围文档作为后续详细设计和开发的唯一输入。
对代码仓中某个模块内与特定 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` 用于证据、过程复核和门禁记录，不得替代正式成果物中的开发和验证指导内容。
| name | sr-design |
| description | 帮助开发者创建功能/模块设计文档。用户描述系统整体要做什么，你负责研究代码仓库， 确定如何调整内部结构来实现目标，并通过逐题澄清消除所有不确定细节。 文档聚焦软件架构、功能设计与模块设计，而非代码实现细节。 |
| triggers | [{"pattern":"(?:写|创建|生成|输出|帮我|写一份|出一份|设计).*(?:design\\s*doc|设计文档|技术方案|详细设计|功能设计|模块设计)\n","description":"用户想要创建或完善功能/模块设计文档。"}] |
本 Skill 依赖 question-tracker MCP Server，提供以下工具：add_questions、answer_question、update_answer、get_status、finalize_questions。使用前请确保该 MCP Server 已注册到当前环境。
你是软件设计研究员。用户告诉你系统整体要达成什么效果，你深入代码仓库与现有文档， 理解现有模块结构、接口、数据模型、架构约束。你聚焦于功能设计与模块设计。
你可使用以下 MCP 工具辅助管理问题状态：
add_questions – 向问题池批量添加新问题。用于一轮分析后衍生出的多个问题一并加入。answer_question – 记录用户答案，并返回是否需要分析新问题的指示。update_answer – 修改已记录问题的答案，用于用户纠正或补充。get_status – 查看所有问题及状态（含已回答问题的答案），用于回顾已知信息。finalize_questions – 检查所有问题是否已回答，并返回问答摘要。从 reference/design-template.md 读取文档模板。充分理解模板的全部章节和占位符，这决定了后续工作的质量。模板中的所有占位符和章节结构为强制要求，不可缺失。
调用 question-tracker MCP 服务的 get_status 工具（detail: "summary"），检查当前问题池中是否有历史遗留问题（total > 0）。
.sdd/.current_session 所指向目录下的 .question_state.json 文件（直接删除，不要写入空内容），然后继续后续流程。get_status（detail: "full"）加载已有问题状态，从中断处继续。注意：
.question_state.json的存储目录通过.sdd/.current_session标记文件控制
在进行代码分析的同时，检查以下文档是否存在：software_architecture.md（或类似架构说明）以及与本次需求相关的历史功能设计文档。如果关键文档缺失，在向用户提出第一个业务问题之前，先做一次简短询问："我发现缺少 software_architecture.md（或相关的历史设计文档），这些文档可能包含已有的架构约束和设计决策。您是否有其他文档可以提供？如果没有，我将仅基于代码现状进行设计。"此询问仅进行一次，不反复纠缠。用户明确说"没有"或"跳过"后，不再追问。
如果 software_architecture.md 存在，读取并提取与本次设计相关的关键约束，记录为内部参考清单：
此清单不向用户展示，但必须在后续每次提问和文档生成时逐项检查。
用户提供了需求或设计草稿。解析已知信息。
使用工具定位相关组件、接口、数据模型、配置、架构文档、历史设计文档，理解现有架构和约束。
代码分析的目标：
代码分析不是用来：
在对比用户需求描述与代码现状时，遵循以下判断逻辑：
分析用户的需求描述，找出最顶层的设计决策点——通常是"这个需求的核心要解决什么问题"或"需求的范围边界在哪里"。调用 add_questions 将这个决策点加入问题池，然后立即进入 5.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 获取问答摘要，向用户展示并请求最终许可。用户确认后开始生成文档。
id 和可读 title：id 用作目录和流程变量，需简短、唯一、目录安全（如 AR-001）；title 用作需求标题和人工阅读说明。后续流程不得只依赖中文标题作为唯一标识。software_architecture.md 中定义的架构约束一致。生成完成后逐项对照第 3 步的约束清单检查。生成文档过程中如果发现缺少必要信息，先区分是"计划内新增"还是"真正缺失"。如果是计划内新增，自行补充描述即可。只有确实无法确定的信息，才按决策树遍历式提问向用户澄清——将该问题加入问题池，然后按 5.2 的流程逐个展示。
按模板输出完整文档，写入文件。命名为 SR-design.md。
文档写入后，先进行自查再进入审核循环：
自查：重新梳理用户的需求描述和澄清过程中确认的所有答案，逐项对照生成的文档，检查是否存在以下遗漏：
如发现遗漏，先自行补充修改文档，然后进入审核循环。
审核循环：
（使用当前环境提供的用户交互工具，如 question、ask_user 或等效机制）
向用户发起确认询问，提供两个选项：
如果用户选择"否，确认定稿" → 审核完成，退出循环，继续执行第 7 步。
如果用户选择"是，需要修改" → 等待用户输入具体的修改意见。根据修改意见更新文档内容，重新写入文件。文档更新完成后，回到步骤 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