@haaaiawd/anws 2.2.1 → 2.2.3

package/templates/.agents/workflows/design-system.md

@@ -30,7 +30,7 @@ description: "为单个系统设计详细的技术文档。适用于架构拆解
 
 ---
 
-## ⚠️ CRITICAL 独立会话与上下文加载
+## CRITICAL 独立会话与上下文加载
 
 > [!IMPORTANT]
 > **为什么需要独立会话？**
@@ -38,13 +38,13 @@ description: "为单个系统设计详细的技术文档。适用于架构拆解
 > 复杂项目有多个系统，建议为每个系统单独设计。
 > 我们使用**文件系统作为外部记忆**：
 > 
-> - ✅ **加载**: 根据需要加载PRD、Architecture Overview、相关ADR
-> - ✅ **灵活**: 可以加载完整文档或摘要，视情况而定
-> - ✅ **使用**: 文件系统作为"外部记忆"，不依赖会话历史
+> - **加载**: 根据需要加载PRD、Architecture Overview、相关ADR
+> - **灵活**: 可以加载完整文档或摘要，视情况而定
+> - **使用**: 文件系统作为"外部记忆"，不依赖会话历史
 
 ---
 
-## ⚠️ CRITICAL 独立会话原则
+## CRITICAL 独立会话原则
 
 > [!IMPORTANT]
 > **每个系统的设计在独立会话中完成**
@@ -271,7 +271,7 @@ description: "为单个系统设计详细的技术文档。适用于架构拆解
 
 ---
 
-## Step 3: 调研 (Research via /explore) ⭐ 用户强调
+## Step 3: 调研 (Research via /explore)  用户强调
 
 **目标**: 了解业界最佳实践，避免闭门造车
 
@@ -375,7 +375,7 @@ description: "为单个系统设计详细的技术文档。适用于架构拆解
 9. "数据库Schema如何设计？（如果需要）"
 10. "数据如何在组件间流动？"
 
-### 4.4 Trade-offs讨论 (⭐ Google风格)
+### 4.4 Trade-offs讨论 ( Google风格)
 11. "为什么选择方案A而不是方案B？（技术选型）"
 12. "这个设计的权衡是什么？优点和缺点？"
 13. "有哪些备选方案？为什么不选它们？"
@@ -443,11 +443,11 @@ description: "为单个系统设计详细的技术文档。适用于架构拆解
 
 | 规则   | 检测项                              | 触发？ |
 | ------ | ----------------------------------- | :----: |
-| **R1** | 任何单个函数/算法伪代码 > 30 行     |  ✅/❌   |
-| **R2** | 所有代码块合计行数 > 200 行         |  ✅/❌   |
-| **R3** | 含配置常量字典且条目 > 5 个         |  ✅/❌   |
-| **R4** | 版本历史注释（`# vX.X 变更`）> 5 处 |  ✅/❌   |
-| **R5** | 预计文档总行数 > 500 行             |  ✅/❌   |
+| **R1** | 任何单个函数/算法伪代码 > 30 行     | 是/否 |
+| **R2** | 所有代码块合计行数 > 200 行         | 是/否 |
+| **R3** | 含配置常量字典且条目 > 5 个         | 是/否 |
+| **R4** | 版本历史注释（`# vX.X 变更`）> 5 处 | 是/否 |
+| **R5** | 预计文档总行数 > 500 行             | 是/否 |
 
 **决策**:
 - 任意触发 → **是**: 创建两个文件（L0 + L1）
@@ -477,7 +477,7 @@ description: "为单个系统设计详细的技术文档。适用于架构拆解
 5. **接口设计 (Interface Design)** — 用**操作契约表格**代替函数伪代码（见 SKILL.md 守则7）
 6. **数据模型 (Data Model)** — 只放**属性字段声明**，不写方法体（见 SKILL.md 守则8）
 7. 技术选型 (Technology Stack)
-8. **Trade-offs & Alternatives** ⭐ 核心
+8. **Trade-offs & Alternatives**  核心
 9. 安全性考虑 (Security Considerations)
 10. 性能考虑 (Performance Considerations)
 11. 测试策略 (Testing Strategy)
@@ -492,7 +492,7 @@ description: "为单个系统设计详细的技术文档。适用于架构拆解
 - §2 完整数据结构（含方法体的 @dataclass）
 - §3 核心算法伪代码（完整函数体，按操作契约表格对应）
 - §4 决策树详细逻辑（对应 L0 Mermaid 图的展开）
-- §5 边缘情况与注意事项（从旧文档 `# ⚠️ 注意` 类注释提取）
+- §5 边缘情况与注意事项（从旧文档 `#  注意` 类注释提取）
 - 版本历史表格（集中放在 L1 末尾）
 
 **关键要求**:
@@ -530,16 +530,16 @@ description: "为单个系统设计详细的技术文档。适用于架构拆解
 
 ---
 
-## Step 6: 审核 (Review via /challenge)
+## Step 6: 审核 (Review via /challenge)
 
 **目标**: 质疑设计决策，识别盲点
 
-> [!IMPORTANT]
-> 当系统设计定义了公共接口、CLI 参数语义、配置结构、文件格式、错误语义或跨系统协议时，**此步骤为必需**。
->
-> **为什么？** 这些契约会直接进入 Blueprint、Change、Forge 和 Challenge 的闭环，缺少审查容易让后续任务和执行漂移。
->
-> 对这类系统，`11.5 Contract Verification Matrix` 也视为必填内容，不得留空。
+> [!IMPORTANT]
+> 当系统设计定义了公共接口、CLI 参数语义、配置结构、文件格式、错误语义或跨系统协议时，**此步骤为必需**。
+>
+> **为什么？** 这些契约会直接进入 Blueprint、Change、Forge 和 Challenge 的闭环，缺少审查容易让后续任务和执行漂移。
+>
+> 对这类系统，`11.5 Contract Verification Matrix` 也视为必填内容，不得留空。
 
 **调用方式**:
 ```
@@ -565,11 +565,11 @@ description: "为单个系统设计详细的技术文档。适用于架构拆解
 
 **展示**:
 ```
-✅ 系统设计文档已生成:
+ 系统设计文档已生成:
   - 文件: .anws/v{N}/04_SYSTEM_DESIGN/{system-id}.md
   - 调研: .anws/v{N}/04_SYSTEM_DESIGN/_research/{system-id}-research.md
 
-📋 文档包含:
+ 文档包含:
   - 14个章节（完整版）或 11个章节（简化版）
   - 架构图 (Mermaid)
   - 接口设计（API/组件）
@@ -604,19 +604,19 @@ description: "为单个系统设计详细的技术文档。适用于架构拆解
 ---
 
 <completion_criteria>
-- ✅ 系统ID已确认
-- ✅ 上下文已加载（PRD + Architecture Overview + 相关ADR）
-- ✅ 系统理解已完成 (`sequential-thinking` 3-5 thoughts)
-- ✅ 调研已完成 (/explore)
-- ✅ 设计已完成 (`sequential-thinking` 5-7 thoughts)
-- ✅ 文档已生成 (使用模板)
-- ✅ 更新了 AGENTS.md AUTO:BEGIN 区块 (系统边界)
-- ✅ 用户已确认
+- 系统ID已确认
+- 上下文已加载（PRD + Architecture Overview + 相关ADR）
+- 系统理解已完成 (`sequential-thinking` 3-5 thoughts)
+- 调研已完成 (/explore)
+- 设计已完成 (`sequential-thinking` 5-7 thoughts)
+- 文档已生成 (使用模板)
+- 更新了 AGENTS.md AUTO:BEGIN 区块 (系统边界)
+- 用户已确认
 </completion_criteria>
 
 ---
 
-## 📚 示例提示词
+## 示例提示词
 
 **为前端系统设计**:
 `/design-system frontend-system`

package/templates/.agents/workflows/explore.md

@@ -1,13 +1,13 @@
 ---
-description: "深度探索复杂问题，产出结构化洞察。适用于技术调研、方案选型、头脑风暴等需要系统性思考的场景。通过向外搜索（收集事实）与向内发散（产生创意）的双向螺旋完成探索。"
----
+
+## description: "深度探索复杂问题，产出结构化洞察。适用于技术调研、方案选型、头脑风暴等需要系统性思考的场景。通过向外搜索（收集事实）与向内发散（产生创意）的双向螺旋完成探索。"
 
 # /explore
 
-<phase_context>
 你是 **EXPLORER (深度探索者)**。
 
 **你的能力**：
+
 - 将复杂问题分解为可探索的子问题
 - **向外探索**：搜索收集外部信息
 - **向内探索**：发散思考内部创意
@@ -21,18 +21,20 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 
 ---
 
-## ⚠️ CRITICAL 触发条件
+## CRITICAL 触发条件
 
 > [!IMPORTANT]
 > **明确何时触发 /explore，避免滥用或漏用。**
 >
 > **触发条件**（满足任一）：
+>
 > - 用户明确说"调研"、"探索"、"技术选型"、"方案对比"、"头脑风暴"
 > - `design-system` Step 3 自动调用（调研业界最佳实践）
 > - `genesis` Step 3 技术选型时（可选）
 > - 用户需要深度了解某个技术领域
 >
 > **不触发**：
+>
 > - 用户直接说"开始设计"、"写代码"、"实现功能"
 > - `quickstart` 流程中不主动推荐
 > - 简单问题（单步即可回答）
@@ -41,39 +43,44 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 
 ---
 
-## ⚠️ CRITICAL 深度思考要求
+## CRITICAL 深度思考要求
 
 > [!IMPORTANT]
 > **探索需要深度思考，思考方式基于模型能力和任务复杂度。**
-> 
+>
 > **核心判断规则**：
+>
 > - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
 > - **有 CoT 模型 + 简单探索**（子问题 < 3）→ 自然 CoT 即可
 > - **有 CoT 模型 + 复杂探索**（需要修正前提、多方案比较）→ 调用 `sequential-thinking` CLI
-> 
+>
 > 探索不是"搜一下 + 想一下"。真正的探索需要：
+>
 > - **分解问题**：找到正确的问题比找到答案更重要
 > - **多向发散**：突破第一反应，探索边界
 > - **交叉验证**：不同来源的信息需要整合
 > - **收敛提炼**：从混乱中提取结构化洞察
-> 
+>
 > **判断口诀**：要修正？要比较？要回放？→ 用 CLI；否则 → 自然 CoT
 
 ---
 
-## ⚠️ 双向探索原则
+## 双向探索原则
 
 > [!IMPORTANT]
 > **何时向外（搜索）？何时向内（发散）？**
-> 
-> | 问题类型 | 偏向 | 示例 |
-> |---------|------|------|
+>
+>
+> | 问题类型        | 偏向     | 示例              |
+> | ----------- | ------ | --------------- |
 > | "X 是什么/怎么做" | 向外（搜索） | "Rust async 原理" |
-> | "如何创新/解决方案" | 向内（发散） | "提高开发效率的方法" |
-> | 复杂问题 | 两者交织 | "设计一个新的代码审查工具" |
-> 
+> | "如何创新/解决方案" | 向内（发散） | "提高开发效率的方法"     |
+> | 复杂问题        | 两者交织   | "设计一个新的代码审查工具"  |
+>
+>
 > 大多数问题需要两者结合：**先搜索了解现状，再发散探索可能**
-</phase_context>
+>
+>
 
 ---
 
@@ -83,16 +90,19 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 
 > [!IMPORTANT]
 > **思考方式选择**（基于模型能力和任务复杂度）：
+>
 > - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
 > - **有 CoT 模型 + 简单问题**（子问题 < 3）→ 用思考引导问题组织自然 CoT
 > - **有 CoT 模型 + 复杂问题**（需要修正前提、多方案比较）→ 调用 `sequential-thinking` CLI
 >
 > **为什么需要深度思考？** 问题分解的质量决定了整个探索的方向。错误的分解会导致：
+>
 > - 搜索了不相关的信息
 > - 发散了错误的方向
 > - 浪费时间在无效探索上
 
 **思考引导**:
+
 1. "用户真正想知道/解决什么？表面问题 vs 深层需求"
 2. "这个问题可以拆成哪些子问题？"
 3. "哪些子问题需要搜索事实？哪些需要发散创意？"
@@ -109,10 +119,10 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 **子问题清单**:
 | 子问题 | 探索方向 | 预期产出 |
 |--------|:-------:|---------|
-| 现状是什么？ | 🔍 向外 | 事实信息 |
-| 为什么会这样？ | 🔍🧠 混合 | 原因分析 |
-| 可以怎么解决？ | 🧠 向内 | 创意选项 |
-| 哪个方案最好？ | 🔍🧠 混合 | 评估结论 |
+| 现状是什么？ |  向外 | 事实信息 |
+| 为什么会这样？ |  混合 | 原因分析 |
+| 可以怎么解决？ |  向内 | 创意选项 |
+| 哪个方案最好？ |  混合 | 评估结论 |
 ```
 
 ---
@@ -123,15 +133,17 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 
 **探索进度表** (每完成一个子问题更新):
 
-| 子问题 | 状态 | 核心发现 (1-2句) |
-|--------|:----:|------------------|
-| [子问题1] | ⏳ 探索中 | - |
-| [子问题2] | ⬜ 待探索 | - |
-| ... | | |
 
-> 每完成一个子问题，更新状态为 ✅ 并填写核心发现。这是你的"记忆锚点"。
+| 子问题    | 状态    | 核心发现 (1-2句) |
+| ------ | ----- | ----------- |
+| [子问题1] |  探索中 | -           |
+| [子问题2] |  待探索 | -           |
+| ...    |       |             |
+
 
-### 2.1 向外搜索 (Outward Search) 🔍
+> 每完成一个子问题，更新状态为  并填写核心发现。这是你的"记忆锚点"。
+
+### 2.1 向外搜索 (Outward Search) 
 
 用于：收集事实、了解现状、验证假设
 
@@ -139,58 +151,68 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 
 > [!IMPORTANT]
 > **可选 Skill 可用性检测**:
+>
 > - `find-skills` 是**可选增强**，不是默认依赖
 > - 如果当前环境支持 `find-skills`，可将其作为方法论与能力发现的额外来源
 > - 如果当前环境**不支持** `find-skills`，直接继续使用 `search_web`、`read_url_content` 等标准搜索路径
 > - **不得因 `find-skills` 不可用而中断 workflow**
 
 **搜索技巧**:
-| 目标 | 技巧 | 示例 |
-|------|------|------|
-| 学术/深度 | `paper`, `research`, `arxiv` | "LLM agent paper" |
-| 最新动态 | `2025`, `latest`, `trends` | "React 19 latest 2025" |
-| 官方权威 | `site:` 指定域名 | "site:pytorch.org" |
-| 对比分析 | `vs`, `comparison`, `benchmark` | "Rust vs Go benchmark" |
-| 实战经验 | `best practices`, `production` | "K8s production best practices" |
-| 问题解决 | `how to`, `fix`, `solution` | "Python asyncio memory leak fix" |
-| **find-skills** | `find-skills` | "find-skills Rust async" |
+
+
+| 目标              | 技巧                              | 示例                               |
+| --------------- | ------------------------------- | -------------------------------- |
+| 学术/深度           | `paper`, `research`, `arxiv`    | "LLM agent paper"                |
+| 最新动态            | `2025`, `latest`, `trends`      | "React 19 latest 2025"           |
+| 官方权威            | `site:` 指定域名                    | "site:pytorch.org"               |
+| 对比分析            | `vs`, `comparison`, `benchmark` | "Rust vs Go benchmark"           |
+| 实战经验            | `best practices`, `production`  | "K8s production best practices"  |
+| 问题解决            | `how to`, `fix`, `solution`     | "Python asyncio memory leak fix" |
+| **find-skills** | `find-skills`                   | "find-skills Rust async"         |
+
 
 > [!IMPORTANT]
-> **`find-skills` 是可选探索源，不是默认必用步骤。**
+> `**find-skills` 是可选探索源，不是默认必用步骤。**
 >
 > 当问题需要吸收成熟方法论、检查框架、设计启发或测试策略时，可以额外调用 `find-skills`。
 > 适用场景包括：
+>
 > - 想了解某类专业能力是否已有现成 skill 可复用
 > - 希望借鉴 UI/UX、架构评审、测试、性能优化等领域的成熟框架
 > - 需要把外部 skill 中的结构化经验转译进 ADR、SYSTEM_DESIGN、TASKS 或 Workflow
 
 **Skill Harvesting 原则**:
-1.  **先发现**: 用 `find-skills` 查找相关能力或方法源
-2.  **再提炼**: 提取有价值的检查维度、输出结构、启发式原则、验收方式
-3.  **后转译**: 将这些内容写入当前探索报告与后续文档，而不是整段搬运 skill 本体
-4.  **保持可选**: 如果普通搜索和内部推理已足够，不必强行调用 `find-skills`
+
+1. **先发现**: 用 `find-skills` 查找相关能力或方法源
+2. **再提炼**: 提取有价值的检查维度、输出结构、启发式原则、验收方式
+3. **后转译**: 将这些内容写入当前探索报告与后续文档，而不是整段搬运 skill 本体
+4. **保持可选**: 如果普通搜索和内部推理已足够，不必强行调用 `find-skills`
 
 **备用搜索路径**（当 `find-skills` 不可用时）:
-1.  使用 `search_web` 搜索方法论关键词、最佳实践、对标对象和测试策略关键词
-2.  使用 `read_url_content` 读取高质量文档、官方文档或代表性深度文章
-3.  在最终报告中标注：本次结论来自 Web / 文档搜索，**未使用 skill harvesting 增强**
 
-### 2.2 向内发散 (Inward Divergence) 🧠
+1. 使用 `search_web` 搜索方法论关键词、最佳实践、对标对象和测试策略关键词
+2. 使用 `read_url_content` 读取高质量文档、官方文档或代表性深度文章
+3. 在最终报告中标注：本次结论来自 Web / 文档搜索，**未使用 skill harvesting 增强**
+
+### 2.2 向内发散 (Inward Divergence) 
 
 用于：产生创意、探索可能性、突破常规
 
 > [!IMPORTANT]
 > **思考方式选择**（基于模型能力和任务复杂度）：
+>
 > - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
 > - **有 CoT 模型 + 简单发散**（技巧 < 3）→ 用发散技巧组织自然 CoT
 > - **有 CoT 模型 + 复杂发散**（需要多方案比较、修正前提）→ 调用 `sequential-thinking` CLI
 >
 > **为什么需要深度发散？** 第一个想法通常是最普通的。突破需要：
+>
 > - 强迫自己继续想
 > - 尝试不同角度
 > - 连接不相关的概念
 
 **发散技巧**:
+
 1. **SCAMPER**: 替代、组合、调整、修改、其他用途、消除、重排
 2. **逆向思维**: "如果完全相反会怎样？"
 3. **类比迁移**: "其他领域怎么解决类似问题？"
@@ -199,6 +221,7 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 6. **5 Whys**: 连问5次"为什么"挖掘根因
 
 **思考引导**:
+
 1. "最常规的解决方案是什么？"
 2. "如果反过来做呢？"
 3. "其他行业有类似问题吗？"
@@ -232,9 +255,10 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 
 > [!IMPORTANT]
 > **每个子问题结束时，你必须**：
+>
 > 1. 回答上述3个检查问题
 > 2. 更新"探索进度表"中的状态和核心发现
-> 
+>
 > 这确保你不会"想完就过"，而是留下可追溯的探索轨迹。
 
 ---
@@ -245,16 +269,19 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 
 > [!IMPORTANT]
 > **思考方式选择**（基于模型能力和任务复杂度）：
+>
 > - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
 > - **有 CoT 模型 + 简单综合**（子问题 < 3，无矛盾）→ 用思考引导问题组织自然 CoT
 > - **有 CoT 模型 + 复杂综合**（需要解决矛盾、修正前提）→ 调用 `sequential-thinking` CLI
 >
 > **为什么需要深度收敛？** 原始发现是碎片化的。你需要：
+>
 > - 识别模式和主题
 > - 解决矛盾信息
 > - 提炼核心洞察
 
 **思考引导**:
+
 1. "所有子问题都探索充分了吗？"
 2. "不同来源的信息一致吗？有矛盾吗？"
 3. "能提炼出哪些核心洞察？"
@@ -270,6 +297,7 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 **目标**: 产出结构化的探索报告。
 
 **保存路径**:
+
 - 如果由 `/design-system` 调用: `.anws/v{N}/04_SYSTEM_DESIGN/_research/{system-id}-research.md`
 - 如果独立调用: `explore/reports/{YYYYMMDD}_{topic_slug}.md`
 - 确保对应目录存在
@@ -278,6 +306,7 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 
 > [!NOTE]
 > 如果本次探索使用了 `find-skills`，请在报告中明确区分：
+>
 > - 哪些结论来自 Web / 文档搜索
 > - 哪些结论来自 skill harvesting
 > - 哪些内容被建议沉淀到 ADR、SYSTEM_DESIGN、TASKS 或 Workflow
@@ -316,7 +345,7 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 
 ### 3.1 [子问题1]
 
-**探索方式**: 🔍 搜索 / 🧠 发散 / 🔍🧠 混合
+**探索方式**:  搜索 /  发散 /  混合
 
 **发现**:
 - ...
@@ -332,7 +361,7 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 
 | 方案 | 创新性 | 可行性 | 影响力 | 推荐度 |
 |------|:------:|:------:|:------:|:------:|
-| ... | ★★★ | ★★★ | ★★★ | ⭐ |
+| ... |  |  |  |  |
 
 ---
 
@@ -368,4 +397,4 @@ description: "深度探索复杂问题，产出结构化洞察。适用于技术
 - "探索如何让代码审查更高效有趣"
 - "探索 Rust 和 Go 在系统编程中的优缺点"
 - "探索解决远程团队协作问题的方案"
-- "探索 AI 辅助编程的最佳实践"
+- "探索 AI 辅助编程的最佳实践"