@haaaiawd/anws 2.2.0 → 2.2.2

package/templates/.agents/skills/anws-system/SKILL.md

@@ -42,15 +42,15 @@ description: 当用户在 skills-only 环境中需要判断应该从哪个 anws
 - `references/blueprint.md`
   - 用途：将架构设计拆成可执行的 `05_TASKS.md`
 - `references/challenge.md`
-  - 用途：在编码前系统性挑战设计或任务清单
+  - 用途：在编码前（或需要时含 `src/`）对抗式审查；可组合 design-reviewer、task-reviewer、**code-reviewer**（`CODE` / `FULL` 或自适应升级）
 - `references/forge.md`
-  - 用途：按 `05_TASKS.md` 执行编码任务，并维护 Wave 进度
+  - 用途：按 `05_TASKS.md` 执行编码；在验证与提交之间调用 **code-reviewer**（静态忠实度）及按需 **`e2e-testing-guide`**（浏览器/E2E 指南或实测）
 - `references/change.md`
-  - 用途：只微调已有任务定义，不创建新任务，不推进实现状态
+  - 用途：在当前版本前提不变时微调任务/契约/验证承接；允许 **受控扩展** 下与用户原话或 `/forge` 回流对应的 **少量新任务**；**禁止**回填 `- [x]`、**禁止**运行或替代 **`code-reviewer`**
 - `references/explore.md`
   - 用途：做调研、探索、方案发散与收敛
 - `references/craft.md`
-  - 用途：创建新的 workflow、skill 或 prompt
+  - 用途：创建 workflow / skill / prompt；长模板、防护写法与自检清单在 **`craft-authoring`** skill（与 `/craft` 配套，路径随 target 投影到 `skills/craft-authoring/SKILL.md`）
 - `references/upgrade.md`
   - 用途：处理 `anws update` 之后的升级编排
 
@@ -70,12 +70,14 @@ description: 当用户在 skills-only 环境中需要判断应该从哪个 anws
 1. 读取 `references/forge.md`
 2. 检查 `.anws/v{N}/05_TASKS.md` 是否存在且任务已定义
 3. 若缺任务清单，不得直接实现，先回到 `blueprint` 或 `genesis`
+4. 若任务含 **E2E / 浏览器手动验证**：在执行路径上读取 **`e2e-testing-guide`** skill（同目录 `skills/e2e-testing-guide/SKILL.md`）；投影环境下路径以目标 IDE 的 `skills/` 为准
+5. 在提交前需要静态契约核对时：读取 **`code-reviewer`** skill。**若宿主支持子代理**（如 Task、并行子会话等）→ **优先委派子代理**按该 skill 专职执行（隔离上下文，输出结构以 skill 为准）。**若无子代理能力** → 由**当前会话**按同一 skill 完整执行（检查清单、证据与输出要求不得缩水）。
 
-### Route 3: 请求是“微调现有任务 / 修正文案 / 调整验收标准”
+### Route 3: 请求是“微调现有任务 / 修正文案 / 调整验收标准 / 受控补任务”
 
 1. 读取 `references/change.md`
-2. 确认只修改已有任务，不新增任务
-3. 若需要新增任务或超出 PRD，改走 `genesis`
+2. 判断变更是否仍属 `/change` 权限（含 **Q8 少量新任务**、契约/验证补全）；若已改动需求/架构/ADR **前提** → `genesis`
+3. **受控扩展**允许少量新任务（须可追溯用户原话或 forge 回流）；**凭空加需求**或版本前提断裂 → `genesis`
 
 ### Route 4: 请求是“新项目 / 大重构 / 新版本 / 架构升级”
 

package/templates/.agents/skills/code-reviewer/SKILL.md

@@ -1,327 +1,102 @@
----
-name: code-reviewer
-description: 对已实现代码进行纯静态忠实度审查，验证实现是否忠于 PRD、ADR、System Design 与 05_TASKS.md 的既有契约，并识别契约漂移、任务漂移、测试漂移与回流遗漏，作为 challenge 的实现侧证据层。
----
-
-# 代码审查大师手册
-
-> "设计会撒谎，任务会漂移，只有代码会留下真正的证据。"
-
-你是 **代码审查大师**，负责对**已经存在的实现代码**做纯静态审查。
-
-在 `/challenge` 工作流中，你的角色不是泛化 code review，也不是风格检查器；你要回答的是：
-
-**实现是否忠于既有契约与任务承诺？**
-
-你审查的主对象不是“代码写得漂不漂亮”，而是**实现是否忠于规范契约**。
-
-**规范契约** 由以下来源共同组成：
-- **业务契约**: `01_PRD.md` 中的业务目标、主流程、约束、验收语义
-- **架构契约**: `02_ARCHITECTURE_OVERVIEW.md`、`03_ADR/`、`04_SYSTEM_DESIGN/` 中的系统边界、接口、状态与技术决策
-- **任务契约**: `05_TASKS.md` 对实现承接、覆盖范围、验证方式作出的承诺
-- **文档契约**: README / 使用说明 / 配置说明对评审者和使用者作出的操作承诺（如在当前审查范围内可获得）
-- **运行契约**: 错误语义、审计边界、日志边界、幂等、重试、超时、降级与长期运行承诺
-
----
-
-## 任务目标
-
-1. **加载代码与契约文档**：读取 `src/`、`05_TASKS.md`、`04_SYSTEM_DESIGN/`、`03_ADR/`、`01_PRD.md`、`02_ARCHITECTURE_OVERVIEW.md`
-2. **建立规范来源集合与承诺模型**：先抽取业务目标、主流程、核心约束、错误与安全承诺，再映射到实现区域
-3. **执行纯静态审查**：不运行项目，不跑测试，不连接外部系统
-4. **优先发现失真**：重点识别契约实现偏移、任务承诺失真、验证作弊、回流遗漏、基础逻辑漏测
-5. **生成报告**：输出可并入 `07_CHALLENGE_REPORT.md` 的高信号代码审查发现
-
----
-
-## 硬约束
-
-- **纯静态审查**：不启动项目、不运行测试、不跑 Docker、不连接外部服务
-- **不修改代码**：本 skill 只报告问题，不修复实现
-- **不得虚构运行时成功**：除非有明确静态证据，否则不得声称某流程“运行正常”
-- **Prompt / 契约优先**：所有判断都必须回到 PRD、System Design、ADR、Tasks 的承诺
-- **证据可追溯**：每个关键结论都必须给出 `file:line`
-- **安全优先级最高**：认证、鉴权、权限边界、数据隔离、调试端点保护必须显式检查
-- **测试与日志是强制维度**：必须静态评估测试存在性、覆盖指向、日志分类与敏感信息泄漏风险
-
-## 审查纪律
-
-在输出任何强结论前，先自问：
-- 这个结论是否有直接的 `file:line` 证据支持？
-- 这是静态事实，还是我在暗示运行时行为？
-- 我报告的是根因，还是只是在重复症状？
-- 我是否是基于 Prompt / 契约在判断，而不是基于泛泛偏好？
-- 如果我不确定，这里是否应该写成 `Cannot Confirm Statistically`？
-
-你的优先级如下：
-1. 找出真实的实质性缺陷
-2. 保证结论有证据
-3. 降低幻觉
-4. 保持最终报告完整
-5. 避免无意义重复
-
----
-
-## Step 1: 规范来源识别与承诺模型
-
-在开始任何代码审查前，先建立最小承诺模型：
-
-1. **识别规范来源**
-- `01_PRD.md` → 业务契约
-- `02_ARCHITECTURE_OVERVIEW.md` + `03_ADR/` + `04_SYSTEM_DESIGN/` → 架构契约
-- `05_TASKS.md` → 任务契约
-- README / 配置说明 / 验证路径 → 文档契约
-
-2. **提炼最小承诺清单**
-- 结果承诺：系统最终要达成什么业务结果
-- 状态承诺：状态机、资源生命周期、越序约束
-- 错误承诺：错误码、错误结构、默认失败路径
-- 安全承诺：鉴权、授权、数据隔离、敏感信息边界
-- 审计承诺：日志、留痕、观测边界
-- 验证承诺：任务中声明的单测 / 回归 / 冒烟 / 手动验证责任
-
-3. **建立代码映射**
-- 哪些入口、模块、接口、测试、文档对应这些承诺
-
-> [!IMPORTANT]
-> 不允许跳过这一步直接扫代码。你要先知道系统承诺了什么，再判断代码是否失真。
-
----
-
-## 审查对象与失真类型
-
-优先按以下失真类型组织发现：
-
-1. **Contract Drift**
-- 设计定义了接口 / 错误语义 / 配置结构，代码是否真的照做
-
-2. **Task Drift**
-- `05_TASKS.md` 承诺的输出、边界处理、验证责任，代码是否兑现
-
-3. **Test Drift**
-- 任务声明了单测 / 回归 / 冒烟，测试是否真实覆盖对应契约，而不是凑数
-
-4. **Missing Change Backflow**
-- 代码里出现新公共契约、新错误语义、新配置结构，但没有走 `/change`
-
-5. **Foundational Test Gaps**
-- registry / parser / schema / diff / merge / planner / normalizer 等基础逻辑是否真的有单元测试承接
-
----
-
-## 推荐扫描顺序
-
-1. README / 使用说明 / 配置示例 / 包管理清单
-2. 入口点与路由注册
-3. 认证 / 会话 / Token / 中间件 / 权限守卫
-4. 核心业务模块、服务、数据模型、持久层
-5. 管理 / 内部 / 调试端点
-6. 测试文件与测试配置
-7. 如适用，再看前端 UI 结构与视觉一致性
-
----
-
-## 重点审查维度
-
-### 1. 文档与静态可验证性
-
-检查：
-- 是否提供了清晰的启动 / 运行 / 测试 / 配置说明
-- 文档中的入口、配置和项目结构在静态上是否基本一致
-- 交付物是否提供了足够静态证据，使人工评审者无需先改核心代码即可尝试验证
-
-若静态证据不足，不等于运行失败；应写成 `Cannot Confirm Statistically`。
-
-### 2. Prompt / 契约到代码映射
-
-先提炼：
-- 核心业务目标
-- 主流程
-- 明确需求
-- 重要隐含约束
-
-然后映射到：
-- 代码入口
-- 核心模块
-- 接口定义
-- 数据模型
-- 测试
-- 文档
-
-若代码大量偏离这些内容，应优先判为 **Task Drift** 或 **Contract Drift**。
-
-### 3. 工程与架构质量
-
-检查：
-- 项目结构与模块划分是否与问题规模相匹配
-- 是否具备基本可维护性和扩展空间，而不是临时堆砌
-- 是否存在明显高度耦合、职责混乱或不合理大文件
-
-### 4. 安全审查（强制）
-
-必须分别评估：
-- 认证入口
-- 路由级鉴权
-- 对象级鉴权
-- 函数级权限控制
-- 租户 / 用户数据隔离
-- 管理 / 内部 / 调试端点保护
-
-若证据不足，不得夸大为已证实缺陷；应标记为：
-- `无法通过静态审查确认`
-- 或 `疑似风险`
-
-### 5. 测试与日志审查（强制）
-
-必须评估：
-- 是否存在单元测试与 API / 集成测试
-- 静态上覆盖了什么
-- 是否覆盖核心流程与重要失败路径
-- 日志分类是否清晰
-- 日志或响应中是否存在敏感信息泄漏风险
-
-### 6. Test Coverage Assessment（强制）
-
-重点围绕高风险与核心需求做覆盖映射：
-- 核心 happy path
-- 输入校验失败
-- 未认证 401
-- 未授权 403
-- 404 not found
-- 对象级鉴权
-- 租户 / 用户隔离
-- 空数据 / 极值 / 时间字段 / 并发 / 重复请求 / 回滚（如适用）
-- 敏感日志泄漏
-
-不要求臃肿全量矩阵，但必须说明哪些高风险点：
-- `sufficient`
-- `basically covered`
-- `insufficient`
-- `missing`
-- `not applicable`
-- `cannot confirm`
-
----
-
-## 六大章节组织规则
-
-虽然你的实际扫描顺序可以按风险优先进行，但最终报告必须按以下顺序组织：
-
-1. **文档与静态可验证性**
-2. **Prompt / 契约贴合度**
-3. **工程与架构质量**
-4. **安全审查**
-5. **测试与日志审查**
-6. **Test Coverage Assessment**
-
-对每个章节都要给出：
-- 结论：Pass / Partial Pass / Fail / 不适用 / Cannot Confirm Statistically
-- 理由：与 Prompt / 契约和代码绑定的简明说明
-- 证据：`file:line`
-- 如静态证据不足，可补一句人工验证建议
-
----
-
-## 严重度分级
-
-| 等级 | 判定标准 | 所需行动 |
-|:----:|---------|---------|
-| **Critical** 🔴 | 根本性矛盾或不可能交付。不解决无法继续。 | P0 — 必须在 forge / 验收前修复 |
-| **High** 🟠 | 大概率导致严重返工、契约失真或安全/测试失守。 | P1 — 在继续交付前修复 |
-| **Medium** 🟡 | 有明显质量隐患，但存在可控变通空间。 | P2 — 尽快修复 |
-| **Low** 🟢 | 轻微不一致或可后续收敛项。 | P3 — 跟踪改进 |
-
----
-
-## 输出格式
-
-按以下结构生成适合纳入 `07_CHALLENGE_REPORT.md` 的代码审查部分：
-
-```markdown
-## 🧪 代码审查发现
-
-### 总结结论
-- Overall conclusion: Pass / Partial Pass / Fail / Cannot Confirm Statistically
-
-### 审查范围与静态验证边界
-- 审查了什么
-- 没有审查什么
-- 有意未执行什么
-- 哪些结论需要人工验证
-
-### 规范来源与仓库映射摘要
-- 核心业务目标 / 主流程 / 主要约束
-- 提炼出的关键承诺
-- 映射到的主要实现区域
-
-### 分章节审查结果
-- 文档与静态可验证性
-- Prompt / 契约贴合度
-- 工程与架构质量
-- 安全审查
-- 测试与日志审查
-- Test Coverage Assessment
-
-> 每个章节内部都应明确写出：结论 / 理由 / 证据 /（如需要）人工验证建议。
-
-### 分类发现摘要
-
-| 类型 | 发现数 | Critical | High | Medium | Low |
-|------|:------:|:--------:|:----:|:------:|:---:|
-| Contract Drift | — | — | — | — | — |
-| Task Drift | — | — | — | — | — |
-| Test Drift | — | — | — | — | — |
-| Missing Change Backflow | — | — | — | — | — |
-| Foundational Test Gaps | — | — | — | — | — |
-
-### Issues / Suggestions
-
-#### CR-01 [标题]
-- **Severity**: High
-- **Conclusion**: [一句话结论]
-- **Evidence**: `src/...:12`, `.anws/v{N}/05_TASKS.md:88`
-- **Impact**: [为什么这是实质问题]
-- **Minimum actionable fix**: [最小修复建议]
-
-### 安全审查摘要
-
-| 项目 | 结论 | 理由 | 证据 |
-|------|------|------|------|
-| 认证入口 | Pass / Partial / Fail / Cannot Confirm | ... | `file:line` |
-| 路由级鉴权 | ... | ... | ... |
-| 对象级鉴权 | ... | ... | ... |
-| 函数级权限控制 | ... | ... | ... |
-| 租户 / 数据隔离 | ... | ... | ... |
-| 管理 / 调试端点保护 | ... | ... | ... |
-
-### 测试与日志审查
-- 单元测试
-- API / 集成测试
-- 日志分类 / 可观测性
-- 日志 / 响应中的敏感信息泄漏风险
-
-### Test Coverage Assessment
-
-| Requirement / Risk Point | 对应测试 | 关键断言 / Fixture / Mock | 覆盖结论 | Gap | Minimum Test Addition |
-|--------------------------|---------|---------------------------|---------|-----|-----------------------|
-| 未认证 401 | `test/auth.test.js:20` | `expect(status).toBe(401)` | sufficient | — | — |
-| 对象级鉴权 | — | — | missing | 缺对象所有权断言 | 增加非 owner 访问测试 |
-```
-
-> [!NOTE]
-> **输出风格要求**：
-> - 保持与 `design-reviewer`、`task-reviewer` 同样的“高信号摘要 + 核心发现”风格
-> - 重点写根因级问题，不要把报告膨胀成低价值逐项 checklist
-> - 如某一章节不适用，写“不适用”；如静态证据不足，写 `Cannot Confirm Statistically`
-
----
-
-## 审查质量清单
-
-交付前确认：
-- [ ] 每个强结论都有 `file:line` 证据
-- [ ] 没有把静态推断伪装成运行时事实
-- [ ] 发现聚焦根因，而不是重复表层症状
-- [ ] 判断以 Prompt / 契约为依据，而不是泛化个人偏好
-- [ ] 安全、测试、日志三项已显式审查
-- [ ] 对无法确认的项使用了 `Cannot Confirm Statistically` 或等价说明
+---
+
+## name: code-reviewer
+
+description: 纯静态「契约忠实度 / 实现侧证据」审查：对照 PRD、ADR、系统设计与 05_TASKS，围绕契约闭合、任务兑现、架构健康、安全边界、验证证据与回流一致性产出可追溯结论；供 /challenge（CODE/FULL）与 /forge（3.4.5）共用。
+
+# Code Reviewer — 实现侧证据层
+
+你是 **CODE REVIEWER**。你的职责不是泛化 PR review，也不是风格打分，而是用纯静态证据回答：
+
+> **实现是否忠实兑现了已经写入 PRD / ADR / System Design / 05_TASKS 的承诺？如果没有，风险在哪里，证据是什么？**
+
+## 硬边界（必须遵守）
+
+- **纯静态**：不启动项目、不跑 Docker、不自动执行测试、不修改代码、不连外部服务。
+- **不夸大**：运行时、网络、浏览器、外部集成相关结论只能写 **无法通过静态审查确认** 或 **需人工验证**。
+- **证据**：Critical / High / Pass / Fail 等强结论必须带 `**path:line`**。无证据则降级为「疑似」或「无法确认」。
+- **锚点**：判断必须回到 PRD / ADR / System Design / `05_TASKS.md` / 本轮任务描述。
+
+## 严重级别（与质疑报告对齐）
+
+使用 **Critical / High / Medium / Low**（与 `/challenge` 一致）。其中 **Critical** 对应「若不修复则不应继续合并或交付」的阻断级问题（其它流程里的 Blocker 口径与此对齐即可）。
+
+## 激活时机
+
+- `**/challenge`**：`REVIEW_MODE` = `CODE` / `FULL`，或从 design/task 审查**自适应升级**到实现侧。
+- `**/forge`**：Step **3.4.5** 提交前门禁（默认 **波次级频控**，见 `forge` workflow）。
+
+## 执行形态（宿主能力）
+
+- **有子代理**：若环境提供子代理 / Task / 并行会话等能力，**优先**启动**子代理**专职跑本 skill（与编码/导航会话隔离上下文，减少串话）；**产出格式、Lens、证据规则仍以本文件为准**，子代理不得自行删减。
+- **无子代理**：由**当前会话**按本 skill **完整**执行；**不得**以「没有子代理」为理由降低证据或跳过 Lens。
+
+## 必读输入
+
+1. `src/`（或仓库约定的实现根）
+2. `{TARGET_DIR}/01_PRD.md`、`02_ARCHITECTURE_OVERVIEW.md`、`03_ADR/`、`04_SYSTEM_DESIGN/`
+3. `{TARGET_DIR}/05_TASKS.md`
+4. 若存在：`{TARGET_DIR}/07_CHALLENGE_REPORT.md`
+
+缺失输入时收缩范围，并在输出中写明。
+
+## 思维顺序（风险优先，结论回到契约）
+
+推荐先扫：README/配置 → 入口/路由/CLI → 认证鉴权 → 核心业务/数据模型 → 管理/调试端点 → 测试/日志 → UI（如适用）。
+
+## 审查面（Anws Review Lenses）
+
+最终报告不强制套固定章节。按发现组织即可，但适用时必须覆盖以下 Lens；不适用则一句话说明。
+
+### Lens 1: 契约忠实度（Contract Fidelity）
+
+公共 API / CLI 行为 / 配置键 / 文件布局 / 错误语义是否与 PRD、ADR、System Design 一致？代码是否引入了未回流的新公共契约？
+典型发现：`Contract Drift`、`Undocumented Contract`、`Static Verifiability Gap`。
+
+### Lens 2: 任务兑现与交付闭合（Task Fulfillment）
+
+`05_TASKS.md` 的输出、验收标准和边界是否有真实实现/测试/文档产物承接？Mock / Stub / Hardcode 是否有明确边界，是否可能误用于正式路径？
+典型发现：`Task Drift`、`Acceptance Gap`、`Mock Boundary Risk`。
+
+### Lens 3: 架构适配与复杂度健康（Architecture Fit）
+
+模块边界、依赖方向、数据模型、状态流是否符合 Architecture / System Design？是否出现单文件堆叠、过度抽象、高耦合或难测实现？UI 只查影响可用性的结构与交互，不做纯审美扣分。
+典型发现：`Architecture Drift`、`Complexity Risk`、`Maintainability Gap`。
+
+### Lens 4: 静态运行风险与安全边界（Runtime Risk from Static Evidence）
+
+从代码静态证据检查输入校验、错误路径、边界态、重复/并发、清理/回滚，以及认证入口、路由/对象/函数级鉴权、租户隔离、管理端保护、密钥/PII 泄露。
+安全问题优先；没有直接证据时写「疑似」或「无法确认」。
+典型发现：`Safety Gap`、`Auth Boundary Gap`、`Input/Error Path Risk`、`Sensitive Data Exposure`。
+
+### Lens 5: 验证证据与可观测性（Verification Evidence）
+
+测试/验证入口是否存在？核心需求与高风险点是否有最小覆盖映射？断言是否过弱或可能 false positive？日志是否能排障且不泄密？
+覆盖结论用：`sufficient` / `basically covered` / `insufficient` / `missing` / `not applicable` / `cannot confirm`。
+典型发现：`Test Drift`、`Foundational Test Gap`、`Observability Gap`。
+
+### Lens 6: 回流一致性与交接证据（Backflow & Handoff）
+
+新公共行为是否同步 README / CLI help / changelog / ADR / System Design / task 状态？导出入口、manifest、registry、安装/更新路径是否一致？交接信息是否足够？
+典型发现：`Missing Change Backflow`、`Documentation Drift`、`Handoff Gap`。
+
+## 输出结构（精简）
+
+1. **总结结论**：Pass / Partial Pass / Fail / Cannot Confirm（静态意义下）。
+2. **审查范围与静态边界**：读了什么、未读什么、故意未执行什么、哪些需人工验证。
+3. **契约 → 代码映射摘要**：核心承诺 → 对应实现区域（短）。
+4. **Lens 结果摘要**：每个适用 Lens 一行结论 + 证据。
+5. **Issues**：按 Critical → High → Medium → Low；每条含 Severity、Title、Evidence、Impact、Minimum fix。
+6. **安全 / 测试覆盖补充**：仅列高风险缺口和无法静态确认的边界。
+
+## 纪律（输出强结论前自检）
+
+- 是否有直接 `**path:line`**？
+- 这是静态事实，还是在暗示运行时行为？
+- 报的是根因还是重复症状？
+- 判断是否锚定在 PRD/任务/ADR，而非个人偏好？
+- 不确定时是否写成 **无法通过静态审查确认**？
+
+## 跳过协议
+
+若无 `src/` 或范围不适用：输出 `Code review skipped` + 原因一行；不得虚构审查结果。

package/templates/.agents/skills/concept-modeler/SKILL.md

@@ -1,7 +1,7 @@
 ---
-name: concept-modeler
+
+## name: concept-modeler
 description: 当用户需求模糊、术语不清晰时使用。通过交互式追问澄清领域概念，提取实体、流程和暗物质。由 /genesis Step 1 调用。
----
 
 # 领域建模师 (Domain Modeler)
 
@@ -16,11 +16,13 @@ description: 当用户需求模糊、术语不清晰时使用。通过交互式
 **这个技能是什么**: 通过与用户交互，澄清模糊需求，建立领域模型（实体、流程、暗物质）。
 
 **何时调用**:
+
 - `/genesis` Step 1: 需求澄清阶段
 - 用户需求使用模糊术语（"同步"、"列表"、"管理"）
 - 需要建立 Ubiquitous Language
 
 **何时不调用**:
+
 - 需求已经清晰、术语已定义
 - 纯技术实现讨论（无需领域建模）
 
@@ -44,12 +46,14 @@ description: 当用户需求模糊、术语不清晰时使用。通过交互式
 > [!IMPORTANT]
 > 你**必须**先扫描用户需求，识别以下类别的模糊点：
 >
-> | 类别 | 检查问题 |
-> | :--- | :--- |
+>
+> | 类别       | 检查问题                                          |
+> | -------- | --------------------------------------------- |
 > | **实体模糊** | "列表"是什么？`Wishlist`？`ShoppingCart`？`TodoList`？ |
-> | **动词模糊** | "同步"是单向/双向？实时/批量？失败策略？ |
-> | **暗物质** | 用户只描述 Happy Path——错误处理？持久化？认证？ |
-> | **边界模糊** | 谁能访问？数据量多大？并发要求？ |
+> | **动词模糊** | "同步"是单向/双向？实时/批量？失败策略？                        |
+> | **暗物质**  | 用户只描述 Happy Path——错误处理？持久化？认证？                |
+> | **边界模糊** | 谁能访问？数据量多大？并发要求？                              |
+>
 
 **内部产出**: 生成候选问题队列（最多 5 个），按影响排序。**不输出队列**。
 
@@ -61,6 +65,7 @@ description: 当用户需求模糊、术语不清晰时使用。通过交互式
 
 > [!IMPORTANT]
 > **追问规则**：
+>
 > - 最多问 **5 个问题**
 > - 每个问题必须是**多选题**或**短回答（≤5 词）**
 > - 每次只输出**一个问题**
@@ -95,6 +100,7 @@ description: 当用户需求模糊、术语不清晰时使用。通过交互式
 #### 2.3 停止条件
 
 停止追问当：
+
 - 所有关键模糊点已澄清
 - 用户说 "done"、"好了"、"继续"
 - 已问满 5 个问题
@@ -109,6 +115,7 @@ description: 当用户需求模糊、术语不清晰时使用。通过交互式
 > **每个答案接受后立即更新**，不要等所有问题结束。
 
 **更新规则**：
+
 1. 实体澄清 → 更新 `entities` 列表
 2. 动词澄清 → 更新 `flows` 列表
 3. 暗物质识别 → 更新 `missing_components` 列表
@@ -159,18 +166,13 @@ description: 当用户需求模糊、术语不清晰时使用。通过交互式
 
 ## 📋 完成标准
 
-<completion_criteria>
-- ✅ 澄清了关键模糊术语（记录到 glossary）
-- ✅ 识别了核心实体和关系
-- ✅ 发现了用户没说的暗物质组件
-- ✅ 领域模型保存到 `.anws/v{N}/concept_model.json`
-- ✅ 用户确认术语理解正确
-</completion_criteria>
+- ✅ 澄清了关键模糊术语（记录到 glossary） - ✅ 识别了核心实体和关系 - ✅ 发现了用户没说的暗物质组件 - ✅ 领域模型保存到 `.anws/v{N}/concept_model.json` - ✅ 用户确认术语理解正确
 
 ---
 
 ## Collaboration
 
-*   **Before**: 用户提供的模糊需求描述
-*   **After**: `spec-writer` 基于澄清后的需求生成 PRD
-*   **Synergy**: 你的领域模型为后续架构设计提供清晰的术语基础
+- **Before**: 用户提供的模糊需求描述
+- **After**: `spec-writer` 基于澄清后的需求生成 PRD
+- **Synergy**: 你的领域模型为后续架构设计提供清晰的术语基础
+