@haaaiawd/anws 1.0.0

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

@@ -0,0 +1,474 @@
+---
+name: task-planner
+description: 使用WBS方法将系统设计文档分解为层次化任务。支持依赖分析、追溯链、验收标准。
+---
+
+# 任务规划大师手册 (Task Planning Master Manual)
+
+> "A task that can't be verified is a task that never finishes.  
+> A task without context is a task that's never understood."
+
+你是**任务规划大师**，负责将系统设计转化为**可执行的层次化任务清单**。
+
+---
+
+## ⚠️ 核心原则
+
+> [!IMPORTANT]
+> **任务规划的四大原则**：
+> 
+> 1. **WBS层次化** - Work Breakdown Structure三级组织
+> 2. **原子化** - 每个Task 1-2周可完成
+> 3. **可验证** - 每个Task有明确的Done When标准
+> 4. **可追溯** - 每个Task关联PRD需求 [REQ-XXX]
+
+❌ **错误做法**：
+- 平铺任务列表（无层次）
+- 任务过大（如"实现整个后端"）
+- 任务过小（如"写一行代码"）
+- 缺少验收标准
+- 忽略依赖关系
+
+✅ **正确做法**：
+- **三级层次**: System → Phase → Task
+- **合理粒度**: 每个Task 1-2周
+- **清晰验收**: 明确的Done When标准
+- **完整元数据**: ID, [REQ-XXX], 描述, 输入, 输出, 验收, 估时, 依赖, 优先级
+
+---
+
+## 🎯 WBS方法：Work Breakdown Structure
+
+### Level 1: System (系统级)
+**按系统分组**，从Architecture Overview获取系统清单。
+
+**示例**:
+```markdown
+## System 1: Frontend UX System
+## System 2: Backend API System
+## System 3: Database System
+```
+
+**规则**:
+- 每个系统对应Architecture Overview中的一个系统
+- 系统顺序按依赖关系排列（被依赖的在前）
+
+---
+
+### Level 2: Phase (阶段级)
+**每个系统内按实施阶段分组**。
+
+**标准Phases**:
+1. **Foundation** (基础设施) - 环境配置、项目初始化、依赖安装
+2. **Core** (核心功能) - 主要业务逻辑实现
+3. **Integration** (集成) - 跨系统集成、API对接
+4. **Polish** (优化) - 性能优化、错误处理、测试完善
+
+**示例**:
+```markdown
+### Phase 1: Foundation (基础设施)
+### Phase 2: Core Components (核心组件)
+### Phase 3: Integration (集成)
+### Phase 4: Polish (优化)
+```
+
+**规则**:
+- Phase按自然顺序排列（Foundation → Core → Integration → Polish）
+- 每个Phase有明确的目标说明
+
+---
+
+### Level 3: Task (任务级)
+**每个Phase内的具体任务**。
+
+**Task结构**:
+```markdown
+- [ ] **T{System}.{Phase}.{Seq}** [REQ-XXX]: 任务描述
+  - **描述**: 简洁说明"做什么"（不是"怎么做"）
+  - **输入**: 需要什么前置条件
+  - **输出**: 产出什么交付物
+  - **验收标准**: 
+    - [ ] Done When 1
+    - [ ] Done When 2
+  - **验证说明**: 如何确认任务完成 (检查什么，如何确认)
+  - **估时**: 预估工时（如: 2h, 1d, 1w）
+  - **依赖**: T{X}.{Y}.{Z} (依赖的Task ID)
+  - **优先级**: P0 | P1 | P2
+```
+
+**示例**:
+```markdown
+- [ ] **T1.1.1** [基础]: 设置 Vite + React 项目
+  - **描述**: 初始化前端项目，配置Vite、React、TypeScript
+  - **输入**: PRD (React技术栈要求)
+  - **输出**: 可运行的Hello World应用
+  - **验收标准**: 
+    - [ ] `npm run dev` 正常启动
+    - [ ] 页面显示"Hello World"
+    - [ ] TypeScript类型检查通过
+  - **估时**: 2h
+  - **依赖**: 无
+  - **优先级**: P0
+```
+
+---
+
+## 📋 任务元数据完整性
+
+### 必需字段
+
+| 字段 | 格式 | 说明 | 示例 |
+|------|------|------|------|
+| **ID** | T{System}.{Phase}.{Seq} | 唯一标识符 | T1.2.3 |
+| **[REQ-XXX]** | [REQ-001] 或 [基础] | 关联PRD需求或类型 | [REQ-001] |
+| **描述** | 简洁的动词短语 | "做什么"，不是"怎么做" | 实现LoginForm组件 |
+| **输入** | 前置条件列表 | 需要什么才能开始 | PRD, 设计稿 |
+| **输出** | 交付物列表 | 产出什么 | LoginForm.tsx |
+| **验收标准** | [ ] 列表 | Done When清单 | [ ] 组件渲染正常 |
+| **估时** | h, d, w | 预估工时 | 4h, 2d, 1w |
+| **依赖** | Task ID列表 | 依赖哪些Task | T1.1.1, T2.1.2 |
+| **优先级** | P0, P1, P2 | Must/Should/Nice | P0 |
+
+---
+
+### 可选字段
+
+| 字段 | 说明 | 示例 |
+|------|------|------|
+| **负责人** | 建议的负责人 | @frontend-dev |
+| **风险** | 潜在风险 | 依赖外部API，可能不稳定 |
+| **备注** | 额外说明 | 参考System Design第5章 |
+
+---
+
+## 🔗 依赖关系类型
+
+### 1. 逻辑依赖 (Logical Dependency)
+**定义**: 技术上必须的先后顺序
+
+**示例**:
+```
+T3.1.1 (数据库Schema) → T2.2.1 (后端API实现)
+T2.2.1 (后端API实现) → T1.2.1 (前端组件消费API)
+```
+
+**如何识别**: 问"如果A没完成，B能开始吗？"
+
+---
+
+### 2. 资源依赖 (Resource Dependency)
+**定义**: 共享资源导致的依赖
+
+**示例**:
+```
+T1.2.1 和 T1.2.2 由同一个开发者负责
+→ 必须串行执行（资源依赖）
+```
+
+**如何识别**: 问"A和B能否由不同人并行执行？"
+
+---
+
+### 3. 偏好依赖 (Preference Dependency)
+**定义**: 最佳实践建议的顺序（技术上可以并行）
+
+**示例**:
+```
+T1.2.1 (前端UI设计) → T2.2.1 (后端API实现)
+虽然可以并行，但先有UI设计更好
+```
+
+**如何识别**: 问"虽然可以并行，但有推荐顺序吗？"
+
+---
+
+## 📊 任务拆分原则
+
+### 原则1: 1-2周规则
+**规则**: 单个Task应该在1-2周内完成。
+
+**为什么？** 
+- 太大: 难以估时、风险不可控
+- 太小: 管理成本高、碎片化
+
+**检查**:
+- Task估时 > 2周 → 继续拆分
+- Task估时 < 2小时 → 考虑合并
+
+---
+
+### 原则2: 单一交付物
+**规则**: 每个Task应该产出一个可验证的交付物。
+
+**示例**:
+- ✅ 好: "实现LoginForm组件" → 交付物: LoginForm.tsx
+- ❌ 差: "做前端" → 交付物不明确
+
+---
+
+### 原则3: Git-Friendly
+**规则**: 每个Task应该对应一个可审查的PR。
+
+**示例**:
+- ✅ 好: Task完成 = 1个PR（~200-500行代码）
+- ❌ 差: Task完成 = 10个PR
+
+---
+
+### 原则4: 可验证性
+**规则**: 每个Task必须有明确的Done When标准。
+
+**示例**:
+- ✅ 好: "Done When: 单元测试通过, Lint无错误, 页面渲染正常"
+- ❌ 差: "Done When: 差不多完成了"
+
+---
+
+## 🛡️ 任务规划守则
+
+### 守则1: 追溯链完整
+**规则**: 每个Task必须关联PRD需求 [REQ-XXX]。
+
+**为什么？** 确保所有实现都有需求依据，避免过度设计。
+
+**示例**:
+```markdown
+- [ ] **T2.2.1** [REQ-001]: 实现 POST /auth/login 端点
+```
+
+**检查**:
+- 所有PRD需求是否都映射到了至少一个Task？
+- 所有Task是否都关联了PRD需求？
+
+---
+
+### 守则2: 验收标准具体化
+**规则**: Done When必须具体、可测试、可观察。
+
+**好的验收标准**:
+- [ ] 单元测试通过（`npm test`）
+- [ ] Lint无错误（`npm run lint`）
+- [ ] API返回200状态码
+- [ ] 页面在Chrome/Firefox正常渲染
+
+**差的验收标准**:
+- [ ] 功能正常（太模糊）
+- [ ] 代码写完了（无法验证）
+
+---
+
+### 守则3: 依赖关系可视化
+**规则**: 必须提供Mermaid依赖图。
+
+**示例**:
+```mermaid
+graph TD
+    T1.1.1[前端项目初始化] --> T1.2.1[实现LoginForm]
+    T2.1.1[后端项目初始化] --> T2.2.1[实现/auth/login]
+    T3.1.1[数据库Schema] --> T2.2.1
+    T2.2.1 --> T1.2.1
+```
+
+**为什么？** 一图胜千言，帮助理解任务顺序。
+
+---
+
+### 守则4: 估时保守
+**规则**: 估时应该偏保守，包含测试和文档时间。
+
+**估时公式**:
+```
+总估时 = 开发时间 × 1.5 + 测试时间 + 文档时间
+```
+
+**示例**:
+- 开发: 4h
+- 测试: 1h
+- 文档: 0.5h
+- **总估时**: 4 × 1.5 + 1 + 0.5 = 7.5h → 向上取整为 **1d**
+
+---
+
+## 🧰 工具箱
+
+> **输出路径**: 任务清单应保存到 `genesis/v{N}/05_TASKS.md`，由调用方 (blueprint workflow) 指定具体的 `v{N}` 版本号。
+
+### 工具1: Tasks模板
+使用WBS三级层次结构组织任务。
+
+**模板**:
+```markdown
+# 任务清单 (Task List)
+
+## 依赖图总览
+[Mermaid依赖图]
+
+## System 1: [System Name]
+
+### Phase 1: Foundation
+[Tasks列表]
+
+### Phase 2: Core
+[Tasks列表]
+
+...
+```
+
+---
+
+### 工具2: 依赖分析Checklist
+在拆分任务后，使用此Checklist分析依赖：
+
+- [ ] 识别所有逻辑依赖（A必须在B之前）
+- [ ] 识别资源依赖（同一人负责的任务）
+- [ ] 识别偏好依赖（推荐顺序）
+- [ ] 找出可并行的任务（标记[P]）
+- [ ] 绘制Mermaid依赖图
+
+---
+
+### 工具3: 任务粒度检查表
+
+| 检查项 | 标准 | 如何修正 |
+|--------|------|---------|
+| 估时 | 1-2周 | 过大→拆分, 过小→合并 |
+| 交付物 | 单一明确 | 多个→拆分为多个Task |
+| 验收标准 | 3-5条具体标准 | 模糊→细化为可测试条件 |
+| 依赖 | < 5个依赖 | 过多→重新组织Phase |
+
+---
+
+## 💡 常见场景与模式
+
+### 场景1: 新功能开发
+**特征**: 实现一个新的User Story
+
+**拆分模式**:
+```
+Phase 1: 数据层 (Database)
+  - T3.1.1: 设计Schema
+  - T3.1.2: 创建Migration
+
+Phase 2: 业务层 (Backend)
+  - T2.2.1: 实现API端点
+  - T2.2.2: 单元测试
+
+Phase 3: 表现层 (Frontend)
+  - T1.3.1: 实现UI组件
+  - T1.3.2: 集成API
+
+Phase 4: 验证
+  - T99.1: E2E测试
+```
+
+---
+
+### 场景2: 性能优化
+**特征**: 优化现有功能的性能
+
+**拆分模式**:
+```
+Phase 1: 分析 (Profiling)
+  - T1.1: 性能基准测试
+  - T1.2: 识别瓶颈
+
+Phase 2: 优化 (Optimization)
+  - T2.1: 添加缓存
+  - T2.2: 优化数据库查询
+
+Phase 3: 验证 (Validation)
+  - T3.1: 性能对比测试
+```
+
+---
+
+### 场景3: Bug修复
+**特征**: 修复已知缺陷
+
+**拆分模式**:
+```
+Phase 1: 复现 (Reproduction)
+  - T1.1: 编写复现步骤
+  - T1.2: 创建失败的测试用例
+
+Phase 2: 修复 (Fix)
+  - T2.1: 实现修复
+  - T2.2: 测试用例通过
+
+Phase 3: 回归测试 (Regression)
+  - T3.1: 确保未引入新Bug
+```
+
+---
+
+## 📊 质量检查清单
+
+完成任务拆解后，使用此清单自检：
+
+### 结构完整性
+- [ ] 使用WBS三级层次（System → Phase → Task）
+- [ ] 每个System有清晰的Phase划分
+- [ ] 每个Task有完整的元数据
+
+### 任务质量
+- [ ] 每个Task估时 1-2周
+- [ ] 每个Task有3-5条验收标准
+- [ ] 每个Task关联PRD需求 [REQ-XXX]
+- [ ] 每个Task描述清晰（"做什么"）
+
+### 依赖关系
+- [ ] 提供Mermaid依赖图
+- [ ] 标注逻辑依赖、资源依赖、偏好依赖
+- [ ] 无循环依赖
+- [ ] 识别可并行任务
+
+### 追溯链
+- [ ] 所有PRD需求映射到至少一个Task
+- [ ] 所有Task关联PRD需求或标注为[基础]
+- [ ] 跨系统集成任务已识别
+
+---
+
+## 🚀 快速上手示例
+
+**任务**: 为"用户登录"功能拆解任务
+
+**Step 1: 确定涉及的系统**
+- Frontend System, Backend API System, Database System
+
+**Step 2: 按Phase组织**
+```
+Database System:
+  Phase 1: Foundation
+    - T3.1.1: 创建users表Schema
+
+Backend API System:
+  Phase 2: Core
+    - T2.2.1: 实现 POST /auth/login
+    - T2.2.2: 单元测试
+
+Frontend System:
+  Phase 2: Core
+    - T1.2.1: 实现LoginForm组件
+    - T1.2.2: 集成/auth/login API
+```
+
+**Step 3: 分析依赖**
+```
+T3.1.1 → T2.2.1 → T1.2.1 (逻辑依赖)
+```
+
+**Step 4: 定义验收标准**
+```
+T2.2.1验收:
+  - [ ] API返回JWT Token
+  - [ ] 单元测试通过
+  - [ ] Postman测试成功
+```
+
+---
+
+**记住**: 好的任务拆解是平衡的艺术。  
+不要过度拆分（管理成本高），也不要过度聚合（风险不可控）。
+
+Happy Planning! 📋

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

@@ -0,0 +1,133 @@
+# Task Decomposition Template
+
+**Project**: [Project Name]  
+**Blueprint Phase**: Approved  
+**RFC Reference**: `genesis/v{N}/02_ARCHITECTURE_OVERVIEW.md`
+
+---
+
+## 📋 Task List
+
+### Legend
+- **ID**: Unique task identifier (T001, T002...)
+- **[P]**: Parallelizable (can run independently)
+- **[Verification]**: Checkpoint task (manual/E2E validation)
+- **User Story**: Maps to PRD (US01, US02...)
+- **Done When**: Verification criterion
+
+---
+
+### Phase 1: Foundation
+
+#### T001 - Database Schema Setup
+- **User Story**: US01
+- **Description**: Create `users` table with fields: `id`, `email`, `password_hash`, `created_at`.
+- **Dependencies**: None
+- **Done When**: `psql -c "\d users"` shows correct schema.
+  
+#### T002 - [P] Environment Configuration
+- **User Story**: US01
+- **Description**: Add `.env` file with `DATABASE_URL`, `JWT_SECRET`.
+- **Dependencies**: None
+- **Done When**: `docker-compose up` starts DB without errors.
+
+
+---
+
+### Phase 2: Core Logic
+
+#### T003 - User Registration Endpoint
+- **User Story**: US01
+- **Description**: Implement `POST /api/register` that hashes password and stores user.
+- **Dependencies**: T001 (DB Schema)
+- **Done When**: `curl -X POST /api
+
+#### T004 - [P] JWT Token Generation
+- **User Story**: US01
+- **Description**: Create `generate_token(user_id)` helper function.
+- **Dependencies**: T002 (JWT_SECRET configured)
+- **Done When**: Unit test `test_generate_token()` passes.
+
+---
+
+### Phase 3: Integration
+
+#### T005 - Login Endpoint
+- **User Story**: US01
+- **Description**: Implement `POST /api/login` that validates credentials and returns JWT.
+- **Dependencies**: T003 (User table populated), T004 (JWT generator ready)
+- **Done When**: 
+  1. Valid login returns `{token: "..."}`.
+  2. Invalid login returns 401.
+
+#### T005-CHK - [Verification] Verify US01 - User Authentication
+- **User Story**: US01
+- **Type**: Checkpoint (Story Milestone)
+- **Description**: Validate entire authentication flow works end-to-end.
+- **Dependencies**: All US01 tasks (T001-T005)
+- **Done When**:
+  1. Run `npm run dev` or equivalent
+  2. Register a new user via `/api/register`
+  3. Login with valid credentials → receives JWT token
+  4. Login with invalid credentials → receives 401 error
+  5. All unit tests pass (`npm test`)
+  6. No linter errors (`npm run lint`)
+
+---
+
+## 🔗 Dependency Graph
+
+```
+T001 (DB Schema)
+  → T003 (Register)
+      → T005 (Login)
+
+T002 (Env Config) [P]
+  → T004 (JWT Helper) [P]
+      → T005 (Login)
+```
+
+---
+
+## 📊 Summary
+
+| Phase | Total Tasks | Parallelizable |
+|-------|-------------|----------------|
+| 1     | 2           | 1              | 
+| 2     | 2           | 1              | 
+| 3     | 1           | 0              | 
+| **Total** | **5**   | **2**          |
+
+---
+
+## ✅ Acceptance Criteria
+
+Before marking Blueprint as complete:
+- [ ] All tasks have unique IDs
+- [ ] Dependencies are explicit (→ notation)
+- [ ] Each task has "Done When" criterion
+- [ ] No task contains actual code (only descriptions <10 lines)
+- [ ] Total estimated time is realistic
+- [ ] User has approved this task list
+
+---
+
+## 🚫 Anti-Patterns to Avoid
+
+❌ **Bad Task**:
+```
+T001 - Build Authentication System
+- Implement everything related to auth
+- Make it secure and fast
+```
+
+✅ **Good Task**:
+```
+T001 - Database Schema Setup
+- Description: Create `users` table with `id`, `email`, `password_hash`.
+- Done When: `psql -c "\d users"` shows correct schema.
+```
+
+---
+
+**Next Step**: Proceed to `/build` workflow to implement tasks sequentially.