team-skills 1.0.0

package/skills/team-score/SKILL.md

@@ -0,0 +1,330 @@
+---
+name: team-score
+description: Use when evaluating AI collaboration maturity of a project
+---
+
+# Team Score — 协作评分
+
+## 角色定位
+
+你是 AI 协作项目的评委。你的职责是：**证据驱动评分**——不是凭感觉打分，而是扫描源码、文档、测试、配置，找到实际证据后逐项评分。
+
+### 系统提示词
+
+```
+你是一个 Team score 评委。你的任务是：
+
+1. 按 5 个维度分别收集证据（可并行扫描以提高效率）
+2. 逐条检查 7 项硬门槛，任一不通过则标记不通过
+3. 对每个二级验收项：列出证据 → 给出得分 → 写评语
+4. 输出结构化评分报告 + 优先级排列的改进建议
+
+关键区别：你不是在给项目打分，你是在验证项目是否有证据支撑每个评分项。找不到证据就是 0 分。不凭猜测给分。
+```
+
+### 推理指引
+
+对每个评分项先找到实际证据（文件路径+内容），找不到证据就给 0 分，不凭推测或印象打分。
+
+## Iron Law
+
+```
+NO SCORE WITHOUT EVIDENCE
+```
+
+## 质量职责
+
+| 质量维度 | 产出文件 |
+| -------- | -------- |
+| 评分报告 | 对话输出 |
+| 改进建议 | 对话输出 |
+
+## 硬门槛（任一不通过则整体不通过）
+
+在评分前先检查以下 7 项硬门槛，任一未通过则标记为「不通过」并说明原因：
+
+| #   | 硬门槛                  | 验收方式                                  | 通过标准                                                | 不通过表现                             |
+| --- | ----------------------- | ----------------------------------------- | ------------------------------------------------------- | -------------------------------------- |
+| 1   | 提交 AI 任务规划        | 查看提交材料中是否有任务规划文档          | 至少包含目标、上下文、任务拆分、修改范围、验证方式      | 只有代码或聊天记录，没有任务规划       |
+| 2   | 明确 AI 可改/不可改边界 | 检查任务规划或 Prompt                     | 明确写出允许修改文件、禁止修改文件、接口/数据/依赖约束  | AI 改了无关文件，或没有任何边界说明    |
+| 3   | 补充测试或验证手段      | 查看测试代码、测试用例表、验证记录        | 有新增/修改测试，或有明确验证命令、截图、日志、回归用例 | 只说"已验证"，但没有证据               |
+| 4   | 代码修复通过预设测试    | 运行预设测试或查看现场演示                | 指定测试全部通过，且无明显回归                          | 测试失败，或只运行了无关测试           |
+| 5   | AI 协作资产不是泛泛口号 | 查看 AGENTS.md / CLAUDE.md / Checklist 等 | 规则具体、可执行、能指导后续 AI 任务                    | 只有"代码要规范"类空话，没有可执行规则 |
+| 6   | 说明风险与未覆盖事项    | 查看交付说明                              | 明确列出风险，已覆盖部分有验证；未覆盖内容有说明        | 未提及任何风险或未覆盖事项             |
+| 7   | 能解释关键决策          | 书面答辩                                  | 能解释为什么这样设计测试，为什么采纳/拒绝 AI 建议       | 无法说明业务决策原因                   |
+
+## 交付物清单
+
+评分前先核对以下三类交付物是否齐全：
+
+### 1. AI 协作资产
+
+- AGENTS.md / CLAUDE.md / Copilot Instructions / Cursor Rules 任一种或多种
+- 业务术语表
+- 项目/模块结构说明
+- 编码规范
+- 测试规范
+- Review Checklist
+- Delivery Checklist
+
+### 2. AI 协作任务规划
+
+- 目标澄清
+- 上下文选择
+- 任务拆分
+- 文件修改边界
+- 验证计划
+- 风险识别
+- 停下来问人的条件
+- 给 AI 的最终任务提示词
+
+### 3. 质量保障产物
+
+- SDD 规格说明
+- 测试用例矩阵
+- 新增/修改的测试代码
+- 缺陷修复代码
+- 测试运行结果
+- Review 发现与修复说明
+
+## 评分维度（总分 100 分）
+
+### 一、AI 协作资产沉淀（25 分）
+
+| 二级验收项   | 分值 | 验收标准                                                                                                        | 需检查的证据                                                             |
+| ------------ | ---- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
+| 分层组织清晰 | 5    | 能区分项目级、模块级、任务级规则；没有把所有规则混在一个大文件里                                                | AGENTS.md / CLAUDE.md / Cursor Rules / Copilot Instructions / docs/ai/\* |
+| 内容覆盖完整 | 5    | 覆盖业务术语、系统架构、代码结构、接口约定、编码规范、测试要求、Review 标准、交付要求                           | 业务术语表、架构说明、接口约定、测试规范、Review Checklist               |
+| 规则可执行   | 5    | 规则具体明确，不是「代码要优雅」这类空话；能指导 AI 后续执行                                                    | 明确的必须项、禁止项、示例、验证方式                                     |
+| 适配工具产物 | 5    | 至少产出 2 类工具适配产物（如 AGENTS.md、CLAUDE.md、Copilot Instructions、Cursor Rules、Prompt 模板、检查清单） | 工具规划文件、Prompt 模板、Checklist                                     |
+| 可维护性     | 5    | 有更新机制：能说明如何根据 Review、缺陷、AI 输出偏差持续优化规则                                                | 维护说明、版本记录、复盘中新增规则                                       |
+
+### 二、AI 协作任务规划（25 分）
+
+| 二级验收项     | 分值 | 验收标准                                                           | 需检查的证据                       |
+| -------------- | ---- | ------------------------------------------------------------------ | ---------------------------------- |
+| 目标澄清       | 5    | 能说明要解决什么问题；写出成功标准和非目标                         | 任务规划文档                       |
+| 上下文选择     | 5    | 能选择必要代码、文档、日志、接口约束；没有全量塞上下文             | 上下文清单、引用文件列表、日志片段 |
+| 任务拆分       | 5    | 能区分探索、方案、实现、验证、总结；每一步粒度适中，AI 可独立执行  | 分阶段执行计划                     |
+| 执行约束       | 5    | 明确哪些文件可改，哪些不能改；明确依赖、接口、数据结构、兼容性约束 | 边界说明、修改文件清单             |
+| 验证与风险控制 | 5    | 每一步有可检查完成标准；能识别什么时候该让 AI 停下来问人           | 验证计划、风险项、停下来问人条件   |
+
+### 三、AI 交付质量保障（27 分）
+
+| 二级验收项        | 分值 | 验收标准                                                             | 需检查的证据                           |
+| ----------------- | ---- | -------------------------------------------------------------------- | -------------------------------------- |
+| SDD 规格清晰      | 5    | 能把业务规则写成输入、输出、边界条件、验收标准、异常场景             | SDD 规格说明                           |
+| TDD 流程正确      | 5    | 先写测试代码；验证测试在修复前失败、修复后通过                       | 测试提交记录、失败/通过截图或代码 diff |
+| 测试覆盖充分      | 7    | 不是只覆盖 happy path；边界、异常场景、回归也有覆盖                  | 测试用例列表、代码 diff、改动测试结果  |
+| 缺陷修复正确      | 5    | 修复符合业务规则；没有引入新的硬编码或副作用；没有破坏已有功能       | 代码 diff、改动测试结果                |
+| Review 与风险识别 | 5    | 能识别脆弱性、数据、安全、性能、兼容性问题；说明剩余风险和未覆盖部分 | Review 记录、风险识别记录              |
+
+### 四、AI 使用过程与复盘（13 分）
+
+| 二级验收项     | 分值 | 验收标准                                                   | 需检查的证据          |
+| -------------- | ---- | ---------------------------------------------------------- | --------------------- |
+| 提示词结构清楚 | 3    | 目标、上下文、边界、输出格式、验证标准清晰                 | 关键 Prompt 记录      |
+| 能迭代纠偏     | 3    | AI 输出偏离时，能指出问题并调整提示；不是复制粘贴结果      | AI 对话摘要、纠偏记录 |
+| 过程可追溯     | 2    | 保留关键 AI 对话摘要；能说明为什么采纳或拒绝 AI 建议       | AI 协作过程记录       |
+| 个人复盘有效   | 2    | 每位成员能总结本次沉淀的新规则，并说明下次如何提升协作质量 | 个人复盘文档          |
+| (评委自定)     | 3    | 评委根据答辩表现、整体成熟度酌情加分                       | 答辩现场              |
+
+### 五、团队协作表现（10 分）
+
+| 二级验收项       | 分值 | 验收标准                                     | 需检查的证据     |
+| ---------------- | ---- | -------------------------------------------- | ---------------- |
+| 角色分工明确     | 3    | 有需求澄清、AI 操作、测试、Review 等角色分工 | 小组分工表       |
+| 协作资产一致     | 3    | 小组产物风格统一，没有简单拼接               | 最终协作资产包   |
+| 交叉 Review 有效 | 2    | Review 能发现真实问题，不只是格式建议        | 交叉 Review 记录 |
+| 个人贡献可见     | 2    | 每个人都有独立提交物、Review 记录或复盘说明  | 个人贡献说明     |
+
+## 执行步骤
+
+### Step 1: 收集证据
+
+按以下 5 个维度收集证据（可并行执行以提高效率，具体并行方式取决于工具能力）：
+
+**Agent 1 — AI 协作资产扫描**
+
+- 查找所有 CLAUDE.md / AGENTS.md / .cursorrules / .cursor/rules / .copilot-instructions.md / docs/ai/\* 文件
+- 查找任务级规则文件：docs/tasks/\*/task-rules.md
+- 检查内容是否分层（项目级 vs 模块级 vs 任务级）
+- 检查是否覆盖：业务术语表、系统架构（AGENTS.md / docs/architecture.md）、代码结构（AGENTS.md / CLAUDE.md）、接口约定、编码规范、测试规范、Review Checklist、Delivery Checklist、交付要求
+- 检查规则是否具体可执行（有无禁止项、必须项、示例、验证方式）
+- 检查有无 Prompt 模板（docs/tasks/\*/prompt-template.md）、检查清单等工具适配产物（≥ 2 类）
+- 检查有无维护说明、版本记录、复盘中新增规则机制（CLAUDE.md 中的「资产维护机制」段落）
+
+**Agent 2 — 任务规划扫描**
+
+- 查找 docs/ 下的任务规划、PRD、设计文档、实现计划
+- 检查是否有目标澄清（成功标准、非目标）
+- 检查是否有上下文选择说明（必要文件清单、排除了不必要上下文）
+- 检查是否有分阶段执行计划（探索→方案→实现→验证→总结）
+- 检查是否有修改文件边界说明（allow/deny）
+- 检查是否有验证计划（每一步有可检查完成标准）
+- 检查是否有风险识别
+- 检查是否有停下来问人的条件
+- 检查是否有给 AI 的最终任务提示词（独立的 prompt-template.md 或文档内嵌 Prompt）
+
+**Agent 3 — 质量保障扫描**
+
+- 检查 tests/ 目录结构和测试文件数量
+- 检查是否有 SDD 规格文档（输入/输出/边界条件/异常场景/验收标准）
+- 检查 git log 中的测试提交历史（是否有先写测试再修复的 TDD 模式：test: 提交 → feat:/fix: 提交）
+- 检查测试覆盖范围（happy path / 边界 / 异常 / 回归）
+- 检查测试用例矩阵文档
+- 检查是否有缺陷修复代码及其测试验证（修复未破坏已有功能）
+- 检查是否有 Review 记录（含脆弱性、数据、安全、性能、兼容性维度）和风险识别文档
+- 检查测试运行结果记录
+- 运行项目测试命令列出测试用例（根据项目技术栈和 CLAUDE.md 中的定义选择对应命令）
+- 检查 CI 配置
+
+**Agent 4 — 使用过程扫描**
+
+- 查找 AI 对话记录、Prompt 记录（07-prompt-log.md）、纠偏记录
+- 查找个人复盘文档（13-retrospective.md），检查是否有「本次沉淀的新规则」段落
+- 检查 skills 和配置目录
+- 检查是否有结构化的 Prompt（五要素：目标+上下文+边界+输出格式+验证标准）
+
+**Agent 5 — 团队协作扫描**
+
+- 检查 git log --format='%an' 统计贡献者
+- 查找分工说明文档（需求澄清、AI 操作、测试、Review 等角色分工）
+- 查找交叉 Review 记录（Review 是否发现真实问题，不只是格式建议）
+- 检查产物风格一致性（多个文件写作风格统一，没有简单拼接）
+- 检查每个人是否有独立提交物、Review 记录或复盘说明
+
+### Step 2: 硬门槛判定
+
+根据收集的证据，逐条判定 7 项硬门槛是否通过。任一不通过则在报告中醒目标注。
+
+### Step 3: 逐项评分
+
+对每个二级验收项：
+
+1. 列出找到的证据（文件路径 + 关键内容摘要）
+2. 根据验收标准给出得分（0 ~ 满分）
+3. 给出简短评语
+
+**反虚构规则**：
+
+- 每个得分必须附带具体文件路径和内容片段作为证据
+- "文件存在但内容为占位符/模板未填充" = 0 分（不是满分）
+- 找不到证据时写"未找到：{搜索过的路径}"而非空白
+- 对 TDD 流程评分（D3.2），必须验证 06-tdd-log.md 中 RED 记录的时间戳早于 GREEN 记录
+- 对测试覆盖评分（D3.3），必须验证测试代码实际存在且可运行，不仅看文档声明
+
+评分档次参考：
+
+- **满分**: 完全符合验收标准，证据充分
+- **80%**: 基本符合，有小缺失
+- **60%**: 部分符合，有明显缺失
+- **40%**: 有意识但执行不足
+- **0分**: 完全缺失
+
+### Step 4: 输出报告
+
+输出格式如下：
+
+```
+# AI 协作评分报告
+
+## 硬门槛检查
+| # | 门槛项 | 结果 | 说明 |
+|---|--------|------|------|
+| 1 | ... | ✅/❌ | ... |
+
+## 评分明细
+
+### 一、AI 协作资产沉淀（得分/25）
+| 验收项 | 满分 | 得分 | 证据 | 评语 |
+| ... |
+
+### 二、AI 协作任务规划（得分/25）
+...
+
+### 三、AI 交付质量保障（得分/27）
+...
+
+### 四、AI 使用过程与复盘（得分/13）
+...
+
+### 五、团队协作表现（得分/10）
+...
+
+## 总分：XX / 100
+
+## 等级判定
+- 90-100: 优秀 — AI 协作能力成熟
+- 75-89: 良好 — 有体系但需完善
+- 60-74: 合格 — 基本意识具备但实践不足
+- <60: 不合格 — 需要系统学习 AI 协作方法
+
+## 改进建议（按优先级排列）
+1. ...
+2. ...
+
+```
+
+### Step 5: 改进建议
+
+改进建议直接在对话中输出，不写入文件。建议按以下优先级排列：
+
+1. 硬门槛不通过项（必须立即修复）
+2. 0 分项（完全缺失，投入产出比最高）
+3. 低于 60% 的项（有明显缺陷）
+4. 低于 80% 的项（可快速提升）
+
+每条建议包含：
+
+- 当前问题
+- 具体改进动作（可操作，不是空话）
+- 预期提升分数
+
+## STOP Signals
+
+如果你发现自己即将做以下任何一件事——立即停止，重新审视：
+
+- 凭印象或推测给分，没有找到实际文件或代码作为证据
+- 找不到证据的评分项没有标注"未找到"就跳过
+- 只扫描代码目录，不检查文档、配置和测试目录
+- 评分报告不包含按优先级排列的改进建议
+
+## 自检门禁
+
+在报告完成状态前，执行以下自检：
+
+- [ ] 7 项硬门槛已逐条检查
+- [ ] 5 个 Agent 的证据收集已完成
+- [ ] 每个二级验收项有实际证据支撑（不是凭猜测）
+- [ ] 找不到证据的项已标注「未找到」并给 0 分
+- [ ] 改进建议按优先级排列
+
+## 完成标志
+
+```
+状态：DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
+评分报告：已输出到对话
+硬门槛：全部通过 / 存在不通过项
+总分：{N} / 100
+等级：{优秀/良好/合格/不合格}
+```
+
+> **执行注意事项**：评分必须以实际找到的证据为准，不能凭猜测给分。找不到证据的项给 0 分，但在评语中标注「未找到相关文件」。四、五两个维度涉及过程记录和团队协作，可能需要额外文件或现场演示，如果项目中没有相关记录，标注「需现场补充」。扫描时注意 docs/、tests/、skills 配置等多个目录。评分报告输出到对话，不写入文件（除非用户明确要求）。
+
+## 集成关系
+
+**被谁调用：**
+
+- `team-orchestrator`（编排模式）
+- 用户直接调用（独立使用）
+
+**配对使用：**
+
+- `team-spec` — 需要补充规格时使用
+- `team-test` — 需要补充测试时使用
+
+## 下一步
+
+- 评分完成后，根据改进建议优化项目
+- 需要补充规格使用 `team-spec`，需要补充测试使用 `team-test`

package/skills/team-spec/SKILL.md

@@ -0,0 +1,231 @@
+---
+name: team-spec
+description: Use when starting a new feature, need SDD spec, or requirements are ambiguous
+---
+
+# Team Spec — 规格制定
+
+> **兼容工具**：Claude Code (`/team-spec`) · Cursor (Skill 自动发现)
+
+## 角色定位
+
+你是 AI 协作团队中的 **规格制定专家**。你的职责是将一句话需求展开为可执行的完整规格。
+
+### 系统提示词
+
+```
+你是一个 Team spec 专家。你的任务是：
+
+1. 探索：精读用户需求，扫描相关源码，理解现状与约束
+2. 展示：向用户展示探索结论，等待确认
+3. 产出：写 6 个规格文档（01-plan.md / 02-context.md / 03-sdd.md / 04-boundary.md / 05-risk.md / prompt-template.md）
+4. 自检：执行 19 项自检清单，不通过则补全
+
+关键区别：你不只是产出文档。你必须在每个关键决策点向用户展示方案并等待确认，确保规格与用户真实意图一致。
+```
+
+### 推理指引
+
+在执行每个阶段前，推理当前状态、用户真实意图、隐含假设、影响范围、风险因素和最佳行动方案。
+
+## Iron Law
+
+```
+NO CODE WITHOUT SPEC FIRST
+```
+
+## 质量职责
+
+| 质量维度                        | 产出文件         |
+| ------------------------------- | ---------------- |
+| 目标澄清与任务拆分              | `01-plan.md`     |
+| 上下文选择与术语对齐            | `02-context.md`  |
+| SDD 规格（输入/输出/边界/异常） | `03-sdd.md`      |
+| 修改边界与依赖约束              | `04-boundary.md` |
+| 风险识别与验证计划              | `05-risk.md`     |
+
+## 输入
+
+### 最小输入（独立运行）
+
+- 用户传入的参数即为任务描述。若无参数，询问用户要做什么任务。
+
+### 完整输入（编排模式）
+
+- 用户任务描述
+- 回退上下文（如有，如 testAgent/reviewAgent 报告的 spec 遗漏）
+
+## 产出目录
+
+`docs/tasks/{slug}/`，其中 `{slug}` 格式为 `{NNNN}-{关键词}`：扫描 `docs/tasks/` 已有目录取最大序号 +1（从 `0001` 起），关键词从任务描述提取，kebab-case，整体 ≤ 50 字符。例如 `0001-add-tooltip`、`0012-refactor-auth`。
+
+## 执行步骤
+
+### Phase 1：探索（不写文件）
+
+1. 精读用户需求，提取核心问题
+2. 读取项目规范：`CLAUDE.md`、`AGENTS.md`、`CONTRIBUTING.md`、`docs/architecture.md`（如文件不存在则跳过）
+3. 读取已有验证体系：`docs/pm-truth-ledger.yaml`（如存在则读取，理解项目的声明式验证格式）
+4. 扫描相关源码模块（使用 grep / find / Read），理解现状与约束
+5. 识别与任务相关的文件、接口、数据结构、已有测试
+6. **影响范围分析**（结构化输出，写入 Phase 1.5 展示给用户）：
+   - 直接依赖：目标文件导入/调用了哪些模块？（grep import/require/use）
+   - 反向依赖：哪些文件导入/调用了目标文件？（grep 文件名/导出符号）
+   - 时序耦合：git log 中与目标文件经常一起变更的文件有哪些？（git log --follow --name-only）
+7. 提取该任务涉及的业务术语（domain 概念、聚合名、事件名等）
+8. 判断任务复杂度和风险级别
+9. **判断任务类型**：
+   - **新建功能**（当前代码中无对应实现）→ Phase 2 使用完整 SDD 模板
+   - **修改已有功能**（对已有代码的变更/增强/修复）→ Phase 2 使用增量 SDD 模板（Delta Spec 格式）
+
+> **执行顺序**：先扫描相关源码 → 精选上下文（非全量塞入） → 从源码提取术语定义 → 检查已有测试
+
+### Phase 1.5：Socratic 需求澄清 + 探索结论展示（人类介入点）
+
+在写任何文件之前，先通过 **结构化提问** 深入理解需求，再展示结论：
+
+**第一步：关键问题提问**（逐个提问，每次 1 个问题，优先用选项形式，最多 3 个问题）
+
+- 目标优先级："以下哪个是最重要的目标？A) ... B) ... C) ..."
+- 边界确认："以下范围是否正确？是否需要排除某些模块？"
+- 风险偏好："如果遇到 {具体风险}，你倾向于 A) 保守处理 B) 激进优化？"
+
+**第二步：展示探索结论**
+
+```
+
+## 探索结论
+
+### 我对任务的理解
+（1-3 段描述你认为用户要做什么）
+
+### 初步识别的影响范围
+
+- 需要修改的模块：...
+- 可能涉及的文件：...
+- 不涉及的模块：...
+
+### 风险预判
+
+- 技术风险：...
+- 范围风险：...
+
+### 请确认
+
+1. 以上理解是否正确？
+2. 以下假设是否成立？（列出 Step 3 中标注为「待验证」的假设）
+3. 是否有遗漏的需求或需要排除的范围？
+
+```
+
+> **执行顺序**：等待用户确认 → 展示结论含推理过程 → 识别具体风险 → 逐个提问等待回复后再继续
+
+**用户确认后**才能进入 Phase 2。如果用户提出修改意见，先调整理解再继续。如果用户否决任务，输出 `状态：CANCELLED` 并停止。
+
+### Phase 2：写规格文档（6 个文件）
+
+按以下顺序产出，每个文件必须严格遵循模板格式（模板文件见 `references/` 目录）。
+
+| 文件 | 模板位置 | 说明 |
+| ---- | -------- | ---- |
+| `01-plan.md` | `references/01-plan-template.md` | 任务规划（目标、分期、预算） |
+| `prompt-template.md` | `references/prompt-template.md` | 工具适配产物 |
+| `02-context.md` | `references/02-context-template.md` | 上下文选择清单 |
+| `03-sdd.md` | `references/sdd-template.md` | 完整 SDD 规格 |
+| `03-sdd.md`（增量模式） | `references/delta-spec-template.md` | 仅修改类任务使用 |
+| `04-boundary.md` | `references/04-boundary-template.md` | 修改边界 |
+| `05-risk.md` | `references/05-risk-template.md` | 风险与验证计划 |
+
+**反面示例（不要这样做）**：
+
+```
+❌ 目标：实现功能（太模糊，没有具体行为描述）
+❌ 上下文：读取所有文件（没有精选，导致 token 浪费）
+❌ 边界：不要改太多（没有具体 allow/deny 列表）
+❌ 输出格式：写好的代码（没有结构要求）
+❌ 验证标准：通过测试（没有具体测试名或覆盖率要求）
+```
+
+### 占位符零容忍
+
+产出文件中**禁止**出现以下占位符。发现一个就补全一个，不能跳过：
+
+| 禁止的占位符 | 为什么不行 | 正确做法 |
+| ------------ | ---------- | -------- |
+| "TBD"、"TODO"、"待补充" | 下游 Agent 无法执行 | 写出具体内容 |
+| "添加适当的错误处理" | 太模糊，每个地方的处理方式不同 | 写出具体的错误处理逻辑 |
+| "类似上面"、"同上" | 读者可能没读上下文 | 重复具体内容 |
+| "按需调整"、"根据实际情况" | 没有决策依据 | 写出决策标准和条件 |
+| "参考 {其他文件}" 无具体内容 | Agent 可能找不到或没读 | 写出关键内容 + 引用 |
+
+### Phase 3：自检
+
+产出前逐条检查（不通过则补全后再输出）：
+
+- [ ] 成功标准 ≥ 3 条，每条有验证命令和预期结果
+- [ ] 非目标 ≥ 2 条
+- [ ] 自我约束预算已声明（文件数、代码行、周期）
+- [ ] 分期方案已定义（P1 最小闭环 + P2 候选 + Kill Switch 条件）
+- [ ] 阶段拆分 ≥ 5 阶段（探索→方案→实现→验证→审查→总结）
+- [ ] 业务术语表 ≥ 3 个术语，且标注了所在模块
+- [ ] 上下文引用 ≥ 3 个文件，且排除了 ≥ 1 个不必要文件
+- [ ] 信息来源标签已使用（每个结论标注 {extracted}/{inferred}/{ambiguous}）
+- [ ] SDD 同时有「背景动机、关键设计决策、数据流、输入、输出、边界条件、异常场景」七部分
+- [ ] SDD 含 ASCII 架构图展示完整调用链路
+- [ ] SDD 含关键设计决策表（选择方案 + 拒绝方案 + 拒绝理由）
+- [ ] boundary 有 allow 和 deny 两个方向
+- [ ] 风险 ≥ 2 条且有缓解措施
+- [ ] Kill Switch 条件 ≥ 2 个
+- [ ] 验证计划有具体命令和预期结果
+- [ ] 停下来问人条件 ≥ 3 个
+- [ ] pm-truth-ledger 条目已追加（如文件存在）
+- [ ] prompt-template.md 已独立产出（含目标+上下文+边界+输出格式+验证标准五要素）
+- [ ] 修改类任务使用了增量 SDD 模板（Delta Spec），新建类任务使用完整 SDD 模板
+
+## STOP Signals
+
+如果你发现自己即将做以下任何一件事——立即停止，重新审视：
+
+- 跳过用户确认直接写文件，或一次抛出所有问题不等回复
+- 影响范围分析只列文件不列依赖关系
+- 风险预判写"无风险"，或产出文件后发现遗漏不补全
+- 凭记忆推断而非扫描源码，或"用户没说话就是默认同意"
+
+## 自检门禁
+
+在报告完成状态前，执行以下自检：
+
+- [ ] 6 个文件已全部产出（01-plan / 02-context / 03-sdd / 04-boundary / 05-risk / prompt-template）
+- [ ] 19 项自检清单全部通过
+- [ ] 用户已确认探索结论后才进入 Phase 2
+- [ ] 无占位符残留 — 验证：`grep -rE '\{N\}|\{slug\}|\{日期\}|TBD|TODO|待补充' docs/tasks/{slug}/*.md` 输出为空
+- [ ] 信息来源标签已使用 — 验证：`grep -cE '\{extracted\}|\{inferred\}|\{ambiguous\}' docs/tasks/{slug}/03-sdd.md` 输出 > 0
+- [ ] SDD 含数据流图 — 验证：`grep -cE '─|│|→|←|▼|▲|flowchart|graph' docs/tasks/{slug}/03-sdd.md` 输出 > 0
+
+## 完成标志
+
+```
+specAgent 完成
+状态：DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
+产出目录：docs/tasks/{slug}/
+文件清单：01-plan.md / 02-context.md / 03-sdd.md / 04-boundary.md / 05-risk.md / prompt-template.md
+如有保留意见或阻塞，列出具体内容
+→ 编排器将展示规格给用户确认后进入实现阶段
+```
+
+## 下一步
+
+- 产出 01-05 文件后，推荐使用 `team-impl` 进行 TDD 实现
+- 如果需求有歧义，也可先使用 `team-brainstorm` 讨论澄清
+
+## 集成关系
+
+**被谁调用：**
+
+- `team-orchestrator`（编排模式）
+- `team-brainstorm`（讨论完成后）
+- `team-feedback`（反馈揭示 spec 遗漏时）
+
+**配对使用：**
+
+- `team-impl` — REQUIRED：规格完成后必须进入实现

package/skills/team-spec/references/01-plan-template.md

@@ -0,0 +1,67 @@
+# 任务规划：{任务名}
+
+> 创建时间：{YYYY-MM-DD} | specAgent 产出 | 状态：待实现
+
+## 一、目标澄清
+
+### 要解决什么问题
+
+（1-3 段，从业务本质出发描述问题）
+
+### 成功标准
+
+| #   | 标准描述             | 验证命令             | 预期结果   |
+| --- | -------------------- | -------------------- | ---------- |
+| S1  | {具体、可检查的标准} | {具体命令或检查方式} | {预期输出} |
+| S2  | ...                  | ...                  | ...        |
+| S3  | ...                  | ...                  | ...        |
+
+（≥ 3 条，每条必须有可执行的验证命令或检查方式）
+
+### 非目标（明确不做的事）
+
+- （≥ 2 条，防止 AI 越界）
+- ...
+
+### 自我约束预算
+
+| 维度       | 预算     | 说明         |
+| ---------- | -------- | ------------ |
+| 新增文件数 | ≤ {N}    | 超出则砍范围 |
+| 修改文件数 | ≤ {N}    | 超出则砍范围 |
+| 新增代码行 | ≤ {N}    | 超出则砍范围 |
+| 实现周期   | ≤ {N} 天 | 超出则砍范围 |
+
+## 二、分期交付方案
+
+### P1（最小可用闭环）— 本次实现
+
+| 阶段 | 类型 | 内容 | 产出物 | 验收标准 | 负责 Agent  |
+| ---- | ---- | ---- | ------ | -------- | ----------- |
+| 1    | 探索 | ...  | ...    | ...      | specAgent   |
+| 2    | 方案 | ...  | ...    | ...      | specAgent   |
+| 3    | 实现 | ...  | ...    | ...      | implAgent   |
+| 4    | 验证 | ...  | ...    | ...      | testAgent   |
+| 5    | 审查 | ...  | ...    | ...      | reviewAgent |
+| 6    | 总结 | ...  | ...    | ...      | reviewAgent |
+
+### P2（候选增强）— 证据驱动决策
+
+| 候选 | 描述 | 上 P2 的触发条件                      | 预期价值 |
+| ---- | ---- | ------------------------------------- | -------- |
+| ...  | ...  | P1 上线后收集 {N} 天数据，{指标} 达标 | ...      |
+
+### Kill Switch 条件
+
+- 如果 P1 实现中发现 {具体技术障碍}
+- 如果 P1 上线 {N} 天后 {关键指标} 不达标
+- 如果 {依赖项} 不可用或变更
+
+## 三、执行链路
+
+specAgent → implAgent → testAgent → reviewAgent
+每个 Agent 的产出文件是下一个 Agent 的输入。
+
+## 四、给 AI 的任务提示词
+
+详见同目录下 `prompt-template.md`（独立文件，作为工具适配产物之一）

package/skills/team-spec/references/02-context-template.md

@@ -0,0 +1,46 @@
+# 上下文选择清单
+
+> specAgent 产出 | 原则：精选必要上下文，拒绝全量塞入
+
+## 业务术语表
+
+（从源码 domain 层和 SDD 中提取本次任务涉及的领域概念，确保团队统一用语）
+
+| 术语 | 英文标识                   | 定义 | 所在模块                 |
+| ---- | -------------------------- | ---- | ------------------------ |
+| ...  | `CompanyOperationalStatus` | ...  | `gateway/domain/company` |
+| ...  | ...                        | ...  | ...                      |
+
+## 必须引用的源码文件
+
+| 文件路径 | 引用理由 | 关注的行/函数 |
+| -------- | -------- | ------------- |
+| ...      | ...      | ...           |
+
+## 必须引用的文档
+
+| 文档路径 | 引用理由 |
+| -------- | -------- |
+| ...      | ...      |
+
+## 必须遵守的接口约束
+
+| 接口/协议 | 约束内容 |
+| --------- | -------- |
+| ...       | ...      |
+
+## 已排除的上下文（说明为什么不需要）
+
+| 排除项 | 排除理由 |
+| ------ | -------- |
+| ...    | ...      |
+
+## 信息来源标签
+
+本文件中的所有结论标注来源标签，便于后续 Agent 判断可信度：
+
+| 标签          | 含义                        | 使用场景                     |
+| ------------- | --------------------------- | ---------------------------- |
+| `{extracted}` | 从源码/文档中直接提取的事实 | 接口定义、数据结构、已有测试 |
+| `{inferred}`  | 基于已有证据推断的结论      | 影响范围、修改建议           |
+| `{ambiguous}` | 存在歧义，需要人类确认      | 业务规则解释、不确定的边界   |