module-asis-analysis

name	module-asis-analysis
version	2.3.2.2
description	对代码仓中某个模块内与特定 SDD 需求、AR、功能点、影响范围或计划变更相关的部分进行 ASIS 逆向分析，并只更新模块目录下的 `.context/详细设计上下文.md`，记录关键事实、证据索引、调用链、工程约束、规格漂移和阻塞项。当前置 TOBE 详细设计、门禁或 AICoding 需要基于代码证据确认现状事实、隐藏约束、依赖、风险、测试覆盖和实现行为时使用。ASIS 阶段不得创建或编辑正式《模块详细设计说明书.md》；正式说明书只能由 TOBE 阶段基于详细设计上下文中的证据生成。必须存在 `.sdd/software_architecture.md`，并且只能以该文件作为模块边界识别依据；缺失时中断。

前置操作：工作流编排检查

若本 skill 是由 aaw-workflow 的工作单调用的，跳过本节，直接执行正文。

否则，在执行正文之前，先向用户发起一次二选一确认：

是否回到 aaw-workflow 工作流中执行？

• 是，回到工作流（推荐）——进度会被跟踪和上报
• 否，单独执行本 skill——本次执行将不纳入流程跟踪

• 用户选“是” → 加载 aaw-workflow skill，按其流程执行（其入口意图判定会引导继续已有工作流或新建），不再单独执行本 skill 正文。
• 用户选“否” → 继续执行本 skill 正文，之后不再提及工作流。

本节最多询问一次，不得重复打扰。

若工作单输出已存在，仍按当前要求完整执行：先读取并评估已有成果，复用仍有效的信息和已确认答案，可局部修改或整体重写，并写回原路径。

重新核验时保留有效证据编号；失效证据须标记替代，并同步修正相关结论和映射。

SDD 模块 ASIS 分析

阶段规则

本 skill 自身定义 ASIS 阶段必须遵守的规则，可独立使用；无论由何种入口调用，均以本 skill 的规则作为 ASIS 阶段唯一执行依据。

运行方式

本 skill 应由当前主 Agent 直接执行，不要通过 SubAgent 启动；遇到需要用户或上游确认的问题，应在当前会话及时问询，避免 SubAgent 的运转模式导致问询滞后。

如果当前环境提供 ask_user 工具，ASIS 只能为需求事实、模块边界、现状事实或外部输入缺口发起问询，并在详细设计上下文中记录问题、回答、影响范围和处理结论；工具不可用时，才退回当前会话问询或标记为 需前置确认。

ASIS 不得要求用户在实现方案之间做选择。凡是“采用哪种存储”“复用哪个组件”“新增哪个接口”“是否引入调度器”“拦截点放在哪里”等 TOBE 设计选择，ASIS 只能记录为现状约束、可选设计输入或 TOBE 决策点，不得在 ASIS 阶段询问用户拍板。

本 skill 只回答一个问题：现状是什么，哪些不确定。ASIS 服务证据链和边界链，不写完整模块说明书，也不提前设计 TOBE。

职责边界

ASIS 负责：

• 确认需求事实、模块边界来源和本次分析切片。
• 查明现有入口、调用链、数据、配置、测试、依赖、隐藏机制和规格漂移。
• 区分 事实、推断、待确认 和 阻塞相关。
• 把现状约束、证据、风险、缺口和 TOBE 需要决策的问题记录到 .context/详细设计上下文.md。

ASIS 不负责：

• 选择 TOBE 实现方案、存储方案、接口形态、调度机制、评分机制、迁移策略或回滚策略。
• 要求用户从多个实现方案中拍板。
• 把“建议采用”“可以复用”“应新增”写成 ASIS 结论。
• 创建、编辑或补写正式模块详细设计说明书。

如果 ASIS 发现现状无法唯一支持后续设计，应写成 TOBE 决策输入 或 需前置确认：

• 需前置确认：需求含义、模块归属、外部事实或上游约束不清，缺少回答会导致 ASIS 无法判断事实或边界。
• TOBE 决策输入：事实已经查明，但存在多个设计路径，选择权属于 TOBE 阶段。

目标

为目标模块中与本次需求相关的区域产出有代码证据支撑的 ASIS 分析，并更新模块目录下的详细设计上下文：

• .context/详细设计上下文.md：记录关键 ASIS 事实、证据索引、模块边界、调用链/数据流、配置/数据/测试/依赖现状、规格漂移/待确认/阻塞和需求/AR 追溯矩阵。
• 模块详细设计说明书.md：ASIS 阶段不得写入；由 TOBE 阶段读取详细设计上下文后，将必要 ASIS 摘要和证据引用写入正式说明书。

这个 skill 不是用来编写泛化的模块说明书，而是用于支撑模块 TOBE 详细设计和后续编码实现。ASIS 只做现状事实发现，不做最终方案设计。

成果物协作规则

遵循用户或当前 SDD 工作流指定的成果物归属规则。默认目录结构为：

• 正式成果物：.sdd/{SR}/{AR}/{模块组名}/模块详细设计说明书.md。
• 过程上下文：.sdd/{SR}/{AR}/{模块组名}/.context/详细设计上下文.md。
• {模块组名} 使用当前工作流确认的模块或模块组目录名；文件名固定，不重复拼接 AR、需求短名或模块组名。
• 本 skill 不得创建、编辑或覆盖正式说明书中的任何章节。
• 本 skill 在详细设计上下文中的写入边界是关键 ASIS 事实（C3）、证据索引（C7）、模块边界（C2）、调用链/数据流（C4）、配置/数据/测试/依赖现状（C5）、规格漂移/待确认/阻塞（C6）和需求/AR 追溯矩阵（C8）。ASIS 的工作过程（线索建立、任务分派、SubAgent 查证、复核动作）不写入 context，留在主 Agent 内部会话中。
• 本 skill 可以读取已有正式说明书、TOBE、风险、任务和门禁章节作为上下文，但不得覆盖这些章节；若发现需要修正，应记录为 ASIS 影响或待确认问题，交由后续 TOBE 阶段处理。
• 如果用户或工作流已提供正式说明书路径，使用同一模块目录下的 .context/详细设计上下文.md，除非工作流另有指定。
• 如果正式说明书尚不存在，不创建正式说明书；只创建或输出详细设计上下文。
• 不要在没有依据的情况下另起一份孤立的 ASIS 文档；只有当工作流、用户或成果物拆分规则要求时，才拆分输出。
• 详细设计上下文中的证据编号、ASIS 结论编号、需求/AR 映射编号、待确认问题编号，后续 TOBE 和门禁必须能够复用。
• 更新已有成果物时，只补充或修正详细设计上下文中与 ASIS 有关的章节、证据索引和待确认问题。

范围原则

默认分析范围是 需求相关的模块内 ASIS。

• 从用户提供的需求、AR、功能点、影响性分析、模块间交互设计或计划变更出发。
• 识别目标模块中受本次需求影响的部分。
• 只分析会影响后续 TOBE 设计、实施任务、风险控制或测试设计的模块区域。
• 为解释行为或隐藏约束，可以向相邻文件、入口、依赖、配置、测试或跨模块交互扩展。
• 只有在用户明确要求完整模块 ASIS，或影响范围无法被可靠收敛时，才扩展到完整模块级 ASIS。

如果分析范围发生扩展，必须说明扩展原因。

如果本次需求高风险、模块低置信度、存在跨模块冷路径或关键隐藏约束无法排除，必须扩大分析范围到相邻入口、反向调用、测试、配置和依赖；若仍无法确认，必须写入待确认问题或 ASIS 阻塞项，不得只把置信度写成 低 后继续流转。

开始 ASIS 时必须判断本次变更类型：既有行为改造、纯新增行为 或 混合变更。纯新增行为是指需求明确计划新增能力，且代码检索确认目标入口、对象或配置当前不存在；不能只因搜索不到代码就判定为纯新增。

输入

可以接受以下任意组合：

• 当前 SDD 工作流指定的正式说明书路径、配套详细设计上下文路径或当前草稿内容；未指定时使用 .sdd/{SR}/{AR}/{模块组名}/模块详细设计说明书.md 和同目录下的 .context/详细设计上下文.md，但不创建或编辑正式说明书。
• 目标代码仓路径。
• 需求、功能点、用户故事、缺陷、AR 设计项或计划变更。
• 目标模块名称、目录、包路径、服务、类、API、Job、Consumer 或功能区域。
• 上游 SDD 产物，例如需求分析、功能设计、AR 设计、模块影响性分析、模块间交互设计。
• 用户关注的表、接口、消息主题、配置项、迁移、风险或行为。

如果代码仓可访问，必须直接检查代码。模块边界不得从代码结构推断，必须来自 .sdd/software_architecture.md；若该文件缺失、不可读或无法识别目标模块，立即中断。边界确认后，其他关键信息缺失但能从仓库中合理推断时，可以继续分析并显式标记假设。

模块边界规则

.sdd/software_architecture.md 是 ASIS 的必要输入和唯一模块边界来源。

1. 在识别模块前，必须检查当前工作区 .sdd/software_architecture.md。
   • 优先用直接路径检查，例如 PowerShell Test-Path .\.sdd\software_architecture.md、Get-Item .\.sdd\software_architecture.md 或 POSIX test -f .sdd/software_architecture.md。
   • 如果需要用文件搜索辅助定位隐藏目录，必须使用能包含隐藏目录的命令，例如 rg --files -uu .sdd；不要用裸 rg --files 判断 .sdd 文件是否存在，因为它通常会漏掉隐藏目录。
2. 如果 .sdd/software_architecture.md 不存在、不可读或不包含足以识别目标模块边界的内容，立即中断 ASIS，并在详细设计上下文或返回结果中标记 ASIS 阻塞；不得继续用代码结构、README、根目录架构文档或用户口述推断边界。
3. 用 .sdd/software_architecture.md 确认模块边界，再用本次需求或 AR 收窄模块内 ASIS 分析范围。
4. 如果用户指定的模块与 .sdd/software_architecture.md 冲突，必须记录双方信息，标记为边界冲突，并中断依赖该边界的 ASIS 定稿。
5. 模块边界只表达归属关系，将文件和组件分类为 确定属于模块、疑似属于模块 或 外部依赖。
6. 本次分析切片单独表达相关性，将文件、组件或行为分类为 需求相关、疑似相关 或 本次不分析。

边界来源必须显式标记为：

• declared by software_architecture.md：由 .sdd/software_architecture.md 直接声明。
• blocked：.sdd/software_architecture.md 缺失、不可读、目标模块缺失、声明含糊或与用户指定模块冲突。

不得推断模块边界。代码结构、import、测试、配置和 README 只能在 .sdd/software_architecture.md 已明确边界后，用于分析边界内 ASIS 事实；不能用于替代模块边界输入。

工作流程

ASIS 是一条「边查证边写入」的分阶段流水线：先把需求转化为代码问题，再逐任务由 SubAgent 查证并实时维护详细设计上下文，主 Agent 复核吸收后形成可被 TOBE 和门禁引用的证据链。

全程纪律（适用于每个阶段）：每个阶段完成后必须立即把结果写入详细设计上下文的对应章节（见各阶段末尾标注的产出章节），禁止在全部查证结束后才首次生成完整文档；未完成前一阶段的写入，不得进入下一阶段的核心动作。如果当前环境无法直接写文件，必须在会话中按同样阶段维护等价草稿，并在最终输出中说明哪些阶段已完成、哪些未完成。

阶段	核心动作	产出（对应详细设计上下文章节）
1. 定位上下文和边界，初始化详细设计上下文	加载模板创建带完整 C1–C8 骨架的文件，再确认模块边界和分析切片并填入骨架	文件创建 + C1、C2
2. 初步理解需求并建立代码线索	判断变更类型，把需求转化为现状关注点和初步代码线索	C3（标注为"推断"状态）
3. 建立 ASIS 探索任务清单	将关注点拆成以代码问题为单位的探索任务（3.1 纯新增场景单独处理）	内部维护，C3 的"来源探索"列记录任务编号
4. 分任务查证	由 SubAgent 并行逆向查证，实时记录证据和检索过程	C3（更新状态为"事实"/"修正后事实"）、C7
5. 主 Agent 复核、吸收和补查	复核证据，分类结论并生成稳定编号，补查子问题	C3（更新类型列：修正后事实/推断/待确认）
6. 建立调用链、约束和追溯映射	沉淀调用链、工程约束、规格漂移和需求覆盖映射	C4、C5、C6、C8
7. 最终整理 context 成果物	统一编号、清理痕迹、补齐不适用说明，完成一致性整理	C1–C8

1. 定位上下文和边界，初始化详细设计上下文

本阶段有两件事必须做：先立刻创建 .context/详细设计上下文.md 文件骨架，再确认模块边界和分析切片，并把确认结果写入刚刚建好的骨架。

1.1. 创建并初始化详细设计上下文：

• 按目录规则定位文件：.sdd/{SR}/{AR}/{模块组名}/.context/详细设计上下文.md；不存在时先创建 .context 目录。
• 加载 <skill-dir>/references/asis-output-template.md，把包含 C1–C8 全部固定目录的骨架写入文件；保留所有标题，不要等"有内容了"才建章节。
• 此时文件应是完整的空骨架，而不是空白文件或只写了一两章。后续每个阶段的产出都是在这份骨架的对应章节上填充，而不是临时新增标题。
• 如果详细设计上下文已存在，跳过创建，但仍需核对骨架是否包含完整的 C1–C8 固定目录；缺失的标题必须补回。

1.2. 确认边界和分析切片：

• 检查 .sdd/software_architecture.md 是否存在、可读，并记录采用的文件路径；缺失、不可读或目标模块缺失时中断。
• 定位当前 SDD 工作流指定的正式说明书路径和同一模块目录下的详细设计上下文路径。
• 明确本次 ASIS 要支撑的需求、AR 项、功能点、影响性分析、模块间交互设计或计划变更。
• 根据 .sdd/software_architecture.md 识别候选模块路径和模块名；边界冲突时中断依赖该边界的 ASIS 定稿。
• 如果用户引用了上游 SDD 产物，定位并阅读相关内容。
• 仓库搜索优先使用 rg 和 rg --files；涉及隐藏目录、.sdd、.github 或点文件时使用直接路径或 rg --files -uu <目录>。

阶段产出（必须在本阶段结束前写入详细设计上下文）：文件已创建（或已存在且骨架完整）；边界确认结果写入 C2. 模块边界确认，本次分析切片和状态写入 C1. ASIS 状态与阅读说明。未完成文件初始化前不得进入下一阶段。

2. 初步理解需求并建立代码线索

这一阶段不是定稿 ASIS，而是把需求转换成需要查证的代码问题。

• 判断本次变更类型：既有行为改造、纯新增行为 或 混合变更。
• 粗读需求、AR、上游设计和模块边界，列出会影响 TOBE 的现状关注点，例如入口归属、数据归属、配置形态、错误处理、兼容策略、权限、测试缺口、跨模块交互或隐藏机制。
• 初步扫描相关代码线索，包括入口、构建文件、依赖清单、路由、配置、迁移、脚本、测试、同类实现和反向引用。
• 如果存在模块理解文档或 module deep research 产物，可以作为初读线索；其中已有结论仍必须回到代码、配置或测试中复核。没有此类文档时，不阻塞 ASIS。
• 记录本次 ASIS 的初步代码线索，说明哪些文件、组件、配置、测试或外部交互可能相关，哪些只是待查线索。线索写入 C3 并标注类型为"推断"。

阶段产出（必须在本阶段结束前写入详细设计上下文）：需求理解和现状关注点写入 C3. 关键 ASIS 事实，类型标注为 推断（尚未代码查证）。未写入前不得进入下一阶段。

3. 建立 ASIS 探索任务清单

在深入逆向前，先形成 ASIS 探索任务清单。清单的单位是代码问题，而不是文档章节。

每个探索任务至少包含：

• 任务编号，例如 Q1、Q2。
• 要回答的问题，例如“现有配置如何加载并影响运行时行为”“是否已有同类实现可复用”“该流程失败时如何回滚”“当前 DTO 字段是否存在兼容别名”。
• 来源需求或现状关注点编号。
• 初始线索，包括文件、目录、搜索词、测试、配置或上游文档位置。
• 建议查证范围。
• 预期输出类型：事实、调用链、数据流、配置约束、测试覆盖、隐藏风险、待确认问题或阻塞项。
• 优先级：P0、P1、P2。

探索任务应覆盖会影响 TOBE、AICoding、验证或风险判断的问题。不要把所有清单项机械展开成深挖任务；低风险且与本次设计无关的线索可记录为不展开，并说明原因。

当受影响区域复杂、风险高、文档稀疏、配置形态不清、存在跨模块冷路径或隐藏机制无法排除时，使用 <skill-dir>/references/evidence-checklist.md 将检查项转化为探索问题。

不要为了套完整模板而生成大量空表；固定目录中无内容的章节写“不适用，原因：...”，不要删除标题。

阶段产出（必须在本阶段结束前完成）：探索任务清单在主 Agent 内部维护，每条任务的编号（Q1、Q2...）回填到 C3. 关键 ASIS 事实 的"来源探索"列。不单独创建探索任务章节，避免过程性内容稀释 context 信息密度。未完成前不得启动 SubAgent 查证或进入下一阶段。

3.1 纯新增场景

纯新增场景不是跳过 ASIS，而是将 ASIS 对象从既有实现行为改为承载新增能力的模块现状约束。

• 仍必须先用 .sdd/software_architecture.md 确认目标模块边界；如果新增能力的模块归属、接口归属或数据归属不清，标记为 需前置确认 或阻塞。
• 找不到既有入口、函数、配置项或测试时，记录为“新增对象当前不存在”，不得直接当作 ASIS 失败。
• 优先将“新增对象是否不存在”“相邻同类实现在哪里”“模块通用惯例是什么”“是否存在配置/注册/测试组织约束”拆成探索任务。
• 如果不存在相邻同类实现，记录检索证据，并显式标记“未发现可复用惯例”；该结论作为 TOBE 需要建立新约定或发起确认的输入，不在 ASIS 阶段补写方案。
• 详细设计上下文必须记录新增对象不存在的检索证据、可复用约束、未发现惯例的范围和仍需确认的问题；不得提前给出 TOBE 实现方案。

4. 分任务查证

主 Agent 负责组织 ASIS，把探索任务交给受控 SubAgent 并行查证。SubAgent 并行、聚焦、结果可复核，不要让 SubAgent 独立执行完整 ASIS，也不要让 SubAgent 直接定稿详细设计上下文。

分任务查证规则：

• 每个探索任务必须由独立 SubAgent 查证；主 Agent 负责组织、分派和复核，不替代 SubAgent 做代码查证。
• 任务输入必须包含：明确的问题、限定查证范围、初始线索（文件/目录/搜索词/配置/测试位置）、需要排除的误判和证据格式要求。
• SubAgent 输出必须包含：结论、证据编号候选、查过的路径或查询、未覆盖范围、置信度、待确认项和对 TOBE 的影响。
• 低置信度、无直接证据、只基于命名推断或存在文档/代码漂移的结果，不得直接升级为 ASIS 事实。
• 仅当执行环境确实无法启动 SubAgent 时，主 Agent 才可自行查证，但必须在 C1 标注「未使用 SubAgent，原因：环境不支持」。

查证时应围绕任务问题逆向当前行为：

• 从入口追踪到副作用，梳理主调用链。
• 识别输入、输出、状态变化、持久化、事件发送和外部调用。
• 识别校验、权限、审计、指标、日志和错误映射。
• 识别事务、重试、幂等、并发、缓存、降级和超时行为。
• 识别环境差异、功能开关、配置来源和配置默认值。
• 识别测试如何表达历史行为、边界场景、默认值和兼容约束。

阶段产出（每批查证结束后必须写入详细设计上下文）：查证结论写入 C3. 关键 ASIS 事实（更新类型为 事实/修正后事实/待确认），证据条目写入 C7. 证据索引（含位置和检索方式）。查证期间不落盘、攒到结束才写的做法是被禁止的。

5. 主 Agent 复核、吸收和补查

主 Agent 必须在吸收分任务结果前进行复核，不能把 SubAgent 输出原样当成最终 ASIS。

复核至少包括：

• 检查证据是否能定位到代码、配置、测试、迁移、路由、表、Topic、函数、类或命令输出摘要。
• 抽查关键结论对应的代码路径，尤其是 P0/P1 任务、低置信度任务、跨模块交互、配置行为和规格漂移。
• 合并重复或冲突结论；冲突无法消除时标记为待确认或阻塞。
• 将结论分类为 事实、推断、待确认 或 阻塞相关。
• 判断探索任务是否需要新增子问题；如果需要，补充任务并继续查证。
• 将被吸收的结论生成稳定 ASIS 结论编号，例如 A1、A2；未被吸收的查证结果保留为未采纳并说明原因。

每个会影响 TOBE、风险、测试或 AICoding 任务的 ASIS 结论都应有稳定结论编号。结论编号应在需求/AR 映射、关键事实、风险和待确认问题中复用，避免后续门禁无法定位采样对象。

如果待确认项会影响需求含义、模块边界、外部事实、上游约束、验收阈值或 ASIS 事实判断，必须立即向用户或上游负责人问询；若当前执行环境不能直接问询，则在详细设计上下文中标记为 需前置确认，并阻止依赖该问题的 TOBE 决策定稿。

如果问题只影响后续实现方案选择，而 ASIS 已能说明相关现状事实和约束，则不要在 ASIS 阶段问用户选择方案；将它记录为 TOBE 决策输入，由 TOBE 阶段基于 ASIS 证据提出方案和取舍。

阶段产出（复核吸收完成后必须写入详细设计上下文）：复核结论更新到 C3. 关键 ASIS 事实 的"类型"列（修正后事实/推断/待确认/阻塞相关），未采纳的查证结果不写入 C3（留在主 Agent 内部记录）。未写入前不得进入下一阶段。

6. 建立需求/AR 覆盖映射和关键事实

在详细设计上下文中维护完整的 需求/AR 与 ASIS 证据映射，用于证明本次 ASIS 已覆盖后续 TOBE 需要的现状事实；TOBE 阶段负责将必要摘要引用进正式说明书。

每条需求、AR 项、功能点或影响点至少记录：

• 编号和描述。
• 对应的现有入口、代码区域、数据对象、配置或外部交互。
• 纯新增场景下，对应的新增对象当前是否不存在，以及已检索范围。
• 对应的 ASIS 探索任务编号。
• 已确认的 ASIS 事实。
• ASIS 结论编号，例如 A1、A2，用于后续 TOBE 引用和门禁倾向采样。
• 证据编号，例如 E1、E2。
• 覆盖状态：已覆盖、部分覆盖、待确认、不涉及本模块。
• 未覆盖或待确认原因。

关键事实必须能支撑工程设计，不要仅根据命名判断职责。重要组件、配置、数据和测试结论必须绑定代码证据。

阶段产出（必须在本阶段结束前写入详细设计上下文）：调用链与数据流写入 C4. 调用链与数据流，配置/数据/测试/依赖现状写入 C5. 配置、数据、测试与依赖现状，隐藏机制/规格漂移/待确认/阻塞写入 C6. 规格漂移、待确认与阻塞，需求/AR 追溯矩阵写入 C8. 需求/AR 追溯矩阵。

7. 最终整理 context 成果物

详细设计上下文的骨架在阶段 1 已创建，本阶段只做最终整理，不重新生成文件。若工作流未指定正式说明书，使用同一模块目录下的 模块详细设计说明书.md，但不创建或编辑正式说明书。

本步骤只做最终整理，不是首次生成完整 context。进入本步骤前，前六个阶段的阶段产出应已分别写入详细设计上下文的对应章节（C1/C2、C3、C3+C7、C3、C4-C6/C8）。

最终整理时只允许：

• 补齐固定目录中缺失的“不适用，原因：...”或“未完成，原因：...；影响：...；下一步需要：...”。
• 统一编号、证据引用、章节交叉引用和状态标记。
• 删除不应进入正式 context 的对话痕迹、心理活动、试错叙事和过程回顾。
• 将方案选择表述改写为 ASIS 事实、现状约束或 TOBE 决策输入。

如果发现前置阶段没有维护草稿，不得直接补写成一份完整文档后宣称 ASIS 完成；必须将 ASIS 状态标记为 部分完成 或重新回到缺失阶段补做。

详细设计上下文要服务后续 TOBE skill 和门禁（Gate）skill：

• 先说明本次需求或变更范围。
• 维护关键 ASIS 事实、证据索引、需求/AR 追溯矩阵和规格漂移/待确认项。
• 具体到足以支撑工程设计。
• 严格区分 ASIS 与 TOBE。
• 除风险和待确认问题外，不提出最终实现方案。
• 范围、边界、依赖、证据和风险优先用表格表达。
• 只保留会影响详细设计或 AICoding 的待确认问题。
• ASIS 阶段不得把任何内容写入正式说明书；正式说明书中的 ASIS 摘要由 TOBE 阶段基于详细设计上下文引用生成。

涉及多入口、多组件协作、跨模块交互、状态变化、写后读、异常路径或回滚时，ASIS 必须补充现状流程图或时序图；简单单函数变更可写明不适用原因。图示应服务后续开发理解调用顺序和责任边界，不要求覆盖完整模块。

如果未来存在模块理解文档沉淀机制，本 skill 在会话中标记可沉淀的增量知识候选；是否更新模块理解文档由独立 deep research 或知识沉淀流程处理，不写入详细设计上下文。

阻塞与降级输出

如果继续分析后仍无法达到质量标准，不要用猜测补齐。必须在详细设计上下文中写入 ASIS 阻塞项，并标记 ASIS 状态为 阻塞 或 部分完成。

出现以下情况时可以阻塞：

• 无法访问必要代码或关键目录。
• .sdd/software_architecture.md 缺失、不可读、目标模块缺失、声明含糊或与用户指定模块冲突。
• 缺少必要的需求、AR 或变更描述，导致无法定义分析切片。
• 关键运行时行为只存在于不可访问的配置、环境、外部系统或生产数据中。
• 上游 SDD 产物互相矛盾，导致无法判断本模块职责。

阻塞输出必须包含：阻塞原因、已完成的分析范围、不能确认的结论、继续推进需要的输入、对 TOBE/AICoding 的影响。禁止把阻塞项伪装成事实。

质量标准

结束前必须确认：

• 已检查 .sdd/software_architecture.md，并在缺失、不可读或目标模块缺失时中断。
• 已明确目标需求、AR 项、功能点或计划变更。
• 已确认 ASIS 问询只针对需求事实、模块边界、外部事实或 ASIS 判断缺口；实现方案选择已记录为 TOBE 决策输入，没有在 ASIS 阶段要求用户拍板。
• 已明确并分类模块边界。
• 已明确需求相关的分析切片和初步代码线索（线索已写入 C3，标注为"推断"状态）。
• 已判断变更类型；纯新增场景已记录新增对象不存在的检索证据、相邻同类实现或不存在相邻实现时可替代的模块惯例。
• 已将需求、上游设计和代码线索转化为探索任务并完成查证（任务编号回填 C3"来源探索"列）。
• 每个影响 TOBE、AICoding、验证或风险判断的探索任务都有查证结果，或明确记录未完成原因、影响和下一步输入。
• 每个探索任务已由 SubAgent 查证（环境不支持时已在 C1 标注原因），主 Agent 已复核证据并记录吸收、修正、未采纳或补查结论。
• 已维护需求/AR 追溯矩阵（C8），并能追溯到 ASIS 结论编号和证据编号。
• 当模块大于本次受影响范围时，已说明不在本次分析范围内的区域。
• 已检查相关入口、内部组件、外部依赖、配置、数据和测试。
• 主行为已沿真实代码路径追踪。
• 已主动搜索隐藏约束和风险。
• 已记录设计文档、README、测试与代码之间影响本次需求的规格漂移。
• 重要结论有证据。
• 详细设计上下文中的 ASIS 结论均能反查到证据索引；后续正式说明书可引用这些编号。
• 已区分事实、推断和待确认。
• 如果分析置信度为 低，或关键结论仅为 推断/待确认，已写入待确认问题或 ASIS 阻塞项，并说明对 TOBE/AICoding 的影响。
• 详细设计上下文使用固定 ASIS 目录；无内容、未完成或不适用的章节保留标题并写明原因。
• 详细设计上下文不是分析结束后首次完整生成的文档；C1/C2、C3、C3+C7、C4-C6/C8 已按阶段维护，或已在阻塞/部分完成说明中标明缺失阶段。
• 正式详细设计上下文没有写入对话痕迹、心理活动、工具试错叙事、执行者自评或过程回顾。
• 未将 TOBE 方案混入 ASIS 结论。

如果未达到质量标准，继续分析；如果达到阻塞条件，则按阻塞与降级输出规则写入详细设计上下文。

完成后回调

本 skill 产出 .context/详细设计上下文.md（含 ASIS 证据、结论编号、需求/AR 映射、待确认问题和阻塞项），交付给 $module-tobe-design。TOBE 读取其中的 ASIS 结论编号、证据编号和需求/AR 映射作为目标设计的现状输入。

若不处于 aaw-workflow 编排中，请忽略此节。

本 skill 由 aaw-workflow 编排调用。交付件生成后：

1. 返回 aaw-workflow 流程
2. 执行 aaw next --sr <SR号> --json 查看进度
3. 若返回 deliverables_exist: true → 直接 aaw done --sr <SR> <id>
4. 否则 → 停止；是否放行下一步由 aaw-workflow 的 user_confirm 策略控制

不记得 SR 号 → 先 aaw status --json

引用文件

• 使用 <skill-dir>/references/asis-output-template.md 组织详细设计上下文中的 ASIS 证据、结论和过程章节。
• 使用 <skill-dir>/references/evidence-checklist.md 将仓库证据、配置、测试和隐藏约束检查项转化为 ASIS 探索问题。