module-asis-analysis

name	module-asis-analysis
description	对代码仓中某个模块内与特定 SDD 需求、AR、功能点、影响范围或计划变更相关的部分进行 ASIS 逆向分析，并只更新同名前缀 `.context.md` 中的详细证据、检索过程、边界确认记录、ASIS 探索任务清单、分任务查证结果、主 Agent 复核吸收记录、ASIS 结论和阻塞项。当前置 TOBE 详细设计、门禁或 AICoding 需要基于代码证据确认现状事实、隐藏约束、依赖、风险、测试覆盖和实现行为时使用。ASIS 阶段不得创建或编辑正式《{AR编号}-{需求短名}-{模块名}模块详细设计说明书.md》；正式说明书只能由 TOBE 阶段基于 context 证据生成。必须存在 `.sdd/software_architecture.md`，并且只能以该文件作为模块边界识别依据；缺失时中断。

SDD 模块 ASIS 分析

阶段规则

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

运行方式

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

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

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

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

职责边界

ASIS 负责：

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

ASIS 不负责：

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

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

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

目标

为目标模块中与本次需求相关的区域产出有代码证据支撑的 ASIS 分析，并更新同名前缀 .context.md：

• .context.md：记录详细 ASIS 证据、检索过程、边界确认记录、ASIS 探索任务清单、分任务查证结果、主 Agent 复核吸收记录、调用链展开、测试覆盖、关键 ASIS 结论、待确认问题和阻塞项。
• 正式说明书：ASIS 阶段不得写入；由 TOBE 阶段读取 .context.md 后，将必要 ASIS 摘要和证据引用写入正式说明书。

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

成果物协作规则

遵循用户或当前 SDD 工作流指定的成果物归属规则。对于本 skill，默认协作目标是同名前缀 .context.md。

• 正式成果物命名为 {AR编号}-{需求短名}-{模块名}模块详细设计说明书.md，例如 AR07758-支持快速退款接口相关功能-支付审计模块详细设计说明书.md。
• 过程上下文命名为 {AR编号}-{需求短名}-{模块名}模块详细设计说明书.context.md。
• 如果工作流未指定具体文件名，xxx模块详细设计说明书 只是占位名；同一轮 SDD 工作流中必须解析为同一个正式说明书和同名前缀 context 文件。
• 本 skill 不得创建、编辑或覆盖正式说明书中的任何章节。
• 本 skill 在 .context.md 中的写入边界是详细 ASIS 证据、证据索引、边界确认记录、代码检索过程、ASIS 探索任务清单、分任务查证结果、主 Agent 复核吸收记录、调用链/数据流展开、测试覆盖细节、关键 ASIS 结论、待确认问题和阻塞项。
• 本 skill 可以读取已有正式说明书、TOBE、风险、任务和门禁章节作为上下文，但不得覆盖这些章节；若发现需要修正，应记录为 ASIS 影响或待确认问题，交由后续 TOBE 阶段处理。
• 如果用户或工作流已提供正式说明书路径，使用同名前缀推导 .context.md 路径，除非工作流另有指定。
• 如果正式说明书尚不存在，不创建正式说明书；只创建或输出同名前缀 .context.md。
• 不要在没有依据的情况下另起一份孤立的 ASIS 文档；只有当工作流、用户或成果物拆分规则要求时，才拆分输出。
• .context.md 中的证据编号、ASIS 结论编号、需求/AR 映射编号、待确认问题编号，后续 TOBE 和门禁必须能够复用。
• 更新已有成果物时，只补充或修正 .context.md 中与 ASIS 有关的章节、证据索引和待确认问题。

范围原则

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

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

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

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

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

输入

可以接受以下任意组合：

• 当前 SDD 工作流指定的正式说明书路径、配套 .context.md 路径或当前草稿内容；未指定时按 {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，并在 .context.md 或返回结果中标记 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 查证并实时维护 .context.md，主 Agent 复核吸收后形成可被 TOBE 和门禁引用的证据链。

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

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

1. 定位上下文和边界，初始化 .context.md

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

1.1. 创建并初始化 .context.md：

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

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

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

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

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

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

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

阶段产出（必须在本阶段结束前写入 .context.md）：需求理解和现状关注点写入 C2. 需求理解与现状关注点，初步代码线索地图写入 C4. 初步代码线索地图。未写入前不得进入下一阶段。

3. 建立 ASIS 探索任务清单

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

每个探索任务至少包含：

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

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

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

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

阶段产出（必须在本阶段结束前写入 .context.md）：探索任务清单写入 C5. ASIS 探索任务清单。未写入前不得启动 SubAgent 查证或进入下一阶段。

3.1 纯新增场景

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

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

4. 分任务查证

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

分任务查证规则：

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

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

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

阶段产出（每批查证结束后必须写入 .context.md）：查证结果汇总写入 C6. 探索任务结果汇总，本批用到的检索路径和查询写入 C13. 代码检索过程，引用到的证据条目写入 C14. 证据索引。查证期间不落盘、攒到结束才写的做法是被禁止的。

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

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

复核至少包括：

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

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

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

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

阶段产出（复核吸收完成后必须写入 .context.md）：复核过程、分类结论、稳定编号生成、未采纳项及原因写入 C7. 主 Agent 复核与吸收记录。未写入前不得进入下一阶段。

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

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

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

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

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

阶段产出（必须在本阶段结束前写入 .context.md）：需求/AR 映射写入 C8. 完整需求/AR 与 ASIS 证据映射，关键事实写入 C9. 关键 ASIS 事实，调用链与数据流写入 C10. 当前机制、流程、调用链与数据流，配置/数据/测试/依赖现状写入 C11. 配置、数据、测试、依赖现状，隐藏机制/规格漂移/待确认/阻塞写入 C12. 隐藏机制、规格漂移、待确认与阻塞。

7. 最终整理 context 成果物

.context.md 的骨架在阶段 1 已创建，本阶段只做最终整理，不重新生成文件。若工作流未指定正式说明书，按 {AR编号}-{需求短名}-{模块名}模块详细设计说明书.md 推导同名前缀，但不创建或编辑正式说明书。

本步骤只做最终整理，不是首次生成完整 context。进入本步骤前，前六个阶段的阶段产出应已分别写入各自对应的 .context.md 章节（C1–C4、C5、C6/C13/C14、C7、C8–C12）。

最终整理时只允许：

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

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

.context.md 输出要服务后续 TOBE skill 和门禁（Gate）skill：

• 先说明本次需求或变更范围。
• 维护完整需求/AR 与 ASIS 证据映射、探索任务、证据链和检索过程。
• 具体到足以支撑工程设计。
• 严格区分 ASIS 与 TOBE。
• 除风险和待确认问题外，不提出最终实现方案。
• 范围、边界、依赖、证据和风险优先用表格表达。
• 只保留会影响详细设计或 AICoding 的待确认问题。
• ASIS 阶段不得把任何内容写入正式说明书；正式说明书中的 ASIS 摘要由 TOBE 阶段基于 .context.md 引用生成。

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

如果未来存在模块理解文档沉淀机制，本 skill 只把可沉淀的增量知识候选写入 .context.md 的对应章节；是否更新模块理解文档由独立 deep research 或知识沉淀流程处理。

阻塞与降级输出

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

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

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

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

质量标准

结束前必须确认：

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

如果未达到质量标准，继续分析；如果达到阻塞条件，则按阻塞与降级输出规则写入同名前缀 .context.md。

完成后回调

本 skill 产出同名前缀 .context.md（含 ASIS 证据、结论编号、需求/AR 映射、待确认问题和阻塞项），交付给 $module-tobe-design。TOBE 读取 .context.md 中的 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 组织 .context.md 中的 ASIS 证据、结论和过程章节。
• 使用 <skill-dir>/references/evidence-checklist.md 将仓库证据、配置、测试和隐藏约束检查项转化为 ASIS 探索问题。