@haaaiawd/anws 1.0.0

package/templates/.agent/skills/tech-evaluator/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: tech-evaluator
+description: 评估技术栈选项，使用加权决策矩阵和 ATAM 方法论产出架构决策记录 (ADR)。
+---
+
+# 技术评估师手册 (The Tech Evaluator's Manual)
+
+> "没有最好的技术栈，只有最适合的技术栈。" —— ThoughtWorks Technology Radar
+
+本技能基于 **SEI 的 ATAM (Architecture Tradeoff Analysis Method)** 和 **加权决策矩阵** 方法论。
+
+---
+
+## ⚠️ 强制深度思考
+
+> [!IMPORTANT]
+> 在进行评估之前，你**必须**调用 `sequential thinking` 工具，视复杂情况进行 **3—7 步**推理。
+> 思考内容例如：
+> 1.  "用户的核心需求是什么？必须支持哪些场景？"
+> 2.  "团队目前熟悉什么技术？学习新技术的时间预算是多少？"
+> 3.  "预算约束是什么？云服务成本敏感吗？"
+> 4.  "这个项目预期规模是什么？需要支持多少并发用户？"
+> 5.  "有没有合规要求（GDPR、等保）影响技术选择？"
+
+---
+
+## ⚡ 任务目标
+
+产出 **ADR (Architecture Decision Record)** 文档，记录技术栈决策及其理由。
+
+---
+
+## 🧭 评估流程 (The Evaluation)
+
+### 第一步：收集约束 (Gather Constraints)
+
+**必须从用户处获取**:
+- **功能需求**: 核心功能列表
+- **非功能需求**: 性能目标、可用性要求、安全等级
+- **团队情况**: 人数、技能栈、学习意愿
+- **预算**: 开发预算、运维预算、时间预算
+- **特殊约束**: 合规要求、现有系统集成、客户指定技术
+
+### 第二步：识别候选技术栈 (Identify Candidates)
+
+**2025 主流技术栈参考**:
+
+| 场景 | 推荐栈 | 备选 |
+|------|--------|------|
+| **Web 全栈** | Next.js + TypeScript | Nuxt, SvelteKit |
+| **后端 API** | Go / Rust / Node.js | Python FastAPI, Java Spring |
+| **桌面应用** | Tauri (Rust + Web) | Electron, Flutter Desktop |
+| **移动应用** | React Native / Flutter | Swift/Kotlin 原生 |
+| **AI/ML** | Python + PyTorch/TensorFlow | Rust (Candle), Julia |
+| **数据密集** | PostgreSQL + TimescaleDB | ClickHouse, DuckDB |
+
+### 第三步：12 维度评估 (12-Dimension Evaluation)
+
+使用以下矩阵对每个候选栈打分 (1-5 分):
+
+| 维度 | 权重建议 | 评估问题 |
+|------|:--------:|---------|
+| **需求匹配** | ★★★★★ | 能否实现所有核心功能？ |
+| **扩展性** | ★★★★ | 能否支撑 10x 增长？ |
+| **性能** | ★★★★ | 能否满足响应时间/吞吐量要求？ |
+| **安全性** | ★★★★ | 内置安全特性？合规支持？ |
+| **团队技能** | ★★★★★ | 团队熟悉程度？学习曲线？ |
+| **人才市场** | ★★★ | 招人容易吗？ |
+| **开发速度** | ★★★★ | 能否快速迭代？ |
+| **TCO (总成本)** | ★★★★ | 开发+运维+许可证成本？ |
+| **社区生态** | ★★★ | 库/工具丰富度？问题解答速度？ |
+| **长期维护** | ★★★ | 技术寿命？LTS 支持？ |
+| **集成能力** | ★★★ | 与现有系统/第三方服务集成？ |
+| **AI 就绪** | ★★ | 集成 AI/LLM 的便利性？ |
+
+### 第四步：权衡分析 (Trade-off Analysis)
+
+使用 **ATAM 方法**:
+1.  识别**质量属性场景** (如 "1000 并发用户时响应 < 200ms")
+2.  评估每个候选栈对场景的**支持程度**
+3.  识别**权衡点** (如 "选 Go 性能好但团队需学习")
+4.  识别**风险点** (如 "选新框架可能踩坑")
+
+### 第五步：产出 ADR (Generate ADR)
+
+你**必须**使用 `write_to_file` 保存到 `genesis/v{N}/03_ADR/ADR_001_TECH_STACK.md`。
+
+---
+
+## 📤 ADR 输出模板
+
+```markdown
+# ADR-001: 技术栈选择
+
+## 状态
+Accepted / Proposed / Deprecated
+
+## 背景
+[项目背景和约束描述]
+
+## 决策
+[选择的技术栈及核心理由]
+
+## 候选方案对比
+
+| 候选 | 总分 | 优势 | 劣势 |
+|------|------|------|------|
+| 方案 A | 42/60 | ... | ... |
+| 方案 B | 38/60 | ... | ... |
+
+## 权衡点
+- [权衡 1]
+- [权衡 2]
+
+## 后果
+- 正面: [...]
+- 负面: [...]
+- 需要的后续行动: [...]
+```
+
+---
+
+## 🛡️ 老师傅守则
+
+1.  **"无聊"技术优先**: 除非有充分理由，优先选择成熟稳定的技术。
+2.  **创新预算有限**: 每个项目只有 1-2 个"创新点"配额，其余用"无聊"技术。
+3.  **团队能力为王**: 再好的技术，团队不会用也是白搭。
+4.  **TCO 不只是钱**: 时间成本、认知成本也是成本。
+
+---
+
+## 🧰 工具箱
+
+*   `references/ADR_TEMPLATE.md`: ADR 模板
+*   `references/TECH_RADAR_2025.md`: 2025 技术雷达参考

package/templates/.agent/skills/tech-evaluator/references/ADR_TEMPLATE.md

@@ -0,0 +1,68 @@
+# ADR 模板 (Architecture Decision Record)
+
+## 用途
+此模板用于记录重大架构决策。每个 ADR 应专注于**单一决策**。
+
+---
+
+## 模板
+
+```markdown
+# ADR-[编号]: [决策标题]
+
+## 状态
+[Proposed | Accepted | Deprecated | Superseded by ADR-XXX]
+
+## 日期
+[YYYY-MM-DD]
+
+## 背景
+[描述驱动此决策的问题或情况]
+- 项目需求是什么？
+- 有什么约束？
+- 利益相关者的期望是什么？
+
+## 决策驱动因素
+[列出影响决策的关键因素]
+- 因素 1: ...
+- 因素 2: ...
+
+## 候选方案
+
+### 方案 A: [名称]
+- **描述**: [简要描述]
+- **优点**: 
+  - ...
+- **缺点**:
+  - ...
+
+### 方案 B: [名称]
+[同上格式]
+
+## 决策
+[明确陈述选择的方案及核心理由]
+
+## 后果
+
+### 正面
+- ...
+
+### 负面
+- ...
+
+### 需要的后续行动
+- ...
+
+## 参考资料
+- [链接或引用]
+```
+
+---
+
+## 最佳实践
+
+1. **保持简洁**: ADR 应在几分钟内可读完
+2. **聚焦单一决策**: 复杂决策拆分为多个 ADR
+3. **不可变**: 一旦接受，视为历史记录；如需更改，创建新 ADR
+4. **版本控制**: 将 ADR 与代码一起存储在 Git 中
+5. **团队协作**: 在最终确定前收集团队反馈

package/templates/.agent/workflows/blueprint.md

@@ -0,0 +1,185 @@
+---
+description: 将架构设计拆解为可执行的 WBS 任务清单，每个任务带验收标准和验证说明，生成 Mermaid 依赖图，前提是已完成 /genesis。
+---
+
+# /blueprint
+
+<phase_context>
+你是 **TASK ARCHITECT (任务规划师)**。
+
+**核心使命**：
+读取最新的架构版本 (`genesis/v{N}`)，将其拆解为**可执行的任务清单**。
+
+**核心原则**：
+- **验证驱动** - 每个任务必须有验证说明
+- **需求追溯** - 每个任务关联 [REQ-XXX]
+- **适度粒度** - 每个任务 2-8 小时工作量
+
+**Output Goal**: `genesis/v{N}/05_TASKS.md`
+</phase_context>
+
+---
+
+## ⚠️ CRITICAL 前提条件
+
+> [!IMPORTANT]
+> **Blueprint 必须基于特定版本的架构**
+> 
+> 你必须先找到最新的 Architecture Overview，才能拆解任务。
+
+---
+
+## Step 0: 定位架构版本 (Locate Architecture)
+
+**目标**: 找到 Source of Truth。
+
+1.  **扫描版本**:
+    扫描 `genesis/` 目录，找到最新版本号 `v{N}`
+2.  **确定最新版本**:
+    - 找到数字最大的文件夹 `v{N}` (例如 `v3`)。
+    - **TARGET_DIR** = `genesis/v{N}`。
+
+3.  **检查必需文件**:
+    - [ ] `{TARGET_DIR}/01_PRD.md` 存在
+    - [ ] `{TARGET_DIR}/02_ARCHITECTURE_OVERVIEW.md` 存在
+
+4.  **检查可选文件** (如缺失则提示):
+    - [ ] `{TARGET_DIR}/04_SYSTEM_DESIGN/` 存在
+    - 如缺失: 提示 "建议先运行 `/design-system` 为每个系统生成详细设计。跳过此步可能导致任务粒度过粗。"
+
+5.  **如果必需文件缺失**: 报错并提示运行 `/genesis` 更新该版本。
+
+---
+
+## Step 1: 加载设计文档
+
+**目标**: 从 **`{TARGET_DIR}`** 加载文档。
+
+1.  **读取 Architecture**: 读取 `{TARGET_DIR}/02_ARCHITECTURE_OVERVIEW.md`
+2.  **读取 PRD**: 读取 `{TARGET_DIR}/01_PRD.md`
+3.  **读取 ADRs**: 扫描 `{TARGET_DIR}/03_ADR/` 目录
+4.  **调用技能**: `task-planner`
+
+---
+
+## Step 2: 任务拆解 (Task Decomposition)
+
+**目标**: 使用 WBS 方法拆解任务。
+
+> [!IMPORTANT]
+> **任务格式要求** (CRITICAL):
+> 每个 Level 3 任务必须包含以下字段。
+
+### 任务格式模板
+
+```markdown
+- [ ] **T{X}.{Y}.{Z}** [REQ-XXX]: 任务标题
+  - **描述**: 具体要做什么
+  - **输入**: 依赖的文件/接口
+  - **输出**: 产出的文件/组件
+  - **验收标准**: 
+    - Given [前置条件]
+    - When [执行动作]
+    - Then [预期结果]
+  - **验证说明**: [如何检查完成，检查什么]
+  - **估时**: Xh
+  - **依赖**: T{A}.{B}.{C} (如有)
+```
+
+### 验证说明格式指南
+
+> [!IMPORTANT]
+> **验证说明**描述"如何确认任务完成"，而非具体命令。
+> AI 执行任务时根据说明自行确定检查方式。
+
+**示例**:
+| 任务类型 | 验证说明示例 |
+|---------|-------------|
+| 前端组件 | 检查组件是否正确渲染；确认交互逻辑符合预期 |
+| API 端点 | 调用接口确认返回正确格式；检查错误处理 |
+| 数据库 Schema | 确认 Migration 成功执行；验证数据类型正确 |
+| 配置文件 | 启动服务确认配置生效；检查环境变量读取 |
+| 单元测试 | 运行测试套件确认全部通过 |
+| 文档 | 阅读确认内容完整准确 |
+
+**输出路径**: `{TARGET_DIR}/05_TASKS.md`
+
+---
+
+## Step 3: 依赖分析 (Dependency Analysis)
+
+**目标**: 生成 Mermaid 依赖图。
+
+```mermaid
+graph TD
+    T1.1.1[初始化项目] --> T2.1.1[实现API]
+    T2.1.1 --> T3.1.1[前端集成]
+    T1.2.1[数据库Schema] --> T2.1.1
+```
+
+**输出**: 插入到 `{TARGET_DIR}/05_TASKS.md` 开头。
+
+---
+
+## Step 4: 复杂度审计
+
+调用 `complexity-guard` 确保:
+- 单个任务 ≤ 8 小时
+- 依赖关系不超过 5 层
+- 无循环依赖
+
+---
+
+## Step 5: 生成文档
+
+**目标**: 保存最终的任务清单，并**更新 AGENTS.md**。
+
+**目标**: 保存最终的任务清单，并**更新 .agent/rules/agents.md**。
+
+1.  **保存**: 将内容保存到 `genesis/v{N}/05_TASKS.md`
+2.  **验证**: 确保文件包含所有任务、验收标准和依赖图。
+3.  **更新 .agent/rules/agents.md "当前状态"**:
+    - 活动任务清单: `genesis/v{N}/05_TASKS.md`
+    - 待办任务数: `{X}` (计算 total tasks)
+    - 最近一次更新: `{Today}`
+
+---
+
+## 检查清单
+- ✅ 05_TASKS.md 是否包含所有 WBS 任务？
+- ✅ 每个任务是否有 Context 和 Acceptance Criteria？
+- ✅ 是否生成了 Mermaid 依赖图？
+- ✅ 已更新 .agent/rules/agents.md？
+
+---
+
+## Step 6: 最终确认
+
+**展示统计**:
+```markdown
+✅ Blueprint 阶段完成！
+
+📊 任务统计:
+  - 总任务数: {N}
+  - P0 任务: {X}
+  - P1 任务: {Y}
+  - P2 任务: {Z}
+  - 总预估工时: {T}h
+
+📁 产出: {TARGET_DIR}/05_TASKS.md
+
+📋 下一步行动:
+  1. 按依赖顺序执行 P0 任务
+  2. 每完成一个任务，标记 [x] 并运行验证
+```
+
+---
+
+<completion_criteria>
+- ✅ 定位到最新架构版本 `v{N}`
+- ✅ 任务清单 `05_TASKS.md` 已生成
+- ✅ 每个 Level 3 任务包含验证说明
+- ✅ 生成了 Mermaid 依赖图
+- ✅ 已更新 .agent/rules/agents.md
+- ✅ 用户已确认
+</completion_criteria>