菜单
主动研究一个既有模块，建立 AI 可复用的模块认知资产。适用于需要深入理解一个模块的职责、运行路径、数据模型、约束和风险时使用。本 skill 只读代码、测试、文档和配置，只写模块认知资产目录；不得修改业务代码。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | module-deep-research |
| description | 主动研究一个既有模块，建立 AI 可复用的模块认知资产。适用于需要深入理解一个模块的职责、运行路径、数据模型、约束和风险时使用。本 skill 只读代码、测试、文档和配置，只写模块认知资产目录；不得修改业务代码。 |
本 skill 主动研究一个既有模块，把"需要读代码才能建立的模块理解"沉淀成可复用的认知资产，让后续任何需要理解该模块的工作（设计、维护、交接、二次开发等）不用从零逆向。
.sdd/modules/<module>/ 下的认知资产。资产结构见 <skill-dir>/references/asset-structure.md。
本 skill 的产出是一个持续积累的模块认知库，不是一次性报告。研究通过单会话自循环推进，整体形态如下：
flowchart TD
S["启动落盘<br/>建骨架 + 写首批研究任务"] --> L["读队列"]
L --> P{"有可取证任务?"}
P -->|"有"| C["选最高价值研究任务"]
C --> R["研究:立假设→取证→追踪路径→反证"]
R --> W["小额落盘<br/>更新认知 + 队列"]
W --> Q["关闭当前任务 + 优化/拆分/补充队列"]
Q --> L
P -->|"队列空"| G{"能拆出新任务?"}
G -->|"能"| L
G -->|"不能"| RC["§7 Recheck 全维度自审"]
RC --> RCF{"自审发现问题?"}
RCF -->|"有,转任务重进循环"| L
RCF -->|"无"| E["停止:落盘进度 + 元信息"]
关键认知：
研究过程/研究队列.md——队列里有什么研究任务，就研究什么；队列空了先拆新任务，拆不出才进 recheck。下文 §3–§6 是每个环节的操作细节（怎么做）；本节是整体骨架（在做什么）。理解整体在先，细节在后。
研究在一个会话内通过自循环持续推进，驱动器是 研究过程/研究队列.md：
启动落盘 → 读队列 → 选研究任务 → 研究 → 小额落盘 → 关闭/优化/拆分/补充队列 → 读队列 → …
只要还能从仓库只读取证，就必须继续推进，不许浅尝辄止。
以下情况不构成停止理由，必须继续推进：
研究过程/待解问题.md，转向另一个只读可取证任务。只有以下情况允许结束当前运行：
停止前必须把当前任务状态、已更新资产、队列状态和未解问题全部落盘（落盘时同步更新文件元信息，见 §4），保证下次能从 研究过程/研究队列.md 继续。
启动时建立可恢复的研究骨架，再开始长时间阅读：
定位或创建 .sdd/modules/<module>/。
创建缺失的认知资产骨架（见 asset-structure.md 初始骨架）。特别注意 业务功能/ 下的 业务流程/ 和 非流程功能点/ 两个子目录都要建——即使第一次没探索到非流程功能点，结构也要在，避免后续补充时丢失。
研究过程/研究队列.md 写入首批研究任务。理解不到位时，从下面 5 个固定维度切（保底模板，保证质量下限）：
| 维度 | 首批研究任务 | 为什么先切 |
|---|---|---|
| 入口与职责 | 模块怎么被调用、对外暴露什么 | 一切起点 |
| 核心业务流程 | 主路径（最常见场景端到端） | 模块主心骨 |
| 数据模型 | 涉及哪些表/数据结构 | 承载状态 |
| 关键约束 | 明显的业务规则/不变量 | 决定边界 |
| 异常与失败路径 | 主路径出错时怎么办 | 最易被浅尝辄止 |
不知道入口时，先写"定位入口"任务（从 API/Controller/Handler/Job/Consumer/公开函数、测试入口、配置入口入手）。
每个认知文件顶部维护一组元信息（与正文内容同级维护，不是独立动作）：状态、最后更新、最后同步提交。其中「最后同步提交」运行结束时用 git rev-parse HEAD 取值填入 <模块名>模块设计说明书.md，作为整个认知库的基线锚点，供后续判断认知对应代码停留在哪一刻——它是只读元信息，不读 diff、不做复核、不自动刷新；环境无法执行 git 时填"无法获取"，不因此阻塞研究。
没有写入首批任务前，不得开始长时间阅读代码，也不得输出只包含意图的计划。
一个合格的研究任务 = 一个可在一轮内取证完的单元，必须同时具备：
正例："退款主路径：从退款请求到账状态变更"、"审计日志写入：触发时机与不可变性保证"。
反例（不合格）：
每轮只研究一个任务，并把它推进到明确状态（已完成 / 阻塞 / 延后）。单轮步骤：
研究过程/研究队列.md 选最高价值且当前可即时取证的任务。价值排序：能即时取证 > 命中已有重要结论 > 位于核心运行路径 > 影响数据/状态/事务/外部契约 > 低置信。若证据不足，不要扩大结论，也不要把问题搁在脑中。强制做两件事：① 在 研究过程/待解问题.md 记一条（写清问题、卡在哪、需要什么才能解）；② 在队列安排下一步取证任务（若可转向只读切片）或转下一个任务。待解问题.md 不是垃圾抽屉——每个条目都要在 §7 recheck 时被处理（能解的转任务重进循环解掉，解不了的标注保留原因）。
研究完一个任务后，基于新理解对 研究过程/研究队列.md 做三件事——优化、拆分、补充并列：
硬约束：这三者是落盘的伴随动作，服务于提升后续研究质量；禁止只调队列不研究——不能花一整轮只优化/补充队列而不推进任何研究任务。
研究任务不许停在表层文件摘要，必须达到行为理解。核心路径、状态写入、跨模块契约、高风险区域的任务必须满足：
业务功能/业务流程/，非流程（横切/特殊场景）进 业务功能/非流程功能点/——拿"是不是端到端流程"判断归属。业务功能/，讲怎么做）和"纯约束规则"（进 约束与风险.md，讲不能破坏什么）——拿"有没有运作过程"判断归属。不许停留在"这个文件负责 XX""这是入口类"的罗列式描述（那只是清单，不是认知）。
研究过程/研究队列.md 为空或只剩粗粒度任务时，从以下来源拆出更小、更可取证的任务：
拆出的任务必须具体到可取证（某个路径、某个场景、某个问题），不要又拆出一个粗粒度方向。
研究队列走完、即将停止前，必须做一次系统性自审，不得跳过。这不是可选的润色，是交付的质量门。
逐项检查，发现问题全部记下：
业务功能/业务流程/ 和 业务功能/非流程功能点/ 下是否覆盖了模块的主要功能点；说明书「功能概览」索引表是否与实际文件一一对应。研究过程/待解问题.md 里每一条都要过——能解的转任务重进循环解掉，解不了的标注保留原因，不许让待解问题无限堆积成无人看的清单。自审发现的所有问题，全部转成新的研究任务放回 研究过程/研究队列.md，重新进入 §5 研究任务循环补窟窿。补完后再次自审，直到自审无新问题，才允许交付。
自审触点同时保证
待解问题.md至少被完整处理一次——这是它不沦为垃圾抽屉的硬保障。
FACT（有直接证据）、INFERRED（多信号推出但无直接明示）、CONFIRMED（团队/权威确认）、BLOCKED（材料不足且影响理解）。## 1. / ### 2.1），便于跨文档引用。**加粗**、<mark>高亮</mark>、<span style="color: red">红色</span>），用于真正需要醒目的少量关键结论、风险、阻塞项。A["退款入口"] --> B["写入审计"]）。<skill-dir>/references/asset-structure.md：认知资产目录结构、写入原则、结论状态和初始骨架。配置驱动的 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` 用于证据、过程复核和门禁记录，不得替代正式成果物中的开发和验证指导内容。