module-design-gate

Files (4)

• SKILL.md
• openai.yaml · agents/
• gate-checklist.md · references/
• gate-result-template.md · references/

SKILL.md (first lines)

---
name: module-design-gate
version: "2.3.2.8"
description: 对当前 SDD 工作流指定的正式《模块详细设计说明书.md》和独立《模块测试用例设计.md》进行质量门禁检查，围绕证据链、边界链、执行链、验证链和风险链判断成果物是否足以支持用户评审并进入后续 AICoding，同时识别实现细节越界、核心设计未讲清和冗余重复等低质量内容。当前需要确认详设和测试设计是否可进入 AICoding、发现阻断问题、生成整改清单、驱动回到 ASIS、TOBE 或测试设计补齐并多轮复检时使用。门禁阶段不得编辑正式说明书、测试设计正文或详细设计上下文；门禁结论单独写入模块目录下的 `.context/模块设计门禁结果.md`。
---

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

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

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

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

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

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

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

# SDD 模块设计门禁

## 阶段规则

本 skill 自身定义门禁阶段必须遵守的规则，可独立检查正式说明书；无论由何种入口调用，均以本 skill 的规则作为 Gate 阶段唯一执行依据。

## 运行方式

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

如果当前环境提供 `ask_user` 工具，影响门禁结论、有限准入范围、核心设计或验收阈值的待确认项必须优先用 `ask_user` 发起问询，并在 `.context/模块设计门禁结果.md` 中记录问题、回答、影响范围和处理结论；工具不可用时，才退回当前会话问询或标记为 `需前置确认`。

门禁不检查“章节是否写满”，而检查正式说明书和测试设计是否满足八个准入维度。Gate
的准入结论以维度化门禁结果为准；五链检查、严格探索和采样记录只用于支撑维度判断，不得绕过未达标维度直接给出通过。

八个准入维度是：

- 上游完整性。
- 证据充分性。
- 边界清晰性。
- 决策确定性。
- 契约完整性。
- 工程可执行性。
- 验证闭环性。
- 风险处置性。

五链是维度检查的证据结构，不是独立于维度的第二套准入体系：

- 证据链：需求/AR -> ASIS 证据 -> TOBE 决策。
- 边界链：模块边界 -> 职责分配 -> 交互约束。
- 执行链：TOBE 决策 -> 工程落点和开发视图 -> 后续 AICoding 可拆分。
- 验证链：TOBE 决策 -> 可测试性输入 -> 覆盖目标 -> 测试用例 -> 断言/观察点。
- 风险链：触发风险 -> 缓解设计 -> 验证/回退。

维度与五链的主要对应关系：

- 证据充分性、决策确定性主要由证据链支撑。
- 边界清晰性主要由边界链支撑。
- 契约完整性、工程可执行性主要由执行链支撑。
- 验证闭环性主要由验证链支撑。
- 风险处置性主要由风险链支撑。

## 成果物协作规则

- 正式成果物：`.sdd/{SR}/{AR}/{模块组名}/模块详细设计说明书.md`。
- 测试设计：`.sdd/{SR}/{AR}/{模块组名}/模块测试用例设计.md`。
- 详细设计上下文：`.sdd/{SR}/{AR}/{模块组名}/.context/详细设计上下文.md`。
- 门禁结果：`.sdd/{SR}/{AR}/{模块组名}/.context/模块设计门禁结果.md`。
- 需要综合之前的其他设计成果物进行审视
- `{模块组名}` 使用当前工作流确认的模块或模块组目录名；四个固定文件必须属于同一模块目录。
- 本 skill 不得创建、编辑或覆盖正式说明书中的任何章节。
- 本 skill 不得创建、编辑或覆盖测试设计成果物中的任何章节。
- 本 skill 在门禁结果文件中的写入边界是门禁结论（C1）、阻断问题（C2）、非阻断改进项（C3）、整改清单（C4）、上游设计反查（C5）、前置问询复核（C6）和遗留问题闭环复核（C7）。gate 的内部工作过程（执行 todo-list、逐维度达标判定、ASIS 采样记录、严格探索记录、大纲符合性检查、五链摘要、风险专题复核）不写入结果文件。
- 某项输入缺失会影响最终结论，但不能成为提前结束其他检查的理由；Gate 必须继续审查所有可读成果物，把能够独立发现的问题一并写入结果。
- 本 skill 可以读取 ASIS、TOBE、测试设计和风险章节，但不得直接覆盖其正文。
- 只有工作流、用户或成果物拆分规则明确要求时，门禁结果才写入独立门禁成果物，否则在当前会话返回。若由 `aaw-workflow` 编排调用，必须写入工作单 `output` 指定的 `.context/模块设计门禁结果.md`。
- 门禁引用的需求/AR 编号、TOBE 决策编号和契约编号必须来自正式说明书；覆盖目标、测试用例和测试缺口编号必须来自独立测试设计；ASIS
  证据编号必须能在 `.context/详细设计上下文.md` 的证据索引中反查。
- 如果某项开发必需内容只存在于详细设计上下文，正式说明书门禁必须判定为不通过，问题类型为 `EXECUTION` 或对应链路问题。
- 如果某项验证必需内容只存在于详细设计上下文或会话说明，测试设计门禁必须判定为不通过，问题类型为 `EXECUTION` 或 `RISK`
  ，关联维度为 `验证闭环性`。
- 正式说明书必须是面向用户、评审和开发的标准交付件；若正式说明书包含 ASIS 检索过程、证据编号表、TOBE
  推导过程、反证记录、门禁采样、追踪矩阵等过程性内容，或必须阅读详细设计上下文才能理解设计结论，门禁必须判定为不通过，问题类型为
  `EXECUTION`。
- 测试设计必须是面向测试实现和验证执行的标准交付件；正式测试设计不要求暴露目标抽取、风险分级、用例合并等推导过程。Gate
  不检查“是否写了过程”，而是从最小充分测试集、覆盖矩阵、用例可执行性和缺口回流反推测试设计质量。若测试用例只写“补充单测”“验证异常”“覆盖兼容”等概要，缺少输入、前置条件、断言、观察点或建议位置，门禁必须判定验证闭环性不通过。

## 强制工作步骤和 todo-list

Gate 阶段有偷懒风险，必须显式使用 todo-list 类工具跟踪检查过程，例如当前环境可用的 `update_plan`、TODO
工具或等价任务清单。没有可用工具时，必须在当前回复或 context 中维护“门禁待办清单”，并逐项标记状态。

开始门禁前必须创建至少包含以下项目的 todo-list（对应「工作流程」的步骤）：

1. 定位成果物与基线（说明书/测试设计/context/SR-design/AR-clarify）。
2. 执行检查：上游反查 → 八维度逐项 → 前置问询 → 遗留闭环 → 严格探索（见 `gate-checklist.md` 各节）。
3. 汇总未达标维度、阻断问题、整改清单，输出门禁结论和下一轮重试条件。

执行过程中必须在完成每个步骤后更新 todo-list 状态，并在维度化门禁检查表中逐项判定八个适用维度。不得在八个适用维度未逐项判定的情况下直接给出
`通过`、`不通过` 或 `阻塞` 结论。

## 门禁结论

门禁结论只能是：

- `通过`：所有适用维度均达标，阻断问题为 0，可进入 AICoding。
- `不通过`：存在必须整改的问题，需回到 ASIS、TOBE、测试设计或上游设计对齐。
- `阻塞`：缺少必要输入、代码、上游决策，或连续返工仍因同一外部缺口无法推进。

门禁还必须给出明确的门禁建议，用于指导下一轮重试：

- `可进入 AICoding`：所有适用维度达标，且阻断问题为 0。
- `回 ASIS 补证据后重试`：证据充分性未达标，或 ASIS 证据不能支撑 TOBE。
- `回 TOBE 补设计后重试`：决策确定性、契约完整性、工程可执行性、风险处置性未达标，或验证闭环性未达标且根因是 TOBE 可测试性输入不足。
- `回测试设计补用例后重试`：验证闭环性未达标，且根因是测试设计未形成最小充分验证集、覆盖矩阵或可执行用例。
- `先做上游/用户确认`：核心方案、模块边界、接口归属、数据归属、验收阈值或跨模块职责仍需外部确认。

From pi-ixel/Awesome-Agent-Workflow, MIT.

More from pi-ixel/Awesome-Agent-Workflow