@haaaiawd/anws 2.2.0 → 2.2.2

package/templates/.agents/skills/craft-authoring/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: craft-authoring
+description: 执行 /craft 时必读：提供 Workflow / Skill / Prompt 的脚手架模板、防护语法、填充与验证清单；长模板与自检细节不在 craft workflow 内重复，一律以本 skill 为准。
+---
+
+# Craft Authoring — 脚手架与自检
+
+本 skill 承接 **`/craft` workflow** 中「怎么写」的细节；`/craft` 只保留仪式与步骤路由。**禁止**在 workflow 里复述本节全文。
+
+## Workflow 骨架（最小可用）
+
+```markdown
+---
+description: [一句话，列表展示用]
+---
+
+# /name
+
+<phase_context>
+你是 **[角色]**。
+**使命**：…
+**能力**：…
+**限制**：…
+**原则**：…
+**与用户的关系**：…
+**Output Goal**: `路径`
+</phase_context>
+
+---
+
+## ⚠️ CRITICAL …
+
+> [!IMPORTANT]
+> **为什么**：…
+> - ❌ …
+> - ✅ …
+
+---
+
+## Step 1: …
+
+**目标**：…
+
+> [!IMPORTANT]
+> 你**必须**… **为什么？** …
+
+**思考引导**:
+1. …
+2. …
+
+---
+
+<completion_criteria>
+- ✅ …
+</completion_criteria>
+```
+
+## Skill 骨架（description 必须是触发条件）
+
+```markdown
+---
+name: kebab-name
+description: 当 [具体触发场景] 时加载。[一句话能力概括]
+---
+
+# 标题
+
+## 硬边界 / 原则
+…
+
+## 输入 / 输出契约
+…
+```
+
+**description 忌**：泛泛「我能处理 PDF」；**宜**：「当用户要读取/编辑 PDF 时」。
+
+## Prompt 骨架
+
+```markdown
+# 标题
+
+## 角色
+…
+
+## 任务
+…
+
+## 约束
+…
+
+## 输出格式
+…
+```
+
+## 防护语法速查
+
+
+| 机制                      | 用途       |
+| ----------------------- | -------- |
+| `[!IMPORTANT]`          | 不可跳过节点   |
+| `## ⚠️ CRITICAL`        | 边界醒目     |
+| `你**必须**`               | 强制动作     |
+| 具体引导问题                  | 替代「好好想想」 |
+| `<completion_criteria>` | 完成定义     |
+
+
+重要约束建议包含：**做什么 / 为什么 / 违反时长什么样**。
+
+## 填充内容（Step 5 等价）
+
+用 `sequential-thinking` 组织 **3–5 个 thought**，覆盖：目标、最易错点、每步 I/O、引导问题、模板复用、调研结论如何打入文档。
+
+**质量扫一眼**：目标是否逐步清晰、约束是否有「为什么」、是否有输出模板、关键处有 ❌/✅ 对照（如需）。
+
+## 验证清单（输出前）
+
+**结构**：frontmatter、`phase_context`（workflow）、CRITICAL 块、每步有目标、`<completion_criteria>`。
+
+**内容**：路径含 `.anws/v{N}/` 若适用、kebab-case、工具调用语法正确。
+
+## 自我批评（输出前最后一道）
+
+用 `sequential-thinking` **3–5 thought**：用户会在哪卡住？AI 可能在哪偷懒跳过？与 `/challenge` 级质量相比缺什么？随后迭代修复再交付。

package/templates/.agents/skills/e2e-testing-guide/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: e2e-testing-guide
+description: /forge 验证阶段专用：当任务要求 E2E、浏览器冒烟或手动网页验证时，产出可追溯的 Testing Guide（步骤、数据、证据）；具备浏览器工具与用户授权时可执行真实页面验证，否则仅交付定稿指南与未执行声明。
+---
+
+# E2E / Browser Testing Guide
+
+你是 **E2E Testing Guide** 作者。你不替代单元测试；你把「人在浏览器里如何证明没错」写成可执行协议。
+
+## 硬约束
+
+- **禁止根据 IDE 名称假设能力**：仅依据当前会话是否具备浏览器自动化/MCP、用户是否授权。
+- **无工具时的诚实**：无浏览器工具 → 输出 **L0 定稿指南** + **未执行声明**（不得写「已点击已截图」类伪造证据）。
+- **与 code-reviewer 分离**：本 skill 负责行为与链路验证指南；静态契约对齐归 `code-reviewer`。
+
+## 激活时机
+
+- **`/forge`**：任务 `**验证类型**` 为 E2E，或手动验证依赖浏览器/UI。
+
+## 产出结构（MUST）
+
+1. **环境**：URL/端口、账号角色、种子数据、feature flag。
+2. **步骤**：编号步骤，每步期望 DOM/网络/控制台信号。
+3. **证据**：截图命名、HAR/日志路径、录屏可选。
+4. **负面路径**：至少 1 条失败/空态/权限拒绝场景（若任务范围包含）。
+5. **评分**：对照项目 E2E Rubric（若任务引用）或最小 MUST 清单。
+
+## Rubric 最小 MUST（无项目模板时使用）
+
+- 可从冷启动复现
+- 每步有可观察断言（不是「看起来没问题」）
+- 覆盖任务验收标准中的 Given-When-Then
+- 记录已知 flake 与重试策略
+
+## Browser-capable 模式
+
+当浏览器工具可用且用户授权：
+
+1. 按 Guide 执行关键路径
+2. 附加截图或控制台摘录到验证报告
+3. 若环境阻塞（登录/验证码/缺数据）→ 记录 blocker，降级为 guide-only
+
+## 输出模板
+
+```markdown
+## E2E / Browser 验证 — T{X.Y.Z}
+
+**模式**: Executed | Guide-only  
+**环境**: …
+
+### 步骤
+1. …
+
+### 证据
+- …
+
+### 未执行 / Blockers（如有）
+- …
+```

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

@@ -146,7 +146,7 @@ description: 为单个系统设计详细的技术文档。负责架构图、接
 8. **Trade-offs & Alternatives** ⭐ - 为什么选A不选B
 9. **安全性考虑 (Security)** - 认证、加密、风险缓解
 10. **性能考虑 (Performance)** - 目标、优化策略、监控
-11. **测试策略 (Testing)** - 单元、集成、E2E、契约验证责任矩阵
+11. **测试策略 (Testing)** - 单元、集成、E2E、契约验证责任矩阵
 
 ### 可选章节 (Optional)
 12. **部署与运维 (Deployment)** - 部署流程、监控告警（小项目可简化）
@@ -383,11 +383,11 @@ flowchart TD
 
 在完成系统设计文档后，使用此清单自检：
 
-### 结构完整性
-- [ ] 包含所有11个必需章节
-- [ ] 架构图存在且清晰（Mermaid）
-- [ ] 数据流图存在（如适用）
-- [ ] 如系统涉及公共契约，11.5 Contract Verification Matrix 已填写
+### 结构完整性
+- [ ] 包含所有11个必需章节
+- [ ] 架构图存在且清晰（Mermaid）
+- [ ] 数据流图存在（如适用）
+- [ ] 如系统涉及公共契约，11.5 Contract Verification Matrix 已填写
 - [ ] Trade-offs章节至少讨论2个重要决策
 
 ### 内容质量

package/templates/.agents/skills/system-designer/references/system-design-template.md

@@ -440,23 +440,23 @@ classDiagram
 - **Test Scenarios**:
   - [ ] 用户登录完整流程（前端 → 后端 → 数据库）
 
-### 11.4 Performance Testing (性能测试)
-- **Tool**: Locust / k6
-- **Scenarios**:
-  - [ ] 1000 并发用户登录
-  - [ ] Target: p95 < 200ms
-
-### 11.5 Contract Verification Matrix (契约-验证责任矩阵)
-
-| 契约 | 风险级别 | 正常态验证 | 失败态验证 | 回归责任 |
-|------|---------|-----------|-----------|---------|
-| `POST /auth/login` | 关键路径 | 集成测试 | 非法凭证返回 401 | 认证主链路最小回归 |
-| JWT 生成规则 | 基础规则层 | 单元测试 | 非法输入/过期边界 | token 相关回归 |
-
-> **要求**:
-> - 每个关键公共契约都应有一条验证责任
-> - 失败态 / 边界态不应省略
-> - Blueprint 和 Challenge 应优先复用本矩阵，而不是完全依赖后续推断
+### 11.4 Performance Testing (性能测试)
+- **Tool**: Locust / k6
+- **Scenarios**:
+  - [ ] 1000 并发用户登录
+  - [ ] Target: p95 < 200ms
+
+### 11.5 Contract Verification Matrix (契约-验证责任矩阵)
+
+| 契约 | 风险级别 | 正常态验证 | 失败态验证 | 回归责任 |
+|------|---------|-----------|-----------|---------|
+| `POST /auth/login` | 关键路径 | 集成测试 | 非法凭证返回 401 | 认证主链路最小回归 |
+| JWT 生成规则 | 基础规则层 | 单元测试 | 非法输入/过期边界 | token 相关回归 |
+
+> **要求**:
+> - 每个关键公共契约都应有一条验证责任
+> - 失败态 / 边界态不应省略
+> - Blueprint 和 Challenge 应优先复用本矩阵，而不是完全依赖后续推断
 
 ---
 

package/templates/.agents/skills/task-planner/SKILL.md

@@ -28,21 +28,21 @@ description: 使用WBS方法将系统设计文档分解为层次化任务。支
 ## ⚠️ 核心原则
 
 > [!IMPORTANT]
-> **任务规划的四大原则**：
-> 
-> 1. **WBS层次化** - Work Breakdown Structure三级组织
-> 2. **原子化** - 每个 Task 优先控制在 2h-2d
-> 3. **可验证** - 默认使用 Given / When / Then；仅纯技术性基础任务允许清晰 Done When
-> 4. **可追溯** - 每个Task关联PRD需求 [REQ-XXX]
-
-> [!IMPORTANT]
-> **测试规划附加原则**：
-> - 优先选择**最轻但足够**的验证类型
-> - 如 Workflow / ADR 已声明测试策略，必须优先遵循，不得自行改重
-> - **冒烟测试默认仅用于 `INT-S{N}` 或极少数里程碑任务**
-> - **回归测试仅在已有关键能力可能被破坏时生成**，不是所有任务的默认要求
-> - **基础层、共享层、纯逻辑层默认优先单元测试**，主要分支、边界情况与错误路径应尽量覆盖
-> - **公共契约必须有承接**：至少一个实现任务 + 至少一个验证承接点
+> **任务规划的四大原则**：
+> 
+> 1. **WBS层次化** - Work Breakdown Structure三级组织
+> 2. **原子化** - 每个 Task 优先控制在 2h-2d
+> 3. **可验证** - 默认使用 Given / When / Then；仅纯技术性基础任务允许清晰 Done When
+> 4. **可追溯** - 每个Task关联PRD需求 [REQ-XXX]
+
+> [!IMPORTANT]
+> **测试规划附加原则**：
+> - 优先选择**最轻但足够**的验证类型
+> - 如 Workflow / ADR 已声明测试策略，必须优先遵循，不得自行改重
+> - **冒烟测试默认仅用于 `INT-S{N}` 或极少数里程碑任务**
+> - **回归测试仅在已有关键能力可能被破坏时生成**，不是所有任务的默认要求
+> - **基础层、共享层、纯逻辑层默认优先单元测试**，主要分支、边界情况与错误路径应尽量覆盖
+> - **公共契约必须有承接**：至少一个实现任务 + 至少一个验证承接点
 
 ❌ **错误做法**：
 - 平铺任务列表（无层次）
@@ -51,11 +51,11 @@ description: 使用WBS方法将系统设计文档分解为层次化任务。支
 - 缺少验收标准
 - 忽略依赖关系
 
-✅ **正确做法**：
-- **三级层次**: System → Phase → Task
-- **合理粒度**: 每个 Task 2h-2d
-- **清晰验收**: 默认 Given / When / Then，必要时使用清晰 Done When
-- **完整元数据**: ID, [REQ-XXX], 描述, 输入, 输出, 验收, 估时, 依赖, 优先级
+✅ **正确做法**：
+- **三级层次**: System → Phase → Task
+- **合理粒度**: 每个 Task 2h-2d
+- **清晰验收**: 默认 Given / When / Then，必要时使用清晰 Done When
+- **完整元数据**: ID, [REQ-XXX], 描述, 输入, 输出, 验收, 估时, 依赖, 优先级
 
 ---
 
@@ -115,41 +115,41 @@ description: 使用WBS方法将系统设计文档分解为层次化任务。支
 > - ✅ 好: `04_SYSTEM_DESIGN/auth.md` §JWT 签发
 > - ❌ 差: "JWT 相关设计"（无具体文档引用）
 
-**Task结构**:
-```markdown
-- [ ] **T{System}.{Phase}.{Seq}** [REQ-XXX]: 任务描述
-  - **描述**: 简洁说明"做什么"（不是"怎么做"）
-  - **输入**: 设计文档引用 + 前置任务产出（必须包含至少一个文档引用）
-  - **输出**: 产出什么交付物
-  - **契约承接**: 本任务实现或验证的公共契约；如无则写“无”
-  - **📎 参考**: ADR-XXX 或 System Design 章节（如有）
-  - **验收标准**: 
-    - Given [前置条件]
-    - When [执行动作]
-    - Then [预期结果]
-    - （仅纯技术性基础任务允许使用清晰 Done When 列表）
-  - **验证类型**: 单元测试 | 集成测试 | E2E测试 | 冒烟测试 | 回归测试 | 手动验证 | 编译检查 | Lint检查
-  - **验证说明**: 如何确认任务完成 (检查什么，如何确认)
-  - **估时**: 预估工时（如: 2h, 6h, 1d, 2d）
-  - **依赖**: T{X}.{Y}.{Z} (依赖的Task ID)
-  - **优先级**: P0 | P1 | P2
-```
-
-**示例**:
-```markdown
-- [ ] **T1.1.1** [基础]: 设置 Vite + React 项目
-  - **描述**: 初始化前端项目，配置Vite、React、TypeScript
-  - **输入**: PRD (React技术栈要求)
-  - **输出**: 可运行的Hello World应用 (`src/App.tsx`, `vite.config.ts`)
-  - **验收标准**: 
-    - [ ] `npm run dev` 正常启动
-    - [ ] 页面显示"Hello World"
-    - [ ] TypeScript类型检查通过
-  - **验证类型**: 编译检查
-  - **估时**: 2h
-  - **依赖**: 无
-  - **优先级**: P0
-```
+**Task结构**:
+```markdown
+- [ ] **T{System}.{Phase}.{Seq}** [REQ-XXX]: 任务描述
+  - **描述**: 简洁说明"做什么"（不是"怎么做"）
+  - **输入**: 设计文档引用 + 前置任务产出（必须包含至少一个文档引用）
+  - **输出**: 产出什么交付物
+  - **契约承接**: 本任务实现或验证的公共契约；如无则写“无”
+  - **📎 参考**: ADR-XXX 或 System Design 章节（如有）
+  - **验收标准**: 
+    - Given [前置条件]
+    - When [执行动作]
+    - Then [预期结果]
+    - （仅纯技术性基础任务允许使用清晰 Done When 列表）
+  - **验证类型**: 单元测试 | 集成测试 | E2E测试 | 冒烟测试 | 回归测试 | 手动验证 | 编译检查 | Lint检查
+  - **验证说明**: 如何确认任务完成 (检查什么，如何确认)
+  - **估时**: 预估工时（如: 2h, 6h, 1d, 2d）
+  - **依赖**: T{X}.{Y}.{Z} (依赖的Task ID)
+  - **优先级**: P0 | P1 | P2
+```
+
+**示例**:
+```markdown
+- [ ] **T1.1.1** [基础]: 设置 Vite + React 项目
+  - **描述**: 初始化前端项目，配置Vite、React、TypeScript
+  - **输入**: PRD (React技术栈要求)
+  - **输出**: 可运行的Hello World应用 (`src/App.tsx`, `vite.config.ts`)
+  - **验收标准**: 
+    - [ ] `npm run dev` 正常启动
+    - [ ] 页面显示"Hello World"
+    - [ ] TypeScript类型检查通过
+  - **验证类型**: 编译检查
+  - **估时**: 2h
+  - **依赖**: 无
+  - **优先级**: P0
+```
 
 ### 验证类型选择逻辑
 
@@ -163,39 +163,39 @@ description: 使用WBS方法将系统设计文档分解为层次化任务。支
 5. **修改可能影响已完成关键能力** → 回归测试
 6. **配置、脚手架、基础设施** → 编译检查 / Lint检查 / 手动验证
 
-**选择细则**:
-- 不要因为任务“看起来重要”就默认选择 E2E测试
-- 如果集成测试足以证明任务完成，就不要升级为 E2E测试
-- 如果只是里程碑 readiness 检查，优先使用少量冒烟测试，而不是新建大量 E2E任务
-- 如果只是验证旧能力未被破坏，优先复用已有测试集合作为回归测试
-
-### 契约风险覆盖规则
-
-> [!IMPORTANT]
-> **若任务产出包含新的公共契约或会修改现有公共契约，必须为其分配明确验证承接。**
-
-公共契约至少包括：
-- 操作契约
-- 跨系统接口
-- HTTP API
-- CLI 命令 / 参数语义
-- 配置结构 / 文件格式 / 状态格式
-- 错误语义 / 返回结构
-- 持久化结构
-
-规则：
-- 每个公共契约至少要有一个实现任务承接
-- 每个高风险公共契约至少要有一个验证承接点
-- 不得仅以“实现任务已有代码变更”视为契约闭合
-- 若契约属于基础规则层或低依赖纯逻辑，应优先补充单元测试，而不是直接升级为 E2E
-
-### 基础单测优先原则
-
-> [!IMPORTANT]
-> **对 registry、manifest、parser、planner、schema、diff、merge、normalizer、selector 等基础逻辑，优先生成单元测试任务。**
-
-- 如果这些逻辑是多个上层流程共享的基础设施，其单元测试默认视为必选，不应依赖高层流程测试间接覆盖
-- 如果一个 Sprint 新增了多个基础逻辑点，优先在同 Sprint 或紧邻 Sprint 内生成对应单测任务，不要全部拖到收尾期
+**选择细则**:
+- 不要因为任务“看起来重要”就默认选择 E2E测试
+- 如果集成测试足以证明任务完成，就不要升级为 E2E测试
+- 如果只是里程碑 readiness 检查，优先使用少量冒烟测试，而不是新建大量 E2E任务
+- 如果只是验证旧能力未被破坏，优先复用已有测试集合作为回归测试
+
+### 契约风险覆盖规则
+
+> [!IMPORTANT]
+> **若任务产出包含新的公共契约或会修改现有公共契约，必须为其分配明确验证承接。**
+
+公共契约至少包括：
+- 操作契约
+- 跨系统接口
+- HTTP API
+- CLI 命令 / 参数语义
+- 配置结构 / 文件格式 / 状态格式
+- 错误语义 / 返回结构
+- 持久化结构
+
+规则：
+- 每个公共契约至少要有一个实现任务承接
+- 每个高风险公共契约至少要有一个验证承接点
+- 不得仅以“实现任务已有代码变更”视为契约闭合
+- 若契约属于基础规则层或低依赖纯逻辑，应优先补充单元测试，而不是直接升级为 E2E
+
+### 基础单测优先原则
+
+> [!IMPORTANT]
+> **对 registry、manifest、parser、planner、schema、diff、merge、normalizer、selector 等基础逻辑，优先生成单元测试任务。**
+
+- 如果这些逻辑是多个上层流程共享的基础设施，其单元测试默认视为必选，不应依赖高层流程测试间接覆盖
+- 如果一个 Sprint 新增了多个基础逻辑点，优先在同 Sprint 或紧邻 Sprint 内生成对应单测任务，不要全部拖到收尾期
 
 ### Sprint 与冒烟测试绑定规则
 
@@ -289,16 +289,16 @@ T1.2.1 (前端UI设计) → T2.2.1 (后端API实现)
 
 ## 📊 任务拆分原则
 
-### 原则1: 2h-2d 规则
-**规则**: 单个 Task 应优先落在 2 小时到 2 天内；超过 2 天应继续拆分。
+### 原则1: 2h-2d 规则
+**规则**: 单个 Task 应优先落在 2 小时到 2 天内；超过 2 天应继续拆分。
 
 **为什么？** 
 - 太大: 难以估时、风险不可控
 - 太小: 管理成本高、碎片化
 
-**检查**:
-- Task估时 > 2天 → 继续拆分
-- Task估时 < 2小时 → 考虑合并
+**检查**:
+- Task估时 > 2天 → 继续拆分
+- Task估时 < 2小时 → 考虑合并
 
 ---
 
@@ -320,13 +320,13 @@ T1.2.1 (前端UI设计) → T2.2.1 (后端API实现)
 
 ---
 
-### 原则4: 可验证性
-**规则**: 每个 Task 必须有明确、可执行、可观察的验收标准；默认使用 Given / When / Then，纯技术性基础任务可使用清晰 Done When。
-
-**示例**:
-- ✅ 好: "Given 合法输入, When 调用接口, Then 返回 200 且结构符合契约"
-- ✅ 好: "[ ] 单元测试通过（仅用于纯技术性基础任务）"
-- ❌ 差: "Done When: 差不多完成了"
+### 原则4: 可验证性
+**规则**: 每个 Task 必须有明确、可执行、可观察的验收标准；默认使用 Given / When / Then，纯技术性基础任务可使用清晰 Done When。
+
+**示例**:
+- ✅ 好: "Given 合法输入, When 调用接口, Then 返回 200 且结构符合契约"
+- ✅ 好: "[ ] 单元测试通过（仅用于纯技术性基础任务）"
+- ❌ 差: "Done When: 差不多完成了"
 
 ---
 
@@ -348,14 +348,14 @@ T1.2.1 (前端UI设计) → T2.2.1 (后端API实现)
 
 ---
 
-### 守则2: 验收标准具体化
-**规则**: 默认使用 Given / When / Then；仅当纯技术性基础任务不适合 GWT 时，才退回清晰的 Done When。
+### 守则2: 验收标准具体化
+**规则**: 默认使用 Given / When / Then；仅当纯技术性基础任务不适合 GWT 时，才退回清晰的 Done When。
 
-**好的验收标准**:
-- Given 输入合法, When 调用接口, Then 返回 200 且结构符合契约
-- Given 非法凭证, When 请求登录, Then 返回 401 且错误语义一致
-- [ ] 单元测试通过（仅用于纯技术性基础任务）
-- [ ] Lint无错误（仅用于纯技术性基础任务）
+**好的验收标准**:
+- Given 输入合法, When 调用接口, Then 返回 200 且结构符合契约
+- Given 非法凭证, When 请求登录, Then 返回 401 且错误语义一致
+- [ ] 单元测试通过（仅用于纯技术性基础任务）
+- [ ] Lint无错误（仅用于纯技术性基础任务）
 
 **差的验收标准**:
 - [ ] 功能正常（太模糊）
@@ -437,7 +437,7 @@ graph TD
 
 | 检查项 | 标准 | 如何修正 |
 |--------|------|---------|
-| 估时 | 2h-2d | 过大→拆分, 过小→合并 |
+| 估时 | 2h-2d | 过大→拆分, 过小→合并 |
 | 交付物 | 单一明确 | 多个→拆分为多个Task |
 | 验收标准 | 3-5条具体标准 | 模糊→细化为可测试条件 |
 | 依赖 | < 5个依赖 | 过多→重新组织Phase |
@@ -560,11 +560,11 @@ Phase 3: 回归测试 (Regression)
 - [ ] 每个System有清晰的Phase划分
 - [ ] 每个Task有完整的元数据
 
-### 任务质量
-- [ ] 每个Task估时 2h-2d
-- [ ] 每个Task有3-5条验收标准
-- [ ] 每个Task关联PRD需求 [REQ-XXX]
-- [ ] 每个Task描述清晰（"做什么"）
+### 任务质量
+- [ ] 每个Task估时 2h-2d
+- [ ] 每个Task有3-5条验收标准
+- [ ] 每个Task关联PRD需求 [REQ-XXX]
+- [ ] 每个Task描述清晰（"做什么"）
 
 ### 依赖关系
 - [ ] 提供Mermaid依赖图