@haaaiawd/anws 1.2.5 → 2.0.0

package/templates/.agents/skills/task-planner/references/TASK_TEMPLATE.md

@@ -0,0 +1,144 @@
+# 任务拆解模板
+
+**项目**: [项目名称]  
+**蓝图阶段**: 已批准  
+**RFC 参考**: `.anws/v{N}/02_ARCHITECTURE_OVERVIEW.md`
+
+---
+
+## 📋 任务清单
+
+### 图例说明
+- **ID**: 唯一任务标识符（T001, T002...）
+- **[P]**: 可并行（可独立执行）
+- **[验证]**: 检查点任务（人工 / E2E 验证）
+- **用户故事**: 映射到 PRD（US01, US02...）
+- **验收成立**: 验收成立条件
+
+---
+
+### 阶段 1：基础阶段
+
+#### T001 - 数据库 Schema 初始化
+- **用户故事**: US01
+- **描述**: 创建 `users` 表，包含 `id`、`email`、`password_hash`、`created_at` 字段。
+- **依赖**: 无
+- **验收成立**: `psql -c "\d users"` 显示正确的表结构。
+  
+#### T002 - [P] 环境配置
+- **用户故事**: US01
+- **描述**: 添加包含 `DATABASE_URL`、`JWT_SECRET` 的 `.env` 文件。
+- **依赖**: 无
+- **验收成立**: `docker-compose up` 可以无报错启动数据库。
+
+
+---
+
+### 阶段 2：核心逻辑
+
+#### T003 - 用户注册接口
+- **用户故事**: US01
+- **描述**: 实现 `POST /api/register`，对密码做哈希并保存用户。
+- **依赖**: T001（数据库 Schema）
+- **验收成立**: `curl -X POST /api
+
+#### T004 - [P] JWT Token 生成
+- **用户故事**: US01
+- **描述**: 创建 `generate_token(user_id)` 辅助函数。
+- **依赖**: T002（JWT_SECRET 已配置）
+- **验收成立**: 单元测试 `test_generate_token()` 通过。
+
+---
+
+## 📊 迭代路线图
+
+| 迭代 | 代号 | 核心任务 | 退出标准 | 预估 |
+|------|------|---------|---------|------|
+| S1 | 基础阶段 | T001-T002 | DB 可连接 + 环境变量生效 | 1d |
+| S2 | 核心逻辑 | T003-T005 | 完整认证流程可运行 | 2d |
+
+---
+
+### 阶段 3：集成阶段
+
+#### T005 - 登录接口
+- **用户故事**: US01
+- **描述**: 实现 `POST /api/login`，校验凭证并返回 JWT。
+- **依赖**: T003（用户表已有数据）、T004（JWT 生成器就绪）
+- **输入**: T003 产出的 `users` 表 + T004 产出的 `generate_token()` 函数
+- **输出**: `/api/login` 端点 (`src/routes/auth.js`)
+- **验收成立**: 
+  1. 合法登录返回 `{token: "..."}`。
+  2. 非法登录返回 401。
+
+#### INT-S2 - [MILESTONE] S2 集成验证 — 核心逻辑
+- **用户故事**: US01
+- **类型**: 集成验证（迭代关卡）
+- **描述**: 验证 S2 退出标准：完整认证流程可运行
+- **依赖**: S2 的所有任务（T003-T005）
+- **验收成立**:
+  1. 运行 `npm run dev` 或等价命令
+  2. 通过 `/api/register` 注册新用户
+  3. 使用合法凭证登录 → 收到 JWT 令牌
+  4. 使用非法凭证登录 → 收到 401 错误
+  5. 所有单元测试通过（`npm test`）
+  6. 无 Linter 错误（`npm run lint`）
+
+---
+
+## 🔗 依赖图
+
+```
+T001 (数据库 Schema)
+  → T003 (注册)
+      → T005 (登录)
+
+T002 (环境配置) [P]
+  → T004 (JWT 辅助函数) [P]
+      → T005 (登录)
+```
+
+---
+
+## 📊 汇总
+
+| 阶段 | 任务总数 | 可并行数 |
+|-------|---------|---------|
+| 1     | 2       | 1       | 
+| 2     | 2       | 1       | 
+| 3     | 1       | 0       | 
+| **总计** | **5** | **2** |
+
+---
+
+## ✅ 验收标准
+
+在将蓝图标记为完成前：
+- [ ] 所有任务都有唯一 ID
+- [ ] 依赖关系明确（使用 `→` 表示）
+- [ ] 每个任务都有 `验收成立` 条件
+- [ ] 任务中不包含实际代码（仅保留 <10 行描述）
+- [ ] 总体估时合理
+- [ ] 用户已确认该任务清单
+
+---
+
+## 🚫 需要避免的反模式
+
+❌ **坏任务示例**：
+```
+T001 - 构建认证系统
+- 把认证相关的一切都做完
+- 让它安全又快速
+```
+
+✅ **好任务示例**：
+```
+T001 - 数据库 Schema 初始化
+- 描述: 创建包含 `id`、`email`、`password_hash` 的 `users` 表。
+- 验收成立: `psql -c "\d users"` 显示正确表结构。
+```
+
+---
+
+**下一步**：进入 `/build` workflow，按顺序实现这些任务。

package/templates/{.agent → .agents}/skills/task-reviewer/SKILL.md

@@ -14,7 +14,7 @@ description: 系统性审查 05_TASKS.md 的质量与完备性。通过 6 大检
 
 ## ⚡ 任务目标
 
-1. **加载文档 (必须)**: 读取 `genesis/v{N}/05_TASKS.md`、`01_PRD.md`、`02_ARCHITECTURE_OVERVIEW.md` 以及所有 `03_ADR/*.md`。
+1. **加载文档 (必须)**: 读取 `.anws/v{N}/05_TASKS.md`、`01_PRD.md`、`02_ARCHITECTURE_OVERVIEW.md` 以及所有 `03_ADR/*.md`。
 2. **构建语义模型**: 构建 3 个清单模型（见 §语义模型构建）。
 3. **执行 6 大 Pass (A→F)**: 顺序执行每个检测 Pass——每个 Pass 在语义模型上操作。
 4. **严重度分级**: 为每条发现分配严重度（CRITICAL / HIGH / MEDIUM / LOW）。
@@ -119,8 +119,9 @@ T{X.Y.Z}: 标题
 | C3 | **幽灵引用** | 任务引用了 Architecture 文档中不存在的组件/接口/API |
 | C4 | **缺失输入/输出** | 任务没有明确的输入或输出字段 |
 | C5 | **缺失验证说明** | 任务没有说明如何验证完成 |
+| C6 | **缺失验证类型** | 任务没有指定验证类型（单元测试/集成测试/E2E测试/手动验证/编译检查/Lint检查） |
 
-**严重度规则**: C2 在 P0 任务上 → CRITICAL。C3 一律 → HIGH。
+**严重度规则**: C2 在 P0 任务上 → CRITICAL。C3 一律 → HIGH。C6 在 P0 任务上 → HIGH。
 
 ---
 
@@ -185,7 +186,7 @@ T{X.Y.Z}: 标题
 ```markdown
 ## 📊 任务审查报告
 
-> **审查文件**: genesis/v{N}/05_TASKS.md  
+> **审查文件**: .anws/v{N}/05_TASKS.md  
 > **对照文档**: 01_PRD.md, 02_ARCHITECTURE_OVERVIEW.md, 03_ADR/*  
 > **日期**: {YYYY-MM-DD}
 

package/templates/{.agent → .agents}/skills/tech-evaluator/SKILL.md

@@ -14,7 +14,7 @@ description: 评估技术栈选项，使用加权决策矩阵和 ATAM 方法论
 ## ⚠️ 强制深度思考
 
 > [!IMPORTANT]
-> 在进行评估之前，你**必须**调用 `sequential thinking` 工具，视复杂情况进行 **3—7 步**推理。
+> 在进行评估之前，你**必须**使用 `sequential-thinking` skill，视复杂情况组织 **3—7 个 thought** 推理。
 > 思考内容例如：
 > 1.  "用户的核心需求是什么？必须支持哪些场景？"
 > 2.  "团队目前熟悉什么技术？学习新技术的时间预算是多少？"
@@ -83,7 +83,7 @@ description: 评估技术栈选项，使用加权决策矩阵和 ATAM 方法论
 
 ### 第五步：产出 ADR (Generate ADR)
 
-你**必须**使用 `write_to_file` 保存到 `genesis/v{N}/03_ADR/ADR_001_TECH_STACK.md`。
+你**必须**创建 `ADR_001_TECH_STACK.md`，并将其写入 `.anws/v{N}/03_ADR/`。
 
 ---
 

package/templates/{.agent → .agents}/skills/tech-evaluator/references/ADR_TEMPLATE.md

@@ -55,6 +55,15 @@
 
 ## 参考资料
 - [链接或引用]
+
+## 影响范围
+<!-- ⚠️ 记录哪些系统引用了本 ADR，便于修改时追踪影响 -->
+
+本 ADR 被以下系统引用:
+- [{系统名称}](../04_SYSTEM_DESIGN/{系统名称}.md) - §8 Trade-offs
+- [待补充]
+
+> **维护说明**: 当 SYSTEM_DESIGN 在 §8 引用本 ADR 时，应在此处添加引用记录。
 ```
 
 ---
@@ -66,3 +75,4 @@
 3. **不可变**: 一旦接受，视为历史记录；如需更改，创建新 ADR
 4. **版本控制**: 将 ADR 与代码一起存储在 Git 中
 5. **团队协作**: 在最终确定前收集团队反馈
+6. **追踪影响**: 在"影响范围"章节记录引用该 ADR 的系统，修改时能立即知道影响范围

package/templates/{.agent → .agents}/workflows/blueprint.md

@@ -1,5 +1,5 @@
 ---
-description: 将架构设计拆解为可执行的 WBS 任务清单，每个任务带验收标准和验证说明，生成 Mermaid 依赖图，前提是已完成 /genesis。
+description: "将架构设计拆解为可执行的 WBS 任务清单。适用于已完成 /genesis 后的任务规划阶段。产出 05_TASKS.md（含验收标准、Sprint 划分、Mermaid 依赖图、User Story Overlay）。"
 ---
 
 # /blueprint
@@ -8,14 +8,14 @@ description: 将架构设计拆解为可执行的 WBS 任务清单，每个任
 你是 **TASK ARCHITECT (任务规划师)**。
 
 **核心使命**：
-读取最新的架构版本 (`genesis/v{N}`)，将其拆解为**可执行的任务清单**。
+读取最新的架构版本 (`.anws/v{N}`)，将其拆解为**可执行的任务清单**。
 
 **核心原则**：
 - **验证驱动** - 每个任务必须有验证说明
 - **需求追溯** - 每个任务关联 [REQ-XXX]
 - **适度粒度** - 每个任务 2-8 小时工作量
 
-**Output Goal**: `genesis/v{N}/05_TASKS.md`
+**Output Goal**: `.anws/v{N}/05_TASKS.md`
 </phase_context>
 
 ---
@@ -34,10 +34,10 @@ description: 将架构设计拆解为可执行的 WBS 任务清单，每个任
 **目标**: 找到 Source of Truth。
 
 1.  **扫描版本**:
-    扫描 `genesis/` 目录，找到最新版本号 `v{N}`
+    扫描 `.anws/` 目录，找到最新版本号 `v{N}`
 2.  **确定最新版本**:
     - 找到数字最大的文件夹 `v{N}` (例如 `v3`)。
-    - **TARGET_DIR** = `genesis/v{N}`。
+    - **TARGET_DIR** = `.anws/v{N}`。
 
 3.  **检查必需文件**:
     - [ ] `{TARGET_DIR}/01_PRD.md` 存在
@@ -81,11 +81,33 @@ description: 将架构设计拆解为可执行的 WBS 任务清单，每个任
     - Given [前置条件]
     - When [执行动作]
     - Then [预期结果]
-  - **验证说明**: [如何检查完成，检查什么]
+  - **验证类型**: [单元测试 | 集成测试 | E2E测试 | 手动验证 | 编译检查 | Lint检查]
+  - **验证说明**: [如何检查完成，检查什么，具体命令或步骤]
   - **估时**: Xh
   - **依赖**: T{A}.{B}.{C} (如有)
 ```
 
+### 验证类型说明
+
+> [!IMPORTANT]
+> **验证类型决定验证方式和证据要求**：
+>
+> | 验证类型 | 验证方式 | 证据要求 |
+> |---------|---------|---------|
+> | **单元测试** | 运行测试套件 | 终端输出：`X passed, 0 failed` |
+> | **集成测试** | 运行集成测试或 API 调用 | 终端输出或日志截图 |
+> | **E2E测试** | 运行端到端测试脚本 | 测试报告或录屏 |
+> | **手动验证** | 人工检查 | 用户确认 ✅ |
+> | **编译检查** | 构建命令 | 终端输出：`Build succeeded` |
+> | **Lint检查** | Lint 命令 | 终端输出：`0 problems` |
+
+**验证类型选择指南**：
+- 纯逻辑/算法任务 → 单元测试
+- 跨模块/跨系统任务 → 集成测试
+- 用户交互/前端任务 → E2E测试 或 手动验证
+- 配置/基础设施任务 → 编译检查 或 手动验证
+- 代码质量任务 → Lint检查
+
 ### 接口追溯规则
 
 > [!IMPORTANT]
@@ -174,16 +196,7 @@ graph TD
 
 ---
 
-## Step 5: 复杂度审计
-
-调用 `complexity-guard` 确保:
-- 单个任务 ≤ 8 小时
-- 依赖关系不超过 5 层
-- 无循环依赖
-
----
-
-## Step 5.5: User Story Overlay (交叉验证)
+## Step 5: User Story Overlay (交叉验证)
 
 **目标**: 从**用户价值维度**验证任务完备性。WBS 按系统拆解，这一步从 User Story 视角交叉检查。
 
@@ -234,10 +247,10 @@ graph TD
 
 **目标**: 保存最终的任务清单，并**更新 AGENTS.md**。
 
-1.  **保存**: 将内容保存到 `genesis/v{N}/05_TASKS.md`
+1.  **保存**: 将内容保存到 `.anws/v{N}/05_TASKS.md`
 2.  **验证**: 确保文件包含所有任务、验收标准和依赖图。
 3.  **更新 AGENTS.md "当前状态"**:
-    - 活动任务清单: `genesis/v{N}/05_TASKS.md`
+    - 活动任务清单: `.anws/v{N}/05_TASKS.md`
     - 最近一次更新: `{Today}`
     - 写入初始波次建议，让 `/forge` 可以直接启动：
     ```markdown
@@ -288,7 +301,7 @@ graph TD
 
 ```markdown
 ### 当前任务状态
-- 任务清单: genesis/v{N}/05_TASKS.md
+- 任务清单: .anws/v{N}/05_TASKS.md
 - 总任务数: {N}, P0: {X}, P1: {Y}, P2: {Z}
 - Sprint 数: {S}
 - Wave 1 建议: T{X.Y.Z}, T{X.Y.Z}, T{X.Y.Z}
@@ -310,11 +323,3 @@ graph TD
 - ✅ 用户已确认
 </completion_criteria>
 
----
-
-## 🔀 Handoffs
-
-完成本工作流后，根据情况选择：
-
-- **质疑设计与任务** → `/challenge` — 对设计和任务清单进行系统性审查
-- **开始编码执行** → `/forge` — 按任务清单开始波次执行

package/templates/{.agent → .agents}/workflows/challenge.md

@@ -1,5 +1,5 @@
 ---
-description: 对项目决策进行系统性挑战，通过三维度审查框架（系统设计、运行模拟、工程实现）深度分析，用证据证明风险真实存在，产出分级问题清单。
+description: "对项目决策进行系统性挑战，用证据证明风险真实存在。适用于架构设计完成后、编码执行前的质量把关。产出 07_CHALLENGE_REPORT.md（含分级问题清单、Pre-Mortem 分析、假设验证）。"
 ---
 
 # /challenge
@@ -22,14 +22,14 @@ description: 对项目决策进行系统性挑战，通过三维度审查框架
 2. **运行模拟维度** - 时序正确性、状态同步、边界条件
 3. **工程实现维度** - 可测试性、可维护性、性能、安全
 
-**Output Goal**: `genesis/v{N}/07_CHALLENGE_REPORT.md`
+**Output Goal**: `.anws/v{N}/07_CHALLENGE_REPORT.md`
 
 ---
 
 ## ⚠️ CRITICAL 强制深度思考
 
 > [!IMPORTANT]
-> **为什么必须使用 `sequentialthinking`？**
+> **为什么必须使用 `sequential-thinking`？**
 > 
 > 质疑不是"扫一眼文档然后列问题"。质疑需要**深度思考**：
 > - 你需要理解设计者的意图，才能找到他们遗漏的部分
@@ -61,9 +61,9 @@ description: 对项目决策进行系统性挑战，通过三维度审查框架
 
 **目标**: 找到当前活动的架构版本。
 
-1.  **扫描版本**: `list_dir genesis/`
+1.  **扫描版本**: `list_dir .anws/`
 2.  **确定最新版本**: 找到数字最大的文件夹 `v{N}`（例如 `v3`）。
-3.  **TARGET_DIR** = `genesis/v{N}`。
+3.  **TARGET_DIR** = `.anws/v{N}`。
 
 ---
 
@@ -105,7 +105,7 @@ description: 对项目决策进行系统性挑战，通过三维度审查框架
 **目标**: 从未来回看，分析可能的失败原因——**但必须有逻辑依据**。
 
 > [!IMPORTANT]
-> 你**必须**使用 `sequentialthinking` 进行 **3-5步**深度思考。
+> 你**必须**使用 `sequential-thinking` skill 组织 **3-5 个 thought**进行深度思考。
 > 
 > **为什么？** Pre-Mortem 的本质是**模拟推演**。你需要：
 > - 在脑中"运行"这个项目
@@ -331,7 +331,8 @@ description: 对项目决策进行系统性挑战，通过三维度审查框架
 ### C1. [问题标题]
 
 **严重度**: Critical  
-**文档**: [文档位置]
+**文档**: [文档位置]  
+**ADR 影响**: [如涉及 ADR 修改,列出需要修改的 ADR 文件和引用该 ADR 的 SYSTEM_DESIGN 列表]
 
 **问题描述**:
 [详细描述，引用具体代码或设计]
@@ -394,6 +395,19 @@ description: 对项目决策进行系统性挑战，通过三维度审查框架
 | 假设 | 验证方法 | 结果 | 风险 |
 |------|---------|------|:----:|
 | ... | ... | ... | ✅/⚠️/❌ |
+
+### C. ADR 影响追踪
+
+> **提醒**: 如果本次审查发现需要修改 ADR,请检查以下引用链:
+
+| ADR 文件 | 引用该 ADR 的 SYSTEM_DESIGN | 影响说明 |
+|---------|---------------------------|---------|
+| [ADR-XXX](../03_ADR/ADR_XXX.md) | [system-1.md](../04_SYSTEM_DESIGN/system-1.md) §8 | [说明] |
+
+**修改 ADR 后的行动**:
+1. 更新 ADR 文件
+2. 检查上表中所有引用该 ADR 的 SYSTEM_DESIGN
+3. 确认这些系统设计是否需要相应调整
 ```
 
 ---
@@ -443,11 +457,3 @@ description: 对项目决策进行系统性挑战，通过三维度审查框架
 - ✅ 用户已阅读并决定下一步
 </completion_criteria>
 
----
-
-## 🔀 Handoffs
-
-完成本工作流后，根据情况选择：
-
-- **修复发现的问题** → `/change` — 根据 challenge 报告修复问题 *(存在需要修复的问题时)*
-- **开始编码执行** → `/forge` — 无阻塞问题，开始波次执行 *(无 CRITICAL 问题时)*

package/templates/{.agent → .agents}/workflows/change.md

@@ -1,5 +1,5 @@
 ---
-description: 处理微调级变更请求，通过 7 问题法严格评估，仅允许修改已有任务的细节，禁止创建新任务或添加新功能。需要新任务时引导用户运行 /genesis。
+description: "处理微调级变更请求，仅允许修改已有任务的细节。适用于任务执行过程中发现描述不准确、验收标准需调整等场景。禁止创建新任务或添加新功能，超出范围时引导用户运行 /genesis。"
 ---
 
 # /change
@@ -17,9 +17,9 @@ description: 处理微调级变更请求，通过 7 问题法严格评估，仅
 - **可追溯** - 所有变更都记录在 CHANGELOG
 
 **Output Goal**: 
-- 更新 `genesis/v{N}/05_TASKS.md` (仅修改已有任务)
-- 更新 `genesis/v{N}/06_CHANGELOG.md`
-- (可选) 微调 `genesis/v{N}/04_SYSTEM_DESIGN/` 中已有文件的细节
+- 更新 `.anws/v{N}/05_TASKS.md` (仅修改已有任务)
+- 更新 `.anws/v{N}/06_CHANGELOG.md`
+- (可选) 微调 `.anws/v{N}/04_SYSTEM_DESIGN/` 中已有文件的细节
 
 ---
 
@@ -78,10 +78,10 @@ description: 处理微调级变更请求，通过 7 问题法严格评估，仅
 ## Step 0: 定位当前版本
 
 1.  **扫描版本**:
-    扫描 `genesis/` 目录，找到最新版本号 `v{N}`
+    扫描 `.anws/` 目录，找到最新版本号 `v{N}`
 2.  **确定当前版本**:
     - 找到数字最大的文件夹 `v{N}`。
-    - **TARGET_DIR** = `genesis/v{N}`。
+    - **TARGET_DIR** = `.anws/v{N}`。
 
 3.  **检查必需文件**:
     - [ ] `{TARGET_DIR}/01_PRD.md` 存在
@@ -166,10 +166,26 @@ description: 处理微调级变更请求，通过 7 问题法严格评估，仅
     - 仅当任务的修改涉及设计细节时才需要同步修改
     - **只能修改已有文件，禁止创建新文件**
 
-5.  **确定修改内容**:
+5.  **ADR 引用检测** (CRITICAL):
+    > [!IMPORTANT]
+    > **ADR 与 SYSTEM_DESIGN 的单向引用链**:
+    > - ADR 记录跨系统决策详情
+    > - SYSTEM_DESIGN §8 Trade-offs **只引用 ADR，不复制决策内容**
+    > - 修改时：ADR 是源头，SYSTEM_DESIGN 通过引用关联
+    
+    **检测规则**:
+    - 如果修改 `04_SYSTEM_DESIGN/` 中的文件：
+      - 扫描文件中是否有 `[ADR-XXX]` 或 `../03_ADR/` 引用
+      - 如果有引用，**必须提醒用户**：该系统设计依赖 ADR 决策
+    - 如果用户请求修改 ADR：
+      - **禁止通过 /change 修改 ADR**（见权限边界表）
+      - 引导用户运行 `/genesis` 创建新版本
+
+6.  **确定修改内容**:
     对每个受影响的文件，明确要修改什么:
     - 05_TASKS.md: 描述调整? 验收标准修改? 估时调整? 优先级变更?
     - 04_SYSTEM_DESIGN: 接口细节? 参数调整? 样式微调?
+    - **ADR 引用**: 如果修改涉及决策，确认是否需要更新 ADR 引用
 
 ---
 
@@ -293,10 +309,3 @@ description: 处理微调级变更请求，通过 7 问题法严格评估，仅
 - ✅ 未添加任何 AI 自认为好的功能
 </completion_criteria>
 
----
-
-## 🔀 Handoffs
-
-完成本工作流后，根据情况选择：
-
-- **继续编码执行** → `/forge` — 变更完成，继续波次执行

package/templates/{.agent → .agents}/workflows/craft.md

@@ -1,5 +1,5 @@
 ---
-description: 创建高质量的工作流、技能和提示词，融合行业最佳实践与实战经验，提供 Workflow/Skill/Prompt 三种模式的标准框架。
+description: "创建高质量的工作流、技能和提示词。适用于需要扩展 AI 能力、标准化团队协作流程的场景。支持 Workflow（端到端任务）、Skill（可复用能力）、Prompt（一次性指令）三种模式。"
 ---
 
 # /craft
@@ -165,7 +165,7 @@ description: 创建高质量的工作流、技能和提示词，融合行业最
 ### 3.3 调研产出
 
 > [!IMPORTANT]
-> 你**必须**调用 `sequentialthinking` 进行 **3-5 步**思考，整合调研结果。
+> 你**必须**使用 `sequential-thinking` skill 组织 **3-5 个 thought**，整合调研结果。
 
 **思考引导**:
 1. "调研中发现了哪些值得借鉴的设计模式？"
@@ -351,7 +351,7 @@ description: 当用户需要 [具体触发场景] 时使用。[一句话核心
 
 ## 📤 输出格式
 
-> **输出路径**: [明确说明产出文件的保存路径，包含版本化路径变量 `genesis/v{N}/` 如适用]
+> **输出路径**: [明确说明产出文件的保存路径，包含版本化路径变量 `.anws/v{N}/` 如适用]
 
 \`\`\`markdown
 ### [输出标题]
@@ -407,7 +407,7 @@ description: 当用户需要 [具体触发场景] 时使用。[一句话核心
 **目标**: 用具体内容填充框架。
 
 > [!IMPORTANT]
-> 你**必须**调用 `sequentialthinking` 进行 **3-5 步**思考。
+> 你**必须**使用 `sequential-thinking` skill 组织 **3-5 个 thought**。
 > 复杂模式可以循环多次。
 >
 > **为什么？** 内容质量决定工具质量。
@@ -492,7 +492,7 @@ description: 当用户需要 [具体触发场景] 时使用。[一句话核心
 ### 防护机制
 - [ ] 有 `[!IMPORTANT]` 强制块
 - [ ] 有具体的思考步数要求
-- [ ] 有 `sequentialthinking` 调用要求
+- [ ] 有 `sequential-thinking` 调用要求
 
 ### 调研融合
 - [ ] 融入了调研发现的最佳实践
@@ -510,7 +510,7 @@ description: 当用户需要 [具体触发场景] 时使用。[一句话核心
 **目标**: 用批判眼光审视刚创建的工作流/技能，识别并修复缺陷。
 
 > [!IMPORTANT]
-> 你**必须**调用 `sequentialthinking` 进行 **3-5 步**批判性思考。
+> 你**必须**使用 `sequential-thinking` skill 组织 **3-5 个 thought**进行批判性思考。
 > 发现问题时可以再次循环深入分析。
 >
 > **为什么？** 第一版永远有缺陷。自我批评是质量保证的最后一道防线。
@@ -531,7 +531,7 @@ description: 当用户需要 [具体触发场景] 时使用。[一句话核心
 **思考引导 - 质量视角**:
 6. "有没有隐含假设没有说明？"
 7. "与调研中的最佳实践对比，还缺什么？"
-8. "这个工作流/技能，能达到 genesis/challenge 的质量标准吗？"
+8. "这个工作流/技能，能达到 `/genesis` / `/challenge` 的质量标准吗？"
 
 ### 8.2 产出审视清单
 
@@ -563,7 +563,7 @@ description: 当用户需要 [具体触发场景] 时使用。[一句话核心
 - Prompt → 用户指定位置或 `prompts/[name].md`
 
 **输出前检查**:
-- [ ] 所有路径引用正确（特别是版本化路径 `genesis/v{N}/`）
+- [ ] 所有路径引用正确（特别是版本化路径 `.anws/v{N}/`）
 - [ ] 输出位置在文档中明确声明
 - [ ] 文件名遵循 kebab-case 命名规范
 - [ ] Markdown 格式正确无误
@@ -662,14 +662,3 @@ description: 当用户需要 [具体触发场景] 时使用。[一句话核心
 - ✅ 输出了最终文档
 </completion_criteria>
 
----
-
-## 🔀 Handoffs
-
-完成本工作流后，根据情况选择：
-
-- **测试新创建的工作流** → `/quickstart` — 用 quickstart 流程测试新工作流 *(创建完成后需要验证时)*
-
----
-
-// turbo-all