@haaaiawd/anws 2.2.2 → 2.2.3

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

@@ -1,216 +1,225 @@
----
-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: 当复杂问题需要系统性逐步推理时使用。适用于多阶段分析、设计规划、问题分解，或初始范围不明确且需要受控收敛的任务。
+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`
+

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

@@ -9,7 +9,7 @@ description: 将模糊或高层需求转化为严格的产品需求文档（PRD
 
 你的任务是**消灭歧义**。
 
-## ⚡ 快速开始
+## 快速开始
 
 1.  **阅读需求（强制）**：阅读用户请求与上下文，识别其中的“感觉词”（如“快”“现代”“简单”）。
 2.  **深度思考（关键）**：你**必须**进行 3-7 轮结构化推理（视复杂度而定），完成以下工作：
@@ -21,7 +21,7 @@ description: 将模糊或高层需求转化为严格的产品需求文档（PRD
 5.  **歧义扫描（强制）**：起草完成后，执行下文的“10 维歧义扫描”。对发现的问题就地修正，或标记为 `[ASSUMPTION]`。
 6.  **User Story 质量闸门（强制）**：验证每条 User Story 都通过下文质量检查表。
 
-## 🛑 强制步骤
+## 强制步骤
 在创建 PRD 之前，你**必须**：
 1. 提取至少 3 条清晰的 User Story。
 2. 定义至少 3 条 Non-Goal（明确**不做什么**）。
@@ -33,13 +33,13 @@ description: 将模糊或高层需求转化为严格的产品需求文档（PRD
 6. 验证每条 User Story 都具备：优先级 / 独立可测 / 涉及系统 / 边界情况。
 7. 确保 `[NEEDS CLARIFICATION]` 标签数量 ≤ 3（硬限制）。若超出，则采用合理默认值并加 `[ASSUMPTION]` 标签。
 
-## ✅ 完成检查清单
+## 完成检查清单
 - [ ] PRD 文件已创建：`.anws/v{N}/01_PRD.md`
 - [ ] 包含 User Stories、验收标准、Non-Goals
 - [ ] 每条需求都可测试、可度量
 - [ ] 用户已确认 PRD
 
-## 🛠️ 方法工具
+## 方法工具
 
 ### 1. 苏格拉底追问
 *   **用户**：“我希望它很快。”
@@ -55,20 +55,20 @@ description: 将模糊或高层需求转化为严格的产品需求文档（PRD
 *   明确定义我们**不做什么**。
 *   *为什么*：防止范围蔓延，避免后续不断冒出“那 X 呢？”的问题。
 
-## ⚠️ 侦探守则
+## 侦探守则
 
 1.  **契约优先**：如果无法验证，就不要写进 PRD。
 2.  **不抢设计工作**：描述 *做什么*，不要过早写 *怎么做*。实现方式留给架构设计阶段。
 3.  **用户价值优先**：每条需求都必须能追溯到明确的用户价值。
 
-## 🧰 工具箱
+## 工具箱
 *   `references/prd_template.md`：产品需求文档模板。
 
-## 🔍 10 维歧义扫描
+## 10 维歧义扫描
 
 起草 PRD 后，你**必须**从以下 10 个维度系统性扫描全文。这一步是为了用**可重复、可穷尽**的方法替代随意的“还有问题吗？”。
 
-对每个维度，标记状态：`Clear` ✅ / `Partial` ⚠️ / `Missing` ❌
+对每个维度，标记状态：`Clear`  / `Partial`  / `Missing` 
 
 | # | 维度 | 检查内容 | 状态 |
 |---|------|----------|:------:|
@@ -90,7 +90,7 @@ description: 将模糊或高层需求转化为严格的产品需求文档（PRD
 - `[NEEDS CLARIFICATION]` 标签数量**硬限制 ≤ 3**；若仍超出，则采用合理默认值并加 `[ASSUMPTION: ...]`
 - **不要向用户追问这些合理默认值**：行业通用的数据保留策略、标准 Web/移动性能预期、带兜底的友好错误提示、标准 Session 或 OAuth2 认证
 
-## ✅ User Story 质量闸门
+## User Story 质量闸门
 
 PRD 中的每条 User Story，在 PRD 被视为完成前，**都必须**通过以下检查：
 

package/templates/.agents/skills/spec-writer/references/prd_template.md

@@ -11,7 +11,7 @@
 
 ## 1. 执行摘要 (Executive Summary)
 <!-- 上下文压缩：在 50 字以内说明"为什么做"和"做了什么"。 -->
-<!-- ⚠️ CRITICAL: 这是"电梯演讲"，必须控制在 50 字以内。 -->
+<!--  CRITICAL: 这是"电梯演讲"，必须控制在 50 字以内。 -->
 
 [简明扼要地描述要解决的问题以及所提出的解决方案，请聚焦于核心价值。]
 
@@ -39,7 +39,7 @@
 ## 3. 目标与范围 (Goals & Non-Goals)
 
 ### 3.1 目标 (Goals)
-<!-- ⚠️ CRITICAL: 必须使用 SMART 原则 (明确、可衡量、可实现、相关性强、有时限) -->
+<!--  CRITICAL: 必须使用 SMART 原则 (明确、可衡量、可实现、相关性强、有时限) -->
 
 - **[G1]**: [可衡量的业务目标，如: 用户登录转化率提升至 95% 以上]
 - **[G2]**: [可衡量的技术目标，如: 列表页 P95 加载时间 < 1.5s]
@@ -54,9 +54,9 @@
 
 ## 4. 用户故事与需求清单 (User Stories)
 <!-- 格式要求: 作为一个 [角色]，我想要 [动作]，以便于 [价值/收益]。 -->
-<!-- ⚠️ CRITICAL: 每个 User Story 必须有唯一 ID [REQ-XXX]，这是整个系统防腐和追溯的核心。 -->
-<!-- ⚠️ CRITICAL: 必须按用户价值优先级排序 (P0 核心路径 → P1 重要体验 → P2 锦上添花)。 -->
-<!-- ⚠️ CRITICAL: 每个 User Story 必须具备独立可测性——完成后可以脱离其他 Story 独立演示。 -->
+<!--  CRITICAL: 每个 User Story 必须有唯一 ID [REQ-XXX]，这是整个系统防腐和追溯的核心。 -->
+<!--  CRITICAL: 必须按用户价值优先级排序 (P0 核心路径 → P1 重要体验 → P2 锦上添花)。 -->
+<!--  CRITICAL: 每个 User Story 必须具备独立可测性——完成后可以脱离其他 Story 独立演示。 -->
 
 ### US-001: [任务标题] [REQ-001] (优先级: P0)
 
@@ -162,7 +162,7 @@ flowchart TD
 
 ---
 
-<!-- ⚠️ CRITICAL 使用指南 -->
+<!--  CRITICAL 使用指南 -->
 <!-- 
 **PRD 撰写原则 (精益规格要求)**:
 1. **去冗存精**: 抵制长篇大论，整个文档建议控制在阅读时间 10 分钟以内。