@haaaiawd/anws 2.2.2 → 2.2.3

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

@@ -1,135 +1,144 @@
----
-name: tech-evaluator
-description: 评估技术栈选项，使用加权决策矩阵和 ATAM 方法论产出架构决策记录 (ADR)。
----
-
-# 技术评估师手册 (The Tech Evaluator's Manual)
-
-> "没有最好的技术栈，只有最适合的技术栈。" —— ThoughtWorks Technology Radar
-
-本技能基于 **SEI 的 ATAM (Architecture Tradeoff Analysis Method)** 和 **加权决策矩阵** 方法论。
-
----
-
-## ⚠️ 强制深度思考
-
-> [!IMPORTANT]
-> 在进行评估之前，你**必须**使用 `sequential-thinking` skill，视复杂情况组织 **3—7 个 thought** 推理。
-> 思考内容例如：
-> 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)
-
-你**必须**创建 `ADR_001_TECH_STACK.md`，并将其写入 `.anws/v{N}/03_ADR/`。
-
----
-
-## 📤 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 技术雷达参考
+---
+
+## name: tech-evaluator
+
+description: 评估技术栈选项，使用加权决策矩阵和 ATAM 方法论产出架构决策记录 (ADR)。
+
+# 技术评估师手册 (The Tech Evaluator's Manual)
+
+> "没有最好的技术栈，只有最适合的技术栈。" —— ThoughtWorks Technology Radar
+
+本技能基于 **SEI 的 ATAM (Architecture Tradeoff Analysis Method)** 和 **加权决策矩阵** 方法论。
+
+---
+
+## 强制深度思考
+
+> [!IMPORTANT]
+> 在进行评估之前，你**必须**使用 `sequential-thinking` skill，视复杂情况组织 **3—7 个 thought** 推理。
+> 思考内容例如：
+>
+> 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)
+
+你**必须**创建 `ADR_001_TECH_STACK.md`，并将其写入 `.anws/v{N}/03_ADR/`。
+
+---
+
+## 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/.agents/skills/tech-evaluator/references/ADR_TEMPLATE.md

@@ -1,78 +1,80 @@
-# ADR 模板 (Architecture Decision Record)
-
-## 用途
-此模板用于记录重大架构决策。每个 ADR 应专注于**单一决策**。
-
----
-
-## 模板
-
-```markdown
-# ADR-[编号]: [决策标题]
-
-## 状态
-[Proposed | Accepted | Deprecated | Superseded by ADR-XXX]
-
-## 日期
-[YYYY-MM-DD]
-
-## 背景
-[描述驱动此决策的问题或情况]
-- 项目需求是什么？
-- 有什么约束？
-- 利益相关者的期望是什么？
-
-## 决策驱动因素
-[列出影响决策的关键因素]
-- 因素 1: ...
-- 因素 2: ...
-
-## 候选方案
-
-### 方案 A: [名称]
-- **描述**: [简要描述]
-- **优点**: 
-  - ...
-- **缺点**:
-  - ...
-
-### 方案 B: [名称]
-[同上格式]
-
-## 决策
-[明确陈述选择的方案及核心理由]
-
-## 后果
-
-### 正面
-- ...
-
-### 负面
-- ...
-
-### 需要的后续行动
-- ...
-
-## 参考资料
-- [链接或引用]
-
-## 影响范围
-<!-- ⚠️ 记录哪些系统引用了本 ADR，便于修改时追踪影响 -->
-
-本 ADR 被以下系统引用:
-- [{系统名称}](../04_SYSTEM_DESIGN/{系统名称}.md) - §8 Trade-offs
-- [待补充]
-
-> **维护说明**: 当 SYSTEM_DESIGN 在 §8 引用本 ADR 时，应在此处添加引用记录。
-```
-
----
-
-## 最佳实践
-
-1. **保持简洁**: ADR 应在几分钟内可读完
-2. **聚焦单一决策**: 复杂决策拆分为多个 ADR
-3. **不可变**: 一旦接受，视为历史记录；如需更改，创建新 ADR
-4. **版本控制**: 将 ADR 与代码一起存储在 Git 中
-5. **团队协作**: 在最终确定前收集团队反馈
-6. **追踪影响**: 在"影响范围"章节记录引用该 ADR 的系统，修改时能立即知道影响范围
+# ADR 模板 (Architecture Decision Record)
+
+## 用途
+
+此模板用于记录重大架构决策。每个 ADR 应专注于**单一决策**。
+
+---
+
+## 模板
+
+```markdown
+# ADR-[编号]: [决策标题]
+
+## 状态
+[Proposed | Accepted | Deprecated | Superseded by ADR-XXX]
+
+## 日期
+[YYYY-MM-DD]
+
+## 背景
+[描述驱动此决策的问题或情况]
+- 项目需求是什么？
+- 有什么约束？
+- 利益相关者的期望是什么？
+
+## 决策驱动因素
+[列出影响决策的关键因素]
+- 因素 1: ...
+- 因素 2: ...
+
+## 候选方案
+
+### 方案 A: [名称]
+- **描述**: [简要描述]
+- **优点**: 
+  - ...
+- **缺点**:
+  - ...
+
+### 方案 B: [名称]
+[同上格式]
+
+## 决策
+[明确陈述选择的方案及核心理由]
+
+## 后果
+
+### 正面
+- ...
+
+### 负面
+- ...
+
+### 需要的后续行动
+- ...
+
+## 参考资料
+- [链接或引用]
+
+## 影响范围
+<!--  记录哪些系统引用了本 ADR，便于修改时追踪影响 -->
+
+本 ADR 被以下系统引用:
+- [{系统名称}](../04_SYSTEM_DESIGN/{系统名称}.md) - §8 Trade-offs
+- [待补充]
+
+> **维护说明**: 当 SYSTEM_DESIGN 在 §8 引用本 ADR 时，应在此处添加引用记录。
+```
+
+---
+
+## 最佳实践
+
+1. **保持简洁**: ADR 应在几分钟内可读完
+2. **聚焦单一决策**: 复杂决策拆分为多个 ADR
+3. **不可变**: 一旦接受，视为历史记录；如需更改，创建新 ADR
+4. **版本控制**: 将 ADR 与代码一起存储在 Git 中
+5. **团队协作**: 在最终确定前收集团队反馈
+6. **追踪影响**: 在"影响范围"章节记录引用该 ADR 的系统，修改时能立即知道影响范围
+