@haaaiawd/anws 2.2.6 → 2.4.0

package/templates/.agents/skills/sequential-thinking/SKILL.md

@@ -1,225 +1,222 @@
----
-
-## name: sequential-thinking
-
-description: 当复杂问题需要系统性逐步推理时使用。适用于多阶段分析、设计规划、问题分解，或初始范围不明确且需要受控收敛的任务。
-license: MIT
-
-# Sequential Thinking
-
-这个 skill 的核心不是“多写几段 thought”，而是让 AI 在复杂问题里**持续推进、允许修正，并最终收敛成结论**。CLI 只是执行载体；skill 本身负责定义什么时候该进入这种思考方式，以及如何避免把顺序思考退化成松散输出。
-
-## Mission
-
-这个 skill 用来把复杂问题处理成一个**有边界、可修正、可复核的推理过程**：
-
-- 先澄清问题，而不是急着给答案
-- 在推进过程中允许修正和调整判断
-- 在复杂度上升时比较替代路径，而不是单线硬推
-- 在有限步数内收敛成结论与建议
-- 最后保留可回放的推理轨迹
-
-它解决的不是“不会想”，而是“想得太散、太早下结论、太难复核”。
-
-## Core Capabilities
-
-- **迭代推进**: 把复杂问题拆成连续步骤，而不是试图一口气得到完整答案
-- **动态修正**: 当新证据出现时，允许回看并修正前面的判断
-- **分支比较**: 当存在替代路径时，允许先比较再收敛
-- **上下文保持**: 在多步推理中维持清晰的问题边界与目标
-- **结论收束**: 最终必须形成判断，而不是无限发散
-
-## When to Use
-
-### 核心判断规则
-
-> **模型能力决定基线，任务复杂度决定是否升级。**
-
-
-| 模型能力          | 简单任务            | 复杂任务            |
-| ------------- | --------------- | --------------- |
-| **有思维链（CoT）** | 自然 CoT 即可       | 调用 ST CLI       |
-| **无思维链**      | **必须调用 ST CLI** | **必须调用 ST CLI** |
-
-
-### 判断口诀
-
-> **"无 CoT → 必须用 ST**
-> **有 CoT → 复杂才用 ST"**
-
-### 必须调用 CLI 的场景
-
-
-| 场景           | 判断标准                 | 为什么需要 CLI           |
-| ------------ | -------------------- | ------------------- |
-| **无 CoT 模型** | 当前模型不支持思维链输出         | 必须依赖外部工具组织推理        |
-| **修正前提**     | 推理过程中发现前面判断错了，需要回头修正 | CLI 会话保留历史，支持回看修正   |
-| **多方案比较**    | 需要在 2+ 个候选方案之间做权衡决策  | `branch` 模式专为分支比较设计 |
-| **可回放轨迹**    | 需要留下可审计、可复现的推理过程     | CLI 支持生成 replay 文档  |
-| **复杂收敛**     | 问题需要 > 5 步才能收敛到结论    | 强制步数限制防止无限发散        |
-
-
-### 有 CoT 时可直接用自然 CoT 的场景
-
-
-| 场景        | 判断标准             | 为什么不需要 CLI           |
-| --------- | ---------------- | -------------------- |
-| **单向推理**  | 不需要回头修正，线性推进     | 模型自然输出即可             |
-| **简单分析**  | 问题边界清晰、步骤 < 5    | 不需要复杂工具辅助            |
-| **快速决策**  | 只需结论，不需要可回放轨迹    | CoT 足够表达推理           |
-| **探索性思考** | 还在发散阶段，不确定是否需要收敛 | 先用 CoT 探索，再决定是否用 CLI |
-
-
-### 决策树
-
-```mermaid
-flowchart TD
-    A[需要多步推理?] -->|否| Z[直接回答]
-    A -->|是| B{模型有 CoT?}
-    B -->|否| CLI[必须调用 ST CLI]
-    B -->|是| C{任务复杂?}
-    C -->|简单: 步骤 < 5, 无修正| CoT[自然 CoT]
-    C -->|复杂: 修正/比较/回放| CLI
-```
-
-
-
-### 不适用场景
-
-- 简单事实查询
-- 单步即可完成的任务
-- 路径已经非常明确、无需多步推演的问题
-- 纯头脑风暴且暂时不要求收敛的场景
-
-## Working Philosophy
-
-- **先找主问题，再找答案**：不要把现象描述误当作根因定位
-- **允许修正，而不是硬撑前提**：前面想错了，就回头修，不要带着错误前提继续推进
-- **先消除复杂度，再堆解决方案**：优先识别主矛盾，而不是抢着给补丁
-- **每一步只推进一步**：当前步只表达当前判断，不重复整套背景
-- **最终必须落到结论**：不能把“我还能继续想”当作默认出口
-
-## Installation & Runtime Model
-
-这个 skill 面向 agent 交付思考方式与调用约束；CLI 通过 npm 分发。
-
-在使用前，应先确保本地已安装对应 CLI：
-
-```bash
-npm install -g sequential-thinking-cli
-
-# 或
-pnpm add -g sequential-thinking-cli
-```
-
-安装后，使用 `sthink` 作为命令入口。
-
-## CLI Contract
-
-本 skill 不再要求 AI 手写 thought JSON。执行层通过 CLI 主路径动作完成：
-
-- `start`
-- `step`
-- `replay`
-
-### `start`
-
-只接受四个输入：
-
-- `name`
-- `goal`
-- `mode`
-- `totalSteps`
-
-约束：
-
-- `mode` 仅允许 `explore`、`branch`、`audit`
-- `totalSteps` 仅允许 `5` 或 `8`
-
-如果你不确定该选哪种模式，默认用 `explore`。只有在任务明显是在比较候选路径时才用 `branch`；只有在任务明显是在审查既有判断时才用 `audit`。
-
-### `step`
-
-只接受：
-
-- `content`
-
-其余上下文应由 runtime 自动恢复并注入。
-
-### `replay`
-
-用于读取已完成会话并生成 replay 文档；如需要，可额外导出到当前目录。
-
-## Recommended Workflow
-
-```text
-1. 先判断问题是否真的需要 sequential-thinking，而不是默认套用。
-2. 如需要，先安装或确认本地已有 npm CLI。
-3. 用 `sthink start` 给出 `name`、`goal`、`mode`、`totalSteps`。
-4. 用 `sthink step` 逐步推进，每一步只写当前推进内容。
-5. 当出现新证据时，允许修正，而不是硬撑旧判断。
-6. 到收敛阶段时，必须输出结论、风险与下一步建议。
-7. 完成后按需使用 `sthink replay` 生成与导出回放文档。
-```
-
-## Examples
-
-以下示例不是为了让你回去手写 JSON，而是为了说明这种 skill 真正有价值的地方：**如何推进、如何修正、如何收敛**。
-
-### Example 1: 基础推演
-
-```bash
-sthink start --name "query-diagnosis" --goal "定位查询性能下降的主因" --mode explore --totalSteps 5
-sthink step --sessionPath "<session-path>" --content "先不要急着选优化手段。需要先把问题拆成几层：是单条 SQL 退化、接口级 N+1，还是更上层的调用放大。若根因没分清，后面的缓存、索引、重写都可能只是补丁。"
-sthink step --sessionPath "<session-path>" --content "从查询日志看，用户详情接口在一次请求里触发了大量重复读取，已经出现明显的 N+1 信号。但还不能直接下结论，因为重复查询也可能只是症状；需要继续确认慢点究竟来自“查询次数过多”，还是“某条关键查询本身很慢”。因此总步数上调一档。"
-sthink step --sessionPath "<session-path>" --content "结论可以收敛了：主因是列表页批量加载时触发的 N+1，次因是关联字段缺少索引放大了单次查询成本。优化顺序应该先消除 N+1，再补索引验证尾延迟；这样既先打掉主矛盾，也避免一上来引入缓存复杂度。"
-```
-
-### Example 2: 修正前提
-
-```bash
-sthink step --sessionPath "<session-path>" --content "回看 profiling 结果后，前面的判断需要修正：真正拖垮接口的不是 N+1 本身，而是关联列缺少索引，导致每次关联查询都在放大全表扫描成本。也就是说，N+1 仍然存在，但它不是第一性瓶颈，优先级应该后移。"
-```
-
-### Example 3: 复杂变更拆解
-
-```bash
-sthink start --name "change-impact-analysis" --goal "拆解复杂变更的影响与优先级" --mode explore --totalSteps 5
-sthink step --sessionPath "<session-path>" --content "用户一次性提出了多项规则修改，不该把它们当成同一种改动处理。先拆开看：有的是机制原则调整，有的是数值平衡，有的是接口语义变化，还有的是文档与实现脱节。如果不先分型，后面会把“该改 ADR 的”“该改设计文档的”“该补代码契约的”混成一锅。"
-sthink step --sessionPath "<session-path>" --content "先做影响矩阵。机制原则类改动通常会回流到 ADR 和 System Design；数值平衡会影响规则表、配置与测试基线；接口语义变化最危险，因为它会悄悄破坏调用方的假设。这里最该警惕的不是改动数量，而是有没有改到“被多个模块默认依赖、但文档里没写清楚”的隐性契约。"
-sthink step --sessionPath "<session-path>" --content "可以收敛了：先处理那些会改变系统边界或调用语义的项，再处理数值与体验层面的项。顺序上应优先修正文档与契约，再讨论平衡性；否则后续所有实现和评审都会建立在漂移的前提上。结论不是“先改最显眼的”，而是“先修最容易污染系统认知的”。"
-```
-
-### Example 4: 分支比较
-
-```bash
-sthink start --name "performance-tradeoff" --goal "比较缓存止血与查询优化的优先级" --mode branch --totalSteps 5
-sthink step --sessionPath "<session-path>" --content "方案 A：先引入缓存削峰。好处是见效快、对接口层侵入小，适合先止血；坏处是会把问题从“数据库慢”转成“缓存一致性与失效策略复杂”，如果根因其实是查询设计不合理，这条路容易把偶然复杂度永久留在系统里。与此同时，方案 B：直接做索引优化和查询重写。好处是从根上消除瓶颈，长期结构更干净；代价是需要更仔细验证写入放大、锁竞争和回归风险。这条路更慢，但如果业务模型稳定，通常比提前上缓存更符合简单优先的原则。"
-```
-
-## Storage & Export Boundary
-
-- runtime 会自动保存会话状态与步骤记录
-- 完成态可生成 replay 文档
-- `replay` 支持导出到当前目录，便于审阅与复用
-
-## Heuristic Reminders
-
-以下提醒是启发式问题，不是硬约束。真正重要的是：它们能帮助你减少空转，逼近结论。
-
-- **问题定义提醒**: 你现在是在描述现象，还是在定位根因？
-- **证据提醒**: 当前判断基于事实、观察结果，还是基于猜测与假设？
-- **边界提醒**: 当前问题影响的是局部模块、单系统，还是跨系统结构？
-- **复杂度提醒**: 你是在消除本质复杂度，还是在增加偶然复杂度？
-- **收敛提醒**: 当前是否已经足够形成结论，还是仍在无效发散？
-
-## Tips
-
-- 不要再手写 thought JSON；让 CLI runtime 负责节奏、落盘与 replay
-- 不要把 sequential-thinking 当成默认模式，只在真正需要多步收敛时调用
-- 如果不确定模式，先用 `explore`
-- `step` 的 `content` 只表达当前推进内容，不要重复补全系统上下文
-- 如果发现前提错了，就明确修正，不要硬撑
-- 到收敛阶段时，应明确输出结论、风险和下一步动作
-- 只有已完成会话才能执行 `replay`
-
+---
+name: sequential-thinking
+description: 当复杂问题需要系统性逐步推理时使用。适用于多阶段分析、设计规划、问题分解，或初始范围不明确且需要受控收敛的任务。
+---
+
+# Sequential Thinking
+
+这个 skill 的核心不是“多写几段 thought”，而是让 AI 在复杂问题里**持续推进、允许修正，并最终收敛成结论**。CLI 只是执行载体；skill 本身负责定义什么时候该进入这种思考方式，以及如何避免把顺序思考退化成松散输出。
+
+## Mission
+
+这个 skill 用来把复杂问题处理成一个**有边界、可修正、可复核的推理过程**：
+
+- 先澄清问题，而不是急着给答案
+- 在推进过程中允许修正和调整判断
+- 在复杂度上升时比较替代路径，而不是单线硬推
+- 在有限步数内收敛成结论与建议
+- 最后保留可回放的推理轨迹
+
+它解决的不是“不会想”，而是“想得太散、太早下结论、太难复核”。
+
+## Core Capabilities
+
+- **迭代推进**: 把复杂问题拆成连续步骤，而不是试图一口气得到完整答案
+- **动态修正**: 当新证据出现时，允许回看并修正前面的判断
+- **分支比较**: 当存在替代路径时，允许先比较再收敛
+- **上下文保持**: 在多步推理中维持清晰的问题边界与目标
+- **结论收束**: 最终必须形成判断，而不是无限发散
+
+## When to Use
+
+### 核心判断规则
+
+> **模型能力决定基线，任务复杂度决定是否升级。**
+
+
+| 模型能力          | 简单任务            | 复杂任务            |
+| ------------- | --------------- | --------------- |
+| **有思维链（CoT）** | 自然 CoT 即可       | 调用 ST CLI       |
+| **无思维链**      | **必须调用 ST CLI** | **必须调用 ST CLI** |
+
+
+### 判断口诀
+
+> **"无 CoT → 必须用 ST**
+> **有 CoT → 复杂才用 ST"**
+
+### 必须调用 CLI 的场景
+
+
+| 场景           | 判断标准                 | 为什么需要 CLI           |
+| ------------ | -------------------- | ------------------- |
+| **无 CoT 模型** | 当前模型不支持思维链输出         | 必须依赖外部工具组织推理        |
+| **修正前提**     | 推理过程中发现前面判断错了，需要回头修正 | CLI 会话保留历史，支持回看修正   |
+| **多方案比较**    | 需要在 2+ 个候选方案之间做权衡决策  | `branch` 模式专为分支比较设计 |
+| **可回放轨迹**    | 需要留下可审计、可复现的推理过程     | CLI 支持生成 replay 文档  |
+| **复杂收敛**     | 问题需要 > 5 步才能收敛到结论    | 强制步数限制防止无限发散        |
+
+
+### 有 CoT 时可直接用自然 CoT 的场景
+
+
+| 场景        | 判断标准             | 为什么不需要 CLI           |
+| --------- | ---------------- | -------------------- |
+| **单向推理**  | 不需要回头修正，线性推进     | 模型自然输出即可             |
+| **简单分析**  | 问题边界清晰、步骤 < 5    | 不需要复杂工具辅助            |
+| **快速决策**  | 只需结论，不需要可回放轨迹    | CoT 足够表达推理           |
+| **探索性思考** | 还在发散阶段，不确定是否需要收敛 | 先用 CoT 探索，再决定是否用 CLI |
+
+
+### 决策树
+
+```mermaid
+flowchart TD
+    A[需要多步推理?] -->|否| Z[直接回答]
+    A -->|是| B{模型有 CoT?}
+    B -->|否| CLI[必须调用 ST CLI]
+    B -->|是| C{任务复杂?}
+    C -->|简单: 步骤 < 5, 无修正| CoT[自然 CoT]
+    C -->|复杂: 修正/比较/回放| CLI
+```
+
+
+
+### 不适用场景
+
+- 简单事实查询
+- 单步即可完成的任务
+- 路径已经非常明确、无需多步推演的问题
+- 纯头脑风暴且暂时不要求收敛的场景
+
+## Working Philosophy
+
+- **先找主问题，再找答案**：不要把现象描述误当作根因定位
+- **允许修正，而不是硬撑前提**：前面想错了，就回头修，不要带着错误前提继续推进
+- **先消除复杂度，再堆解决方案**：优先识别主矛盾，而不是抢着给补丁
+- **每一步只推进一步**：当前步只表达当前判断，不重复整套背景
+- **最终必须落到结论**：不能把“我还能继续想”当作默认出口
+
+## Installation & Runtime Model
+
+这个 skill 面向 agent 交付思考方式与调用约束；CLI 通过 npm 分发。
+
+在使用前，应先确保本地已安装对应 CLI：
+
+```bash
+npm install -g sequential-thinking-cli
+
+# 或
+pnpm add -g sequential-thinking-cli
+```
+
+安装后，使用 `sthink` 作为命令入口。
+
+## CLI Contract
+
+本 skill 不再要求 AI 手写 thought JSON。执行层通过 CLI 主路径动作完成：
+
+- `start`
+- `step`
+- `replay`
+
+### `start`
+
+只接受四个输入：
+
+- `name`
+- `goal`
+- `mode`
+- `totalSteps`
+
+约束：
+
+- `mode` 仅允许 `explore`、`branch`、`audit`
+- `totalSteps` 仅允许 `5` 或 `8`
+
+如果你不确定该选哪种模式，默认用 `explore`。只有在任务明显是在比较候选路径时才用 `branch`；只有在任务明显是在审查既有判断时才用 `audit`。
+
+### `step`
+
+只接受：
+
+- `content`
+
+其余上下文应由 runtime 自动恢复并注入。
+
+### `replay`
+
+用于读取已完成会话并生成 replay 文档；如需要，可额外导出到当前目录。
+
+## Recommended Workflow
+
+```text
+1. 先判断问题是否真的需要 sequential-thinking，而不是默认套用。
+2. 如需要，先安装或确认本地已有 npm CLI。
+3. 用 `sthink start` 给出 `name`、`goal`、`mode`、`totalSteps`。
+4. 用 `sthink step` 逐步推进，每一步只写当前推进内容。
+5. 当出现新证据时，允许修正，而不是硬撑旧判断。
+6. 到收敛阶段时，必须输出结论、风险与下一步建议。
+7. 完成后按需使用 `sthink replay` 生成与导出回放文档。
+```
+
+## Examples
+
+以下示例不是为了让你回去手写 JSON，而是为了说明这种 skill 真正有价值的地方：**如何推进、如何修正、如何收敛**。
+
+### Example 1: 基础推演
+
+```bash
+sthink start --name "query-diagnosis" --goal "定位查询性能下降的主因" --mode explore --totalSteps 5
+sthink step --sessionPath "<session-path>" --content "先不要急着选优化手段。需要先把问题拆成几层：是单条 SQL 退化、接口级 N+1，还是更上层的调用放大。若根因没分清，后面的缓存、索引、重写都可能只是补丁。"
+sthink step --sessionPath "<session-path>" --content "从查询日志看，用户详情接口在一次请求里触发了大量重复读取，已经出现明显的 N+1 信号。但还不能直接下结论，因为重复查询也可能只是症状；需要继续确认慢点究竟来自“查询次数过多”，还是“某条关键查询本身很慢”。因此总步数上调一档。"
+sthink step --sessionPath "<session-path>" --content "结论可以收敛了：主因是列表页批量加载时触发的 N+1，次因是关联字段缺少索引放大了单次查询成本。优化顺序应该先消除 N+1，再补索引验证尾延迟；这样既先打掉主矛盾，也避免一上来引入缓存复杂度。"
+```
+
+### Example 2: 修正前提
+
+```bash
+sthink step --sessionPath "<session-path>" --content "回看 profiling 结果后，前面的判断需要修正：真正拖垮接口的不是 N+1 本身，而是关联列缺少索引，导致每次关联查询都在放大全表扫描成本。也就是说，N+1 仍然存在，但它不是第一性瓶颈，优先级应该后移。"
+```
+
+### Example 3: 复杂变更拆解
+
+```bash
+sthink start --name "change-impact-analysis" --goal "拆解复杂变更的影响与优先级" --mode explore --totalSteps 5
+sthink step --sessionPath "<session-path>" --content "用户一次性提出了多项规则修改，不该把它们当成同一种改动处理。先拆开看：有的是机制原则调整，有的是数值平衡，有的是接口语义变化，还有的是文档与实现脱节。如果不先分型，后面会把“该改 ADR 的”“该改设计文档的”“该补代码契约的”混成一锅。"
+sthink step --sessionPath "<session-path>" --content "先做影响矩阵。机制原则类改动通常会回流到 ADR 和 System Design；数值平衡会影响规则表、配置与测试基线；接口语义变化最危险，因为它会悄悄破坏调用方的假设。这里最该警惕的不是改动数量，而是有没有改到“被多个模块默认依赖、但文档里没写清楚”的隐性契约。"
+sthink step --sessionPath "<session-path>" --content "可以收敛了：先处理那些会改变系统边界或调用语义的项，再处理数值与体验层面的项。顺序上应优先修正文档与契约，再讨论平衡性；否则后续所有实现和评审都会建立在漂移的前提上。结论不是“先改最显眼的”，而是“先修最容易污染系统认知的”。"
+```
+
+### Example 4: 分支比较
+
+```bash
+sthink start --name "performance-tradeoff" --goal "比较缓存止血与查询优化的优先级" --mode branch --totalSteps 5
+sthink step --sessionPath "<session-path>" --content "方案 A：先引入缓存削峰。好处是见效快、对接口层侵入小，适合先止血；坏处是会把问题从“数据库慢”转成“缓存一致性与失效策略复杂”，如果根因其实是查询设计不合理，这条路容易把偶然复杂度永久留在系统里。与此同时，方案 B：直接做索引优化和查询重写。好处是从根上消除瓶颈，长期结构更干净；代价是需要更仔细验证写入放大、锁竞争和回归风险。这条路更慢，但如果业务模型稳定，通常比提前上缓存更符合简单优先的原则。"
+```
+
+## Storage & Export Boundary
+
+- runtime 会自动保存会话状态与步骤记录
+- 完成态可生成 replay 文档
+- `replay` 支持导出到当前目录，便于审阅与复用
+
+## Heuristic Reminders
+
+以下提醒是启发式问题，不是硬约束。真正重要的是：它们能帮助你减少空转，逼近结论。
+
+- **问题定义提醒**: 你现在是在描述现象，还是在定位根因？
+- **证据提醒**: 当前判断基于事实、观察结果，还是基于猜测与假设？
+- **边界提醒**: 当前问题影响的是局部模块、单系统，还是跨系统结构？
+- **复杂度提醒**: 你是在消除本质复杂度，还是在增加偶然复杂度？
+- **收敛提醒**: 当前是否已经足够形成结论，还是仍在无效发散？
+
+## Tips
+
+- 不要再手写 thought JSON；让 CLI runtime 负责节奏、落盘与 replay
+- 不要把 sequential-thinking 当成默认模式，只在真正需要多步收敛时调用
+- 如果不确定模式，先用 `explore`
+- `step` 的 `content` 只表达当前推进内容，不要重复补全系统上下文
+- 如果发现前提错了，就明确修正，不要硬撑
+- 到收敛阶段时，应明确输出结论、风险和下一步动作
+- 只有已完成会话才能执行 `replay`

package/templates/.agents/skills/spec-writer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: spec-writer
-description: 将模糊或高层需求转化为严格的产品需求文档（PRD）。适用于需求含糊、范围过大或表达停留在概念层的场景。
+description: 【ALPHA】genesis Step 2：将模糊或高层需求转化为严格的产品需求文档（PRD）；含 craft 脚手架、PRD spec 契约、可选子代理分片编排与 Step 完成信号。适用于需求含糊、范围过大或表达停留在概念层的场景。
 ---
 
 # 需求侦探手册
@@ -9,35 +9,80 @@ description: 将模糊或高层需求转化为严格的产品需求文档（PRD
 
 你的任务是**消灭歧义**。
 
-## 快速开始
-
-1.  **阅读需求（强制）**：阅读用户请求与上下文，识别其中的“感觉词”（如“快”“现代”“简单”）。
-2.  **深度思考（关键）**：你**必须**进行 3-7 轮结构化推理（视复杂度而定），完成以下工作：
-    *   提取 User Story（As a X, I want Y, so that Z）
-    *   识别歧义点
-    *   起草澄清问题
-3.  **追问澄清**：向用户提出问题。**未获得答案前不得继续**。
-4.  **起草 PRD（强制）**：读取 `references/prd_template.md`，然后创建 `.anws/v{N}/01_PRD.md`。
-5.  **歧义扫描（强制）**：起草完成后，执行下文的“10 维歧义扫描”。对发现的问题就地修正，或标记为 `[ASSUMPTION]`。
-6.  **User Story 质量闸门（强制）**：验证每条 User Story 都通过下文质量检查表。
-
-## 强制步骤
-在创建 PRD 之前，你**必须**：
-1. 提取至少 3 条清晰的 User Story。
-2. 定义至少 3 条 Non-Goal（明确**不做什么**）。
-3. 向用户澄清“感觉词”（例如：“快”具体意味着什么？“现代”指什么？）。
-4. 创建输出文件，**不要只在聊天里打印内容**。
-
-在创建 PRD 之后，你**必须**：
-5. 执行“10 维歧义扫描”，修复或标记所有 `Partial` / `Missing` 项。
-6. 验证每条 User Story 都具备：优先级 / 独立可测 / 涉及系统 / 边界情况。
-7. 确保 `[NEEDS CLARIFICATION]` 标签数量 ≤ 3（硬限制）。若超出，则采用合理默认值并加 `[ASSUMPTION]` 标签。
-
-## 完成检查清单
-- [ ] PRD 文件已创建：`.anws/v{N}/01_PRD.md`
-- [ ] 包含 User Stories、验收标准、Non-Goals
-- [ ] 每条需求都可测试、可度量
-- [ ] 用户已确认 PRD
+## 【ALPHA】genesis Step 2（范围与衔接）
+
+本模板相对 `templates/.agents/skills/spec-writer` 增加 **ALPHA** 侧的 **craft 脚手架**、**spec 契约**（落盘语义）、**子代理编排**与 **completion**；下列「执行清单 / 方法论 / 10 维歧义扫描表 / User Story 质量闸门表」的**规范性效力不变**——追问苏格拉底行为、一次性一个问题、`[NEEDS CLARIFICATION]` 硬上限、Non-Goals 与 User Story 闸门等规则** verbatim 适用**。
+
+### craft scaffolding（产物脚手架）
+
+在**执行清单**第 4 步（落盘 `01_PRD.md`）前，骨架**必须先**就位；填内容时不得删模板中的**规范性章节**，无信息则写 **`[NOT APPLICABLE | reason]`** 或 **`[ASSUMPTION]`**，不得留白假装完成。
+
+| 工件 | 路径 | 必须满足 |
+|------|------|----------|
+| 版本目录 | `.anws/v{N}/` | `v{N}` 与宿主 genesis / 会话约定一致；首轮创建或显式沿用既有 `v{N}`，禁止 silent fork。 |
+| PRD | `.anws/v{N}/01_PRD.md` | **唯一权威** Step 2 产出；内容由 `references/prd_template.md` 驱动；**禁止**仅以聊天长篇代替落盘。 |
+| 模板 | `references/prd_template.md` | 起草 PRD **前**全文读取；标题层级与必选段落以模板为准，额外附录允许但不可替代模板必选节。 |
+
+**就绪检查（内部，可向用户简述）**：已选 `v{N}`；已读本 SKILL + `prd_template.md`；已枚举至少 3 条 User Story 草稿与 ≥3 Non-Goals 再进入落盘段落扩展。
+
+### spec 契约（PRD 落盘语义）
+
+> [!IMPORTANT]
+> PRD 段落在合并进 genesis 链路时视作**可对下游断言的契约草稿**（架构、任务分解、challenge），须同时满足：
+>
+> - **可验证**：凡写入「必须 / 禁止 / SLA / 用户数 / 兼容性」类陈述，须有 Given-When-Then、指标或枚举；否则不得标为已实现需求，只可 `[ASSUMPTION]` 或删至 Non-Goals。  
+> - **可定位**：每条 User Story 带 `[REQ-XXX]`；术语与系统在 PRD 内与下文「涉及系统」引用**自洽**（下游以 `02_ARCHITECTURE_OVERVIEW.md` 对齐时不得无故改名）。  
+> - **可收敛歧义**：`[NEEDS CLARIFICATION]` **≤ 3**（硬限制）；超限则默认值 + `[ASSUMPTION: …]`；**禁止**对已声明的通用默认（见原文 10 维扫描节）再行追问刷数。  
+> - **可追溯价值**：每条需求能一句话对齐用户价值；Non-Goals 与 Goals **互斥且无空洞**「也许不做」。  
+> - **一致性**：同一事实在摘要与详情中**不二次矛盾表述**；修正采用**原子段落替换**，不留互相打架的并排说法。
+
+Challenge / 下游专用对齐：若在报告或附件中摘录 PRD 结论，摘录须带 **小节锚点** 或 **`01_PRD.md`  Stable 标题**，禁止只写「见 PRD」。
+
+### 子代理编排（可选）
+
+当宿主支持并行子会话时：
+
+| 角色 | 职责 |
+|------|------|
+| **父代理** | 选定 `v{N}`、加载用户意图与上下文、合并本子代理返回的结构化块、**去重与同主题择优**、对 `.anws/v{N}/01_PRD.md` 保持 **单写者**、跑完强制「10 维歧义扫描」与 User Story 质量闸门并最终交付用户确认。 |
+| **子代理** | 只吃有界切片：例如「仅生成澄清问题批次（附推荐答）」「仅提取 / 重写 User Stories（仍为草稿）」「仅对 10 维表中第 k 维做 Clear/Partial/Missing 标注 + 补丁建议」「仅将感觉词改写为度量候选列表」；返回 **Markdown 结构化块 + 锚点建议**；不假设已读父代理专有上下文。 |
+
+**单写者**：任一 `01_PRD.md` 在同一轮 genesis Step 2 **仅一个** writer；子代理不得在父未授权下直接写该路径。
+
+#### 交接清单（子 → 父）
+
+- [ ] 声明交付物类型（问题列表 / Story 草稿 / 扫描向量 / 感觉词度量表）及 **不适用** 的维度（附一行原因）。
+- [ ] 所有条目可映射到 PRD 将使用的 **小节标题或 `[REQ-XXX]` 占位**，无锚点则标「待父挂载」。
+- [ ] 不引入与父已声明 Non-Goals 冲突的新需求；若冲突可能，单列「须父裁定」。
+- [ ] 子代理停于结构化块移交；后续编辑由父合并入库。
+
+### completion（genesis Step 2 完成信号）
+
+Step 2 **不得宣称完成**，除非同时满足：
+
+| 门禁 | 条件 |
+|------|------|
+| 落盘 | `.anws/v{N}/01_PRD.md` 存在且可被独立打开；结构与 `prd_template.md` **必选节**对齐。 |
+| 内容 | 含 User Stories（过质量闸门）、验收标准、**≥3** Non-Goals；每条需求可测试、可度量或可显式假定。 |
+| 歧义 | 「10 维歧义扫描」已执行完毕；所有 `Partial` / `Missing` 已修复、`[ASSUMPTION]` 化或在硬限制规则下收口。 |
+| 标签 | `[NEEDS CLARIFICATION]` **≤ 3**；Story 均无未量化感觉词或通过改写 / 假定关闭。 |
+| 人 | **用户已对 PRD 确认**（或明确书面弃权并记录为 `[ASSUMPTION: stakeholder sign-off deferred]`）；不得伪称已确认。 |
+| Handoff | 父代理已向用户交付**短摘要表**（目标 / 关键 REQ 数 / 开放澄清数 / Non-Goals 数 / 下一 Step 推荐阅读顺序）。 |
+
+未达到上表任一 **硬** 行 → Step 2 状态为 **blocked / in_progress**，不得在链路中静默进入架构起草。
+
+---
+
+## 执行清单（唯一权威顺序）
+
+与上文 **「craft scaffolding」**、**「completion（genesis Step 2 完成信号）」** 表对齐；最终放行以 **completion 表硬行**为准，本清单只定义操作顺序（合并原「快速开始 / 强制步骤 / 完成检查」，避免重复阅读）。
+
+1. **阅读需求**：识别「感觉词」与隐含边界（强制）。
+2. **深度思考**：3–7 轮结构化推理（按复杂度）；产出 User Story 草稿、歧义点、澄清问题（强制）。
+3. **追问澄清**：未获答复不得推进主线（强制）。
+4. **落盘前下限**：≥3 User Story、≥3 Non-Goal、澄清感觉词；读取 `references/prd_template.md`，创建 `.anws/v{N}/01_PRD.md`，**禁止**仅以聊天代替落盘（强制）。
+5. **落盘后**：执行下文「10 维歧义扫描」并收口 `Partial` / `Missing`；跑 User Story 质量闸门；`[NEEDS CLARIFICATION]` ≤3（强制）。
+6. **收口**：满足 **completion** 表全部硬行 + 用户确认 PRD（或已记录的弃权假定）。
 
 ## 方法工具