dev-design-gate

Files (2)

• SKILL.md
• gate-report.md · references/

SKILL.md (first lines)

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

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

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

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

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

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

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

# dev-design-gate

## 定位

检查 `dev-design.md` 与 `test-design.md` 是否足以进入 `task-split`。门禁关注的是**下游能不能照着干活**——决策都定了、代码论断可信、契约和验收可执行——而不是文档形态或章节文采。

它是放行仪式加下游真依赖的硬检查，不再复查设计过程（取证是否发生、提问是否规范由 dev-design 的自检负责），也不挑与下游无关的常规性建议。

门禁阶段只读两份文档与相关输入，**不修改设计正文**。整改由上游 `dev-design` / `dev-test-design` 阶段完成。

## 检查对象

```text
.sdd/{SR}/dev-design.md       —— 必需
.sdd/{SR}/test-design.md      —— 必需
.sdd/{SR}/requirement.md      —— 可选，存在时对照核验范围
```

唯一成果物（门禁报告）：

```text
.sdd/{SR}/.context/dev-design-gate.md
```

## 3 项准入检查

每项给出 达标 / 未达标 判定（本门禁不使用"不适用"——三项对任何进入拆分的设计都是硬要求），未达标项必须指明问题出处与整改方向。

| # | 检查项 | 关注点 | 不达标影响 |
|---|---|---|---|
| 1 | **决策已收敛** | 需求目标与范围边界写清、明确不做什么；方案是**明确选择**，不存在"可选/待定/看情况"；存疑章节无影响实现或验证的未决项 | 拆分出的任务边界模糊，task-dev 自行发挥 |
| 2 | **代码论断可回溯** | 方案、契约变更、影响面中关于现有代码的论断均带 `file:line` 或明确定位；影响面文件路径经取证确认而非猜测 | 设计脱离现状凭空推导，task-dev 边做边猜、踩已有约束 |
| 3 | **契约与验收可执行** | 契约变更逐项写全（名称、位置、签名/字段、类型、调用方、错误语义、兼容策略）；`test-design.md` 存在且覆盖矩阵覆盖**全部**验收标准与契约变更项，缺口已清零或已登记回流 | 带病进入编码；无法判断完成与否 |

**核心验收不得待处理**：某条验收若无法设计出用例且没有回流归属，直接判第 3 项未达标。

## 结论判定

| 中文结论 | `gate_result` | 判定条件 |
|---|---|---|
| 通过 | `pass` | 3 项全达标，且不存在影响实现的存疑 |
| 不通过 | `fail` | 存在可通过修改 `dev-design.md` 或 `test-design.md` 解决的未达标项 |
| 阻塞 | `blocked` | 必需输入缺失不可读（如 `test-design.md` 不存在），或必须由用户提供事实/作出决策才能继续判断 |

任一检查项未达标或存在影响实现的存疑，**不得通过**。

## 具体流程

1. 完整读取 `dev-design.md` 与 `test-design.md`；存在 `requirement.md` 时对照核验范围是否被曲解或遗漏。
2. 按 3 项逐一判定，未达标项定位到具体文档的章节或行，给出整改方向（指明改 `dev-design.md` 还是 `test-design.md`，缺口类问题按回流登记处理）。
3. 汇总未达标项与需整改项，生成结论。
4. 按 `references/gate-report.md` 骨架写报告到 `.context/dev-design-gate.md`。
5. 按 `data_schema` 构造 `gate_result` / `recommendation` / `report` / `summary` 提交给 CLI：
   - `pass` 时 `unqualified_items` / `blocking_issues` / `pending_questions` 必须为 0；
   - `fail` / `blocked` 时如实填写未达标项与阻塞项数量。

## 报告边界

### 报告必须包含

- 本轮结论（通过/不通过/阻塞）与一句话理由；
- 未达标项列表（每项：检查项编号、问题描述、整改方向与整改对象文档）；
- 存疑或阻塞项列表。

### 报告不要包含

- 设计文档的复述或摘要；
- 与 3 项准入无关的常规性建议；
- 模板中本轮用不上的空章节。

## 自检清单

- [ ] 已完整读取 `dev-design.md` 与 `test-design.md`（及存在时的 `requirement.md`）。
- [ ] 3 项检查逐项判定，没有跳过。
- [ ] 覆盖矩阵核对过：全部验收标准与契约变更项都有覆盖用例，缺口清零或已登记回流。
- [ ] 报告已写入 `.context/dev-design-gate.md`，只含结论与需整改项。
- [ ] 结论与 `summary` 数字一致；`pass` 时三项均为 0。
- [ ] 未修改 `dev-design.md` / `test-design.md` 正文。

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

More from pi-ixel/Awesome-Agent-Workflow