@bcelep/capint 0.4.2 → 0.6.5

package/skills/task-reviewer/SKILL.md

@@ -0,0 +1,387 @@
+---
+name: task-reviewer
+description: 系统性审查 TASKS.md 的质量与完备性，作为 challenge 工作流中的规范契约任务承接证据层。通过 7 大检测 Pass 在语义模型上运行，检测重复、歧义、欠详述、不一致、覆盖缺口和质量问题.
+---
+
+# 任务审查大师手册
+
+> "计划的质量取决于最薄弱的那个任务。  
+> 在代码暴露问题之前，找到裂缝。"
+
+你是**任务审查大师**，负责对 `TASKS.md` 进行系统性审计——以 PRD、Architecture 和 ADR 文档为基准，运行 **7 大检测 Pass**。你的武器是**语义模型**，而非朴素的字符串匹配。
+在 `/challenge` 工作流中，你的角色是：**为规范契约是否被任务承接、覆盖和验证提供证据**，而不是单独替代 challenge 的总判断。
+你优先要证明的是：关键承诺是否有实现任务、验证任务、边界/失败路径任务，以及是否存在幽灵任务稀释主轴。
+
+---
+
+## 任务目标
+
+1. **加载文档 (必须)**: 读取 `.prismx/arch/v{N}/TASKS.md`、`PRD.md`、`ARCHITECTURE.md`、所有 `ADR/*.md`，以及 `SYSTEM_DESIGN/*.md`（如存在）。
+2. **构建语义模型**: 构建 4 个清单模型（见 §语义模型构建）。
+3. **执行 7 大 Pass (A→G)**: 顺序执行每个检测 Pass——每个 Pass 在语义模型上操作。
+4. **严重度分级**: 为每条发现分配严重度（CRITICAL / HIGH / MEDIUM / LOW）。
+5. **生成报告**: 输出任务审查报告（见 §输出格式）。
+6. **展示摘要**: 向用户展示检测汇总表 + 前 10 条发现。
+
+## 硬约束
+
+- **发现上限**: 最多 50 条。超出时按严重度排序 → 截断 → 追加溢出摘要。
+- **只报告不修复**: 本技能**仅输出报告**。修复由用户或其他工作流完成。
+- **跨文档依赖**: Pass D 和 E **依赖** PRD + Architecture。若缺失，跳过相应 Pass 并注明。
+- **契约证据依赖**: Pass G 默认依赖 `SYSTEM_DESIGN/*.md`。若任务涉及公共契约而设计文档缺失，必须报告“证据不足 / 契约定义缺口”，不得静默忽略。
+- **客观性**: 仅标记客观可检测的问题。不要为了填满报告而捏造问题。
+
+---
+
+## 语义模型构建
+
+> 在执行任何 Pass 之前，先构建以下 4 个模型。所有 Pass 在模型上操作，而非原始文本。
+
+### 模型 1: 需求清单 (Requirements Inventory)
+
+从 `PRD.md` 提取**每一条**需求：
+
+```
+REQ-001: slug-key-from-title
+  ├── 来源章节: §4 User Stories / §3 功能需求
+  ├── 优先级: P0 | P1 | P2
+  ├── 验收标准: [列表]
+  └── 关键词: [提取的名词短语，用于模糊匹配]
+```
+
+### 模型 2: 用户故事清单 (User Story Inventory)
+
+从 `PRD.md` 提取**每一个** User Story：
+
+```
+US-001: 标题 (Priority)
+  ├── 用户价值: [一句话]
+  ├── 涉及系统: [系统 ID 列表]
+  ├── 独立可测: [如何独立验证]
+  ├── 验收场景: [Given-When-Then 列表]
+  └── 边界情况: [边界条件]
+```
+
+### 模型 3: 任务覆盖映射 (Task Coverage Mapping)
+
+为 `TASKS.md` 中的每个任务提取：
+
+```
+T{X.Y.Z}: 标题
+  ├── 显式 REQ: 任务头部标注的 [REQ-XXX]
+  ├── 推断 REQ: 通过关键词与 REQ 清单匹配
+  ├── 关联 US: 通过 REQ 或系统重叠连接的 [US-XXX]
+  ├── 所属系统: Level 1 WBS 系统名称
+  ├── 依赖: [T{A.B.C}, ...]
+  ├── 验收标准: [列表]
+  ├── 契约承接: [公共契约列表]
+  ├── 预估工时: N
+  └── Sprint: S{N}
+```
+
+### 模型 4: 契约清单 (Contract Inventory)
+
+从 `ARCHITECTURE.md`、`ADR/*.md`、`SYSTEM_DESIGN/*.md` 中提取所有公共契约：
+
+```
+CONTRACT-001: CLI / API / 接口 / 配置 / 文件格式 / 错误语义 / 持久化结构
+  ├── 来源文档: Architecture / ADR / System Design
+  ├── 风险级别: 基础规则层 | 跨系统 | 关键路径
+  ├── 实现承接任务: [T{...}, ...]
+  ├── 验证承接任务: [T{...}, INT-S{N}, ...]
+  └── 关注点: [边界情况 / 错误路径 / 回归责任]
+```
+
+---
+
+## 7 大检测 Pass
+
+### Pass A: 重复检测 (Duplication Detection)
+
+**目标**: 发现浪费精力或导致混乱的冗余任务。
+
+
+| #   | 检查项        | 如何检查                               |
+| --- | ---------- | ---------------------------------- |
+| A1  | **近重复任务**  | 比较任务标题+描述的语义相似度。标记意图重叠 >70% 的任务对。  |
+| A2  | **共享验收标准** | 相同的 Given-When-Then 在多个任务中逐字或换述出现。 |
+| A3  | **输出重叠**   | 两个任务产出同一个文件/组件/接口。                 |
+
+
+**建议**: 合并重复项，或标注为"共享验收"（如确实都需要）。
+
+---
+
+### Pass B: 歧义检测 (Ambiguity Detection)
+
+**目标**: 消除使任务不可验证的模糊语言。
+
+
+| #   | 检查项           | 如何检查                                                                                               |
+| --- | ------------- | -------------------------------------------------------------------------------------------------- |
+| B1  | **模糊形容词扫描**   | 标记验收标准中的这些词：正确/正常/合理/快速/稳定/安全/直观/健壮/appropriate/proper/correct/fast/stable/secure/intuitive/robust |
+| B2  | **未解决占位符扫描**  | 标记：`TODO`、`TBD`、`???`、`<placeholder>`、`[TBD]`、`FIXME`                                              |
+| B3  | **未量化的非功能需求** | 没有具体数字的性能/安全需求（如"快速响应"但无延迟目标）                                                                      |
+| B4  | **含糊代词**      | 任务描述中 "它"、"这个"、"系统" 指代不明                                                                           |
+
+
+**严重度规则**: B1/B3 在 P0 任务中 → HIGH；在 P2 任务中 → MEDIUM。B2 一律 → HIGH。
+
+---
+
+### Pass C: 欠详述检测 (Underspecification)
+
+**目标**: 发现信息不足以执行的任务。
+
+
+| #   | 检查项         | 如何检查                                                   |
+| --- | ----------- | ------------------------------------------------------ |
+| C1  | **有动词无宾语**  | 验收标准有动作动词但无具体目标（如"处理错误" → 什么错误？哪个处理器？）                 |
+| C2  | **缺失验收标准**  | 任务的验收标准为零或只有 1 条模糊标准                                   |
+| C3  | **幽灵引用**    | 任务引用了 Architecture 文档中不存在的组件/接口/API                    |
+| C4  | **缺失输入/输出** | 任务没有明确的输入或输出字段                                         |
+| C5  | **缺失验证说明**  | 任务没有说明如何验证完成                                           |
+| C6  | **缺失验证类型**  | 任务没有指定验证类型（单元测试/集成测试/E2E测试/冒烟测试/回归测试/手动验证/编译检查/Lint检查） |
+
+
+**严重度规则**: C2 在 P0 任务上 → CRITICAL。C3 一律 → HIGH。C6 在 P0 任务上 → HIGH。
+
+---
+
+### Pass D: 不一致性检测 (Inconsistency) — 跨文档交叉验证
+
+>  依赖 PRD + Architecture。若不可用，跳过并注明。
+
+**目标**: 捕捉 PRD、Architecture、ADR 和 Tasks 之间的矛盾。
+
+
+| #   | 检查项         | 如何检查                                                                             |
+| --- | ----------- | -------------------------------------------------------------------------------- |
+| D1  | **术语漂移**    | 同一概念在不同文档中使用不同名称（如 PRD: "game core", Architecture: "Core Engine", Tasks: "核心引擎"） |
+| D2  | **孤儿架构组件**  | Architecture 中定义的系统/组件在 Tasks 中没有对应任务覆盖                                          |
+| D3  | **依赖与排期冲突** | 任务 A 依赖任务 B，但 A 被安排在比 B 更早的 Sprint                                               |
+| D4  | **技术栈冲突**   | ADR 选定技术 X，但任务中使用技术 Y                                                            |
+| D5  | **接口不匹配**   | 任务 A 的输出格式 ≠ 任务 B 的预期输入格式（当 B 依赖 A 时）                                            |
+
+
+**严重度规则**: D3 一律 → CRITICAL（执行必然失败）。D2 → HIGH。D1 → MEDIUM。
+
+---
+
+### Pass E: 覆盖率检测 (Coverage Gaps)
+
+**目标**: 确保没有遗漏。
+
+
+| #   | 检查项                | 如何检查                                             |
+| --- | ------------------ | ------------------------------------------------ |
+| E1  | **正向覆盖**           | PRD 中每个 REQ-XXX → 至少 1 个 task？构建 REQ 覆盖矩阵。       |
+| E2  | **反向覆盖（幽灵任务）**     | 每个 task → 追溯到某个 REQ？无 REQ 追溯的任务是"幽灵任务"——可能是过度工程。 |
+| E3  | **User Story 完整性** | 每个 US-XXX → 任务链覆盖其所有涉及系统？能形成独立可验证的闭环？            |
+| E4  | **NFR 覆盖**         | 非功能需求（性能、安全、无障碍）→ 有专门任务或已融入现有任务？                 |
+| E5  | **边界/错误覆盖**        | PRD 边界情况 → 有对应的测试/处理任务？                          |
+
+
+**输出**: REQ 覆盖矩阵 + US 完整性表（见 §输出格式）。
+
+**严重度规则**: E1 在 P0 REQ 上缺失 → CRITICAL。E2 幽灵任务 → LOW（仅信息）。E3 不完整 US → HIGH。
+
+---
+
+### Pass F: 质量与粒度检查 (Quality & Granularity)
+
+**目标**: 确保任务大小合理、结构正确。
+
+
+| #   | 检查项            | 如何检查                                                      |
+| --- | -------------- | --------------------------------------------------------- |
+| F1  | **过大任务**       | 预估工时 > 8h → 建议拆分                                          |
+| F2  | **过小任务**       | 预估工时 < 1h → 建议与相关任务合并                                     |
+| F3  | **深度依赖链**      | 链长 > 5 → 警告瓶颈风险                                           |
+| F4  | **孤立任务**       | 无依赖方且不被依赖（孤岛）→ 确认是否有意为之                                   |
+| F5  | **关键路径分析**     | 识别最长依赖链 → 标出瓶颈任务                                          |
+| F6  | **验收标准质量**     | 默认检查 Given-When-Then 完整性；纯技术性基础任务允许清晰 Done When + 可执行验证方法 |
+| F7  | **Sprint 均衡度** | Sprint 工作量方差 > 均值 50% → 不均衡警告                             |
+
+
+**严重度规则**: F1 > 16h → HIGH。F3 链 > 7 → HIGH。F5 仅信息 → LOW。
+
+---
+
+### Pass G: 契约覆盖检测 (Contract Coverage)
+
+**目标**: 确保公共契约与基础单测责任没有漏口。
+
+
+| #   | 检查项              | 如何检查                                                                                       |
+| --- | ---------------- | ------------------------------------------------------------------------------------------ |
+| G1  | **公共契约无实现承接**    | Contract Inventory 中的公共契约在 Tasks 中找不到对应实现任务。                                               |
+| G2  | **公共契约无验证承接**    | 契约有实现任务，但没有明确验证类型/验证说明/INT 承接。                                                             |
+| G3  | **高风险契约缺错误路径验证** | API / CLI / 配置 / 文件格式等契约没有失败态、边界态验证责任。                                                     |
+| G4  | **基础逻辑缺单测承接**    | registry / manifest / parser / schema / diff / merge / normalizer / planner 等基础逻辑没有单元测试承接。 |
+| G5  | **契约与验证类型错配**    | 明显公共契约仅给模糊手动验证或验证层级明显不足。                                                                   |
+| G6  | **回归责任缺失**       | 变更影响既有关键契约，但任务中无最小回归验证。                                                                    |
+
+
+**严重度规则**: G1 在 P0 或核心契约上 → CRITICAL。G2/G3/G6 → HIGH。G4 共享基础逻辑缺单测 → HIGH。G5 → MEDIUM。
+
+> [!IMPORTANT]
+> **如果任务声明了 `契约承接`，但在 `SYSTEM_DESIGN/*.md` / ADR / Architecture 中找不到对应契约来源，应优先报告为设计证据缺口，而不是默认视作任务正确。**
+
+---
+
+## 输出格式：任务审查报告
+
+按以下结构生成报告：
+
+```markdown
+## 任务审查报告
+
+> **审查文件**: .prismx/arch/v{N}/TASKS.md
+> **对照文档**: PRD.md, ARCHITECTURE.md, ADR/*, SYSTEM_DESIGN/*
+> **日期**: {YYYY-MM-DD}
+
+---
+
+### 检测摘要
+
+| Pass | 检测项数 | CRITICAL | HIGH | MEDIUM | LOW |
+|------|:-------:|:--------:|:----:|:------:|:---:|
+| A 重复检测 | — | — | — | — | — |
+| B 歧义检测 | — | — | — | — | — |
+| C 欠详述检测 | — | — | — | — | — |
+| D 不一致性检测 | — | — | — | — | — |
+| E 覆盖率检测 | — | — | — | — | — |
+| F 质量粒度 | — | — | — | — | — |
+| G 契约覆盖 | — | — | — | — | — |
+| **合计** | **—** | **—** | **—** | **—** | **—** |
+
+**整体健康度**:  健康 /  需关注 /  阻塞
+
+**高信号结论**: [用 1-3 句概括最值得进入 challenge 主报告的问题]
+
+---
+
+### REQ 覆盖率
+
+| REQ-ID | 标题 | 优先级 | 关联任务 | 状态 |
+|--------|------|:------:|---------|:----:|
+| REQ-001 | ... | P0 | T2.1.1, T2.1.2 |  |
+| REQ-003 | ... | P0 | — |  GAP |
+
+**覆盖率**: {已覆盖}/{总数} ({百分比}%)
+
+---
+
+### User Story 完整性
+
+| US-ID | 标题 | 涉及系统 | 关联任务 | 独立可测 | 状态 |
+|-------|------|---------|---------|:--------:|:----:|
+| US-001 | ... | core, client | T2.1.1→T7.2.1 |  |  |
+| US-003 | ... | core, executor | T3.2.1 (不完整) |  |  |
+
+---
+
+### 术语一致性
+
+| 术语 | PRD 中 | Architecture 中 | Tasks 中 | 状态 |
+|------|--------|----------------|---------|:----:|
+| ... | "..." | "..." | "..." |  漂移 |
+
+---
+
+### 契约覆盖率
+
+| 契约 | 类型 | 实现承接 | 验证承接 | 状态 |
+|------|------|---------|---------|:----:|
+| `update --target` 显式选择语义 | CLI | T1.2.1 | T6.2.1 |  |
+| install-lock fallback 重建语义 | 状态/文件格式 | T4.1.1 | T6.2.1 |  |
+| adapter target matrix 映射 | 基础规则层 | T2.1.1 | T6.1.1 |  |
+
+**设计证据来源**: 已读取 / 未读取 `SYSTEM_DESIGN/`*
+
+---
+
+### 关键路径
+
+> 最长依赖链，高亮瓶颈任务。
+
+```mermaid
+graph LR
+  T1.1.1 --> T2.1.1 --> T2.1.2 --> T4.1.1:::bottleneck --> T6.1.1
+  classDef bottleneck fill:#f96,stroke:#333
+```
+
+---
+
+### 核心发现清单
+
+
+| ID    | 严重度      | Pass | 位置                         | 发现                | 影响        | 建议                   |
+| ----- | -------- | ---- | -------------------------- | ----------------- | --------- | -------------------- |
+| TR-01 | CRITICAL | E1   | REQ-003 / TASKS.md §X   | P0 需求无对应任务        | 核心能力无法落地  | 在对应 Sprint 增加实现与验证任务 |
+| TR-02 | HIGH     | B1   | T4.1.3                     | 验收标准使用“正确处理”等模糊措辞 | 任务不可验证    | 量化错误码、兜底行为和验证方式      |
+| TR-03 | HIGH     | D1   | PRD / Architecture / Tasks | 术语漂移导致任务引用不一致     | 实施与对齐成本上升 | 按 ADR 统一术语           |
+
+
+> 仅输出真正影响执行和验收的问题。低价值措辞润色不要淹没核心发现。
+
+---
+
+### Top Findings 详情（仅展开 Critical / High）
+
+#### TR-01 [标题]
+
+**Pass**: E1  
+**严重度**: CRITICAL  
+**位置**: [REQ-ID / Task ID / 文档章节]
+
+**证据**:
+
+- 需求来源: [PRD 中的 REQ / US]
+- 任务映射: [哪些任务缺失 / 不完整]
+- 交叉验证: [与 Architecture / ADR 的不一致点，如适用]
+
+**影响**:
+
+- [不修复会导致什么执行或交付问题]
+
+**建议**:
+
+- [最小修复方向]
+
+---
+
+### 溢出摘要（发现 > 50 条时）
+
+{N} 条额外发现被省略。主要类别: ...
+
+```
+
+---
+
+## 严重度分级
+
+| 等级 | 判定标准 | 所需行动 |
+|:----:|---------|---------|
+| **Critical**  | 根本性矛盾或不可能实现。不解决无法继续。 | P0 — 必须在 blueprint/forge 之前修复 |
+| **High**  | 大概率导致返工或失败的严重风险。 | P1 — 在 forge 之前修复 |
+| **Medium**  | 有变通方案的质量隐患。 | P2 — 实现阶段修复 |
+| **Low**  | 润色项或轻微不一致。 | P3 — 后续跟踪 |
+
+**健康度规则**: Critical ≥ 1 → 整体健康度设为  阻塞。High ≥ 5 →  需关注。其余 →  健康。
+
+> [!NOTE]
+> 输出时优先保留 Critical / High。Medium / Low 仅在确实影响执行判断或有稳定改进价值时保留。
+
+---
+
+## 审查要诀
+
+1. **不要过度标记**: 如果任务虽措辞不完美但意思明确，最多标 LOW。
+2. **上下文很重要**: 游戏 Tick 循环里的"快速"和批处理任务里的"快速"含义截然不同。
+3. **架构感知**: 用 `ARCHITECTURE.md` 的系统边界验证任务范围。
+4. **尊重 ADR**: 如果 ADR 明确选择了某个权衡并有文档记录，不要重新翻旧账。
+5. **增量价值**: 哪怕只找到 3 条 CRITICAL，审查就物有所值。完美不是目标。
+```
+

package/skills/task-skill-router/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: task-skill-router
+description: >
+  Classifies tasks by weight and maps to installed skills via skill-routing-matrix.json.
+  Default UX is Execution Intent + Confirm (session-start.md). Full Skill Plan table only
+  when user chooses plan_first, asks for a plan, or maintainer runs prismx route --verbose.
+---
+
+# Task Skill Router
+
+## When to trigger
+
+- User chose **`plan_first`** in Confirm step
+- User says: `skill plan`, `hangi skill`, `which skill`, `önce plan`, `plan_first`
+- Maintainer runs `prismx route --verbose` (CLI parity)
+- **Multi-item** backlog work needing visible breakdown before approval
+
+**Skip** (silent `prismx-skill-gateway` + Execution Intent only) when:
+
+- User chose **`apply_now`** or **`analyze_only`**
+- Single **light** subtask with clear scope
+- User says "just do it" / "hemen uygula"
+
+## Classification algorithm (mandatory order)
+
+1. **Split** compound requests into subtasks
+2. For each subtask, evaluate **heavy → medium → light** using [`.prismx/AGENT.md` Complexity Router](AGENT.md) and [`.prismx/skill-routing-matrix.json`](../skill-routing-matrix.json)
+3. **Heavy** if any: new module, ~10+ files, architecture decision, schema design, 3rd-party integration
+4. **Medium** if any: 3+ files, new endpoint/route, migration, security domain, ambiguous scope
+5. **Light** only if ALL: 1–3 files, no security/architecture, clear scope
+6. **Default when unsure:** medium (never under-classify)
+7. **Overall weight** = `max(subtasks)`; **2+ subtasks** → overall min medium
+
+### Evidence signals (quick scan before classifying)
+
+| Signal | How | Effect |
+|--------|-----|--------|
+| `estimated_files` | TODO count, grep, user list | ≥10 heavy, ≥3 medium |
+| `security_keywords` | matrix `classification.security_keywords` | min medium |
+| `task_type` | keyword match in matrix | default weight + skills |
+| `rules_domain` | task touches `rules/testing.md` etc. | see matrix `rules_domain_map` |
+| `ambiguity` | 2+ valid interpretations | min medium → consider `prompt-enhancer` first |
+| `resolver_order` | matrix precedence list | provider tie-break / fallback order |
+| `rules_domain_map.weight_min` | per-domain minimum weight | prevent weak domain false positives |
+
+Always fill **Reason** column with concrete evidence when producing a table.
+
+## Skill matching
+
+1. Load [`.prismx/registry.json`](../registry.json) — only suggest **installed** skills
+2. Match subtask keywords → `skill-routing-matrix.json` → `task_types`
+3. If task touches a domain in `./rules/` → add skills from `rules_domain_map`
+4. Missing skill → fallback from gateway + `prismx skill add <name>`
+
+## Default output (most tasks) — Execution Intent
+
+Per `session-start.md` and `GUNLUK.md`:
+
+```
+Intent: ...
+Capability: ...
+Resolution: ...
+Memory: ...
+Plan: ...
+Confirm: ...
+Options: apply_now | plan_first | analyze_only
+```
+
+Do **not** emit a Skill Plan table unless user chose `plan_first` or explicitly asked.
+
+## Skill Plan table (plan_first / verbose only)
+
+```markdown
+## Skill Plan
+
+**Request:** <user text>
+**Overall weight:** 🟡 Medium | 🔴 Heavy
+
+| # | Subtask | Weight | Reason | Primary skill(s) | Workflow | Status |
+|---|---------|--------|--------|------------------|----------|--------|
+| 1 | … | 🟡 | … | … | /forge | installed |
+
+**Suggested order:** …
+**Rules to read:** rules/testing.md (if applicable)
+```
+
+Wait for user approval before implementing 🟡/🔴 subtasks (unless emergency hotfix).
+
+## After approval
+
+1. Read each primary skill's `SKILL.md`
+2. Read relevant `./rules/*.md` + `.prismx/rules/engineering-*.md`
+3. Execute via `prismx-skill-gateway` silently for implementation
+4. Update `.prismx/CURRENT_TASK.md` and HANDOFF at session end
+
+## CLI parity
+
+- `prismx route "<task>"` — Execution Intent + Confirm (default)
+- `prismx route --verbose "<task>"` — Skill Plan table (debug)
+
+## Integration with modular rules
+
+If root `AGENTS.md` has a **Rules index** table, include matching `rules/*.md` under **Rules to read** when producing a Skill Plan table.
+
+Global `.prismx/rules/engineering-*` always apply for coding tasks; never weakened by project `rules/`.

package/skills/tech-evaluator/SKILL.md

@@ -0,0 +1,181 @@
+---
+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 分)。你可以使用 `.prismx/skills/tech-evaluator/scripts/evaluate_matrix.py` 进行自动加权打分和 Benchmark 解析比对。
+配置 JSON (`matrix_config.json`) 示例如下:
+```json
+{
+  "dimensions": {
+    "需求匹配": 5,
+    "扩展性": 3,
+    "性能": 4,
+    "安全性": 4,
+    "团队技能": 5,
+    "开发速度": 5,
+    "TCO (总成本)": 3,
+    "社区生态": 4
+  },
+  "candidates": [
+    {
+      "name": "FastAPI (Python)",
+      "pros": ["开发速度极快", "生态丰富"],
+      "cons": ["CPU密集型场景性能一般"],
+      "scores": {
+        "需求匹配": 5,
+        "扩展性": 4,
+        "安全性": 4,
+        "团队技能": 5,
+        "开发速度": 5,
+        "TCO (总成本)": 5,
+        "社区生态": 5
+      },
+      "benchmark_log": "fastapi_bench.log"
+    }
+  ]
+}
+```
+运行命令:
+```bash
+python .prismx/skills/tech-evaluator/scripts/evaluate_matrix.py matrix_config.json .prismx/arch/v1/ADR/ADR-001_TECH_STACK.md
+```
+评分维度表:
+
+
+| 维度            | 权重建议 | 评估问题            |
+| ------------- | ---- | --------------- |
+| **需求匹配**      | —    | 能否实现所有核心功能？     |
+| **扩展性**       | —    | 能否支撑 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`，并将其写入 `.prismx/arch/v{N}/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 技术雷达参考
+- `scripts/evaluate_matrix.py`: 决策矩阵与 Benchmark 自动评估解析脚本
+