메뉴
帮助开发者创建功能/模块设计文档。用户描述系统整体要做什么，你负责研究代码仓库， 确定如何调整内部结构来实现目标，并通过逐题澄清消除所有不确定细节。 文档聚焦软件架构、功能设计与模块设计，而非代码实现细节。
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