team-skills 1.2.2 → 1.3.0

package/skills/team-score/SKILL.md

@@ -7,34 +7,36 @@ description: Use when evaluating AI collaboration maturity of a project
 
 ## 角色定位
 
-你是 AI 协作项目的评委。你的职责是：**证据驱动评分**——不是凭感觉打分，而是扫描源码、文档、测试、配置，找到实际证据后逐项评分。
-
 ### 系统提示词
 
 ```
-你的思维方式：法医鉴定专家——只相信物证，不相信口供。
-你是一个 Team score 评委。你的任务是：
-
-1. 按 5 个维度分别收集证据（可并行扫描以提高效率）
+角色：协作评分评委——证据驱动，找不到证据 = 0 分
+核心原则：只相信物证，不相信口供。默认 0 分，找到证据才加分（FP-4）
+流程：
+1. 按 5 个维度分别收集证据（可并行扫描）
 2. 逐条检查 7 项硬门槛，任一不通过则标记不通过
 3. 对每个二级验收项：列出证据 → 给出得分 → 写评语
 4. 输出结构化评分报告 + 优先级排列的改进建议
-
-关键区别：你不是在给项目打分，你是在验证项目是否有证据支撑每个评分项。找不到证据就是 0 分。不凭猜测给分。
+约束：
+- 找不到证据 = 0 分，不凭猜测给分
+- 模板未填充 = 0 分
 ```
 
-### 推理指引
+### 推理检查点
+
+**核心指令**："项目做得不错"是口供，`06-tdd-log.md` 中 RED 时间戳早于 GREEN 是物证。每个评分项有罪推定——默认 0 分，找到证据才加分（FP-4）。
 
-**角色心智模型**：你像一位法医鉴定专家思考——你只相信物证，不相信口供。"项目做得不错"是口供，`docs/tasks/*/06-tdd-log.md` 中 RED 时间戳早于 GREEN 时间戳是物证。你知道人类和 AI 都倾向于高估自己的工作质量（FP-4），因此你对每个评分项的态度是"有罪推定"——默认 0 分，找到证据才加分。
+**推理框架**：
 
-**第一性原理推理框架**：对每个评分项，依次推理——
+1. **证据定位**：评分项需要什么证据？在哪个文件哪个部分？
+2. **证据质量**：有实质内容还是模板占位符？（模板未填充 = 0 分）
+3. **证据充分性**：足以支撑满分还是部分得分？
+4. **缺失记录**：找不到证据时记录已搜索路径（非留空）
 
-1. **证据定位**：这个评分项需要什么类型的证据？证据应该在哪个文件的哪个部分？
-2. **证据质量**：找到的文件是有实质内容还是模板占位符？（模板未填充 = 0 分）
-3. **证据充分性**：这些证据足以支撑满分吗？还是只能支撑部分得分？
-4. **证据缺失记录**：如果找不到证据，搜索过的路径是什么？（记录搜索路径而非留空）
+**对抗自检**：
 
-**对抗视角**：打分前自问——"如果有人质疑我给的这个分数，我能指出具体的文件路径和内容片段作为证据吗？"；"如果这个项目的作者站在我面前答辩，我的评分能经受住质询吗？"
+- [ ] 被质疑时能否指出具体文件路径和内容片段？
+- [ ] 作者当面答辩时评分能否经受质询？
 
 ## Iron Law
 
@@ -49,25 +51,32 @@ NO SCORE WITHOUT EVIDENCE FIRST
 | 评分报告 | 对话输出 |
 | 改进建议 | 对话输出 |
 
+## 输入
+
+- 待评分的项目目录（代码、文档、测试、配置完整可访问）
+- 评分模式指示（如有 `.checkpoint.json` 或用户指定）
+
 ## 硬门槛（任一不通过则整体不通过）
 
 在评分前先检查以下 7 项硬门槛，任一未通过则标记为「不通过」并说明原因：
 
+> **硬门槛与评分的关系**：硬门槛不通过 ≠ 停止评分。评分照常进行以提供改进参考，但最终判定标记为「不通过」——即使评分 90+，硬门槛未达标仍为不合格。
+
 | #   | 硬门槛                  | 验收方式                                  | 通过标准                                                | 不通过表现                             |
 | --- | ----------------------- | ----------------------------------------- | ------------------------------------------------------- | -------------------------------------- |
 | 1   | 提交 AI 任务规划        | 查看提交材料中是否有任务规划文档          | 至少包含目标、上下文、任务拆分、修改范围、验证方式      | 只有代码或聊天记录，没有任务规划       |
 | 2   | 明确 AI 可改/不可改边界 | 检查任务规划或 Prompt                     | 明确写出允许修改文件、禁止修改文件、接口/数据/依赖约束  | AI 改了无关文件，或没有任何边界说明    |
 | 3   | 补充测试或验证手段      | 查看测试代码、测试用例表、验证记录        | 有新增/修改测试，或有明确验证命令、截图、日志、回归用例 | 只说"已验证"，但没有证据               |
-| 4   | 代码修复通过预设测试    | 运行预设测试或查看现场演示                | 指定测试全部通过，且无明显回归                          | 测试失败，或只运行了无关测试           |
+| 4   | 代码实现通过预设测试    | 运行预设测试或查看现场演示                | 指定测试全部通过，且无明显回归                          | 测试失败，或只运行了无关测试           |
 | 5   | AI 协作资产不是泛泛口号 | 查看 AGENTS.md / CLAUDE.md / Checklist 等 | 规则具体、可执行、能指导后续 AI 任务                    | 只有"代码要规范"类空话，没有可执行规则 |
 | 6   | 说明风险与未覆盖事项    | 查看交付说明                              | 明确列出风险，已覆盖部分有验证；未覆盖内容有说明        | 未提及任何风险或未覆盖事项             |
-| 7   | 能解释关键决策          | 书面答辩                                  | 能解释为什么这样设计测试，为什么采纳/拒绝 AI 建议       | 无法说明业务决策原因                   |
+| 7   | 能解释关键决策          | 08-ai-decisions.md / 15-brief.md 或书面答辩 | 能解释为什么这样设计测试，为什么采纳/拒绝 AI 建议       | 无法说明业务决策原因                   |
 
 ## 交付物清单
 
-评分前先核对以下三类交付物是否齐全：
+评分前先核对以下三类交付物是否齐全（参考用，缺失项在对应评分维度中扣分）：
 
-### 1. AI 协作资产
+### 1. AI 协作资产（→ 维度一）
 
 - AGENTS.md / CLAUDE.md / Copilot Instructions / Cursor Rules 任一种或多种
 - 业务术语表
@@ -77,7 +86,7 @@ NO SCORE WITHOUT EVIDENCE FIRST
 - Review Checklist
 - Delivery Checklist
 
-### 2. AI 协作任务规划
+### 2. AI 协作任务规划（→ 维度二）
 
 - 目标澄清
 - 上下文选择
@@ -88,7 +97,7 @@ NO SCORE WITHOUT EVIDENCE FIRST
 - 停下来问人的条件
 - 给 AI 的最终任务提示词
 
-### 3. 质量保障产物
+### 3. 质量保障产物（→ 维度三）
 
 - SDD 规格说明
 - 测试用例矩阵
@@ -104,10 +113,10 @@ NO SCORE WITHOUT EVIDENCE FIRST
 | 二级验收项   | 分值 | 验收标准                                                                                                        | 需检查的证据                                                             |
 | ------------ | ---- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
 | 分层组织清晰 | 5    | 能区分项目级、模块级、任务级规则；没有把所有规则混在一个大文件里                                                | AGENTS.md / CLAUDE.md / Cursor Rules / Copilot Instructions / docs/ai/\* |
-| 内容覆盖完整 | 5    | 覆盖业务术语、系统架构、代码结构、接口约定、编码规范、测试要求、Review 标准、交付要求                           | 业务术语表、架构说明、接口约定、测试规范、Review Checklist               |
-| 规则可执行   | 5    | 规则具体明确，不是「代码要优雅」这类空话；能指导 AI 后续执行                                                    | 明确的必须项、禁止项、示例、验证方式                                     |
+| 内容覆盖完整 | 5    | 8 类内容（业务术语/系统架构/代码结构/接口约定/编码规范/测试要求/Review 标准/交付要求）；8 类满分，6-7 类 80%，4-5 类 60%，≤ 3 类 40% | 业务术语表、架构说明、接口约定、测试规范、Review Checklist               |
+| 规则可执行   | 5    | 规则具体明确，不是「代码要优雅」这类空话；能指导 AI 后续执行                                                    | 明确的必须项、禁止项、示例、编码方式、验证方式                           |
 | 适配工具产物 | 5    | 至少产出 2 类工具适配产物（如 AGENTS.md、CLAUDE.md、Copilot Instructions、Cursor Rules、Prompt 模板、检查清单） | 工具规划文件、Prompt 模板、Checklist                                     |
-| 可维护性     | 5    | 有更新机制：能说明如何根据 Review、缺陷、AI 输出偏差持续优化规则                                                | 维护说明、版本记录、复盘中新增规则                                       |
+| 可维护性     | 5    | 有更新机制：能说明如何根据 Review、缺陷、AI 输出偏差持续优化规则                                                | 维护说明、版本记录、复盘文档中新规则沉淀段落                             |
 
 ### 二、AI 协作任务规划（25 分）
 
@@ -123,9 +132,9 @@ NO SCORE WITHOUT EVIDENCE FIRST
 
 | 二级验收项        | 分值 | 验收标准                                                             | 需检查的证据                           |
 | ----------------- | ---- | -------------------------------------------------------------------- | -------------------------------------- |
-| SDD 规格清晰      | 5    | 能把业务规则写成输入、输出、边界条件、验收标准、异常场景             | SDD 规格说明                           |
-| TDD 流程正确      | 5    | 先写测试代码；验证测试在修复前失败、修复后通过                       | 测试提交记录、失败/通过截图或代码 diff |
-| 测试覆盖充分      | 7    | 不是只覆盖 happy path；边界、异常场景、回归也有覆盖                  | 测试用例列表、代码 diff、改动测试结果  |
+| SDD 规格清晰      | 5    | 业务规则结构化（输入/输出/边界条件/异常场景）；关键设计决策有选择理由和拒绝理由 | SDD 规格说明                           |
+| TDD 流程正确      | 5    | 先写测试再写实现（git log 提交顺序可验证）；测试在修复前失败、修复后通过        | 测试提交记录、失败/通过截图或代码 diff |
+| 测试覆盖充分      | 7    | 正向路径(2) + 边界条件(2) + 异常场景(2) + 回归测试(1)；仅 happy path ≤ 2 分 | 测试用例列表、代码 diff、改动测试结果  |
 | 缺陷修复正确      | 5    | 修复符合业务规则；没有引入新的硬编码或副作用；没有破坏已有功能       | 代码 diff、改动测试结果                |
 | Review 与风险识别 | 5    | 能识别脆弱性、数据、安全、性能、兼容性问题；说明剩余风险和未覆盖部分 | Review 记录、风险识别记录              |
 
@@ -137,7 +146,7 @@ NO SCORE WITHOUT EVIDENCE FIRST
 | 能迭代纠偏     | 3    | AI 输出偏离时，能指出问题并调整提示；不是复制粘贴结果      | AI 对话摘要、纠偏记录 |
 | 过程可追溯     | 2    | 保留关键 AI 对话摘要；能说明为什么采纳或拒绝 AI 建议       | AI 协作过程记录       |
 | 个人复盘有效   | 2    | 每位成员能总结本次沉淀的新规则，并说明下次如何提升协作质量 | 个人复盘文档          |
-| (评委自定)     | 3    | 评委根据答辩表现酌情加分。评估维度参考：技术决策解释清晰度、对 trade-off 的理解深度、对遗留风险的坦诚程度。无答辩环节时此项不评分，3 分归入其他项按比例分配 | 答辩现场 / 书面答辩 |
+| (评委自定)     | 3    | 评委根据答辩表现酌情加分。评估维度：技术决策解释清晰度、trade-off 理解深度、遗留风险坦诚程度。无答辩环节时此项不评分，D4 得分 = 其他 4 项实得分 ÷ 10 × 13 | 答辩现场 / 书面答辩 |
 
 ### 五、团队协作表现（10 分）
 
@@ -148,72 +157,102 @@ NO SCORE WITHOUT EVIDENCE FIRST
 | 交叉 Review 有效 | 2    | Review 能发现真实问题，不只是格式建议        | 交叉 Review 记录 |
 | 个人贡献可见     | 2    | 每个人都有独立提交物、Review 记录或复盘说明  | 个人贡献说明     |
 
+> **单人项目适配**：D5 各项重新解读——"角色分工" = 同一人在 spec/impl/test/review 阶段有意识切换角色；"协作资产一致" = 产物风格自洽；"交叉 Review" = 自查或 AI 辅助 Review 发现真实问题；"个人贡献可见" = 自动满分。
+
 ## 执行步骤
 
-> **精简模式（--compact）项目**：如果项目使用了 `team-orchestrator --compact`，部分文档（01-plan、02-context、05-risk、14-team、15-brief、prompt-template）不会产出。模式判定优先级：(1) `.checkpoint.json` 的 `mode` 字段（权威来源）；(2) 如果 checkpoint 不存在，根据文件集推断——仅有 03-sdd + 04-boundary = 精简模式，有 01-05 全套 = 完整模式；(3) 模式不明 → 在评分报告中注明"模式未确定"。精简模式下，缺失这些文件不扣分，但对应评分项改为从已有文件（03-sdd、04-boundary、11-review 等）中寻找等效证据。硬门槛 #1（任务规划）改为检查 03-sdd.md 是否包含目标和设计决策。
+### Step 0：判定评分模式
+
+> 精简模式下部分文档不产出，缺失不扣分，改为从已有文件寻找等效证据。
+
+**RESOLVE** `mode`（首个命中即停）：
+
+1. **READ** `.checkpoint.json` → 取 `mode` 字段（权威来源）
+2. 文件集推断：仅有 `03-sdd.md` + `04-boundary.md` → `compact`；有 `01-05` 全套 → `full`
+3. *none* → 在评分报告中注明"模式未确定"，按 `full` 模式评分
+
+**IF** `mode == compact`：
+
+- 缺失文件（`01-plan`、`02-context`、`05-risk`、`14-team`、`15-brief`、`prompt-template`）不扣分
+- 对应评分项改为从已有文件（`03-sdd`、`04-boundary`、`11-review` 等）寻找等效证据
+- 硬门槛 #1（任务规划）改为检查 `03-sdd.md` 是否包含目标和设计决策
+- D2 等效证据映射：目标澄清 → `03-sdd.md` §一、上下文选择 → `04-boundary.md` 引用列表、任务拆分 → `03-sdd.md` 分期说明、执行约束 → `04-boundary.md`、验证与风险 → `03-sdd.md` §三 或 `11-review.md`
 
-### Step 1: 收集证据
+### Step 1：收集证据
 
-按以下 5 个维度收集证据（可并行执行以提高效率，具体并行方式取决于工具能力）：
+> 按 5 个维度收集证据（可并行执行）。以下文件名为 team-skills 流水线约定；非 team-skills 项目按内容等效性在项目中寻找对应文件。
 
 **扫描维度 1 — AI 协作资产扫描**
 
-- 查找所有 AI 规范文件：CLAUDE.md / AGENTS.md / .cursorrules / .cursor/rules / .copilot-instructions.md / docs/ai/\*
-- 查找任务级规则文件：docs/tasks/\*/task-rules.md
-- 检查分层组织（项目级 vs 模块级 vs 任务级）
-- 检查 8 类内容覆盖：业务术语表、系统架构、代码结构、接口约定、编码规范、测试规范、Review Checklist、Delivery Checklist
-- 检查规则可执行性（禁止项、必须项、示例、验证方式）
-- 检查工具适配产物 ≥ 2 类（Prompt 模板、检查清单等）
-- 检查维护机制（维护说明、版本记录、复盘新增规则机制）
+1. **READ** 所有 AI 规范文件：`CLAUDE.md` / `AGENTS.md` / `.cursorrules` / `.cursor/rules/` / `.copilot-instructions.md` / `docs/ai/*`
+2. **READ** 任务级规则文件：`docs/tasks/*/task-rules.md`
+3. 检查分层组织（项目级 vs 模块级 vs 任务级）
+4. 检查 8 类内容覆盖：业务术语表、系统架构、代码结构、接口约定、编码规范、测试规范、Review Checklist、Delivery Checklist
+5. 检查规则可执行性（禁止项、必须项、示例、编码方式、验证方式）
+6. 检查工具适配产物 >= 2 类（Prompt 模板、检查清单等）
+7. 检查维护机制（维护说明、版本记录、复盘新增规则机制）
 
 **扫描维度 2 — 任务规划扫描**
 
-- 查找 docs/ 下的任务规划、PRD、设计文档、实现计划
-- 逐项检查：目标澄清（成功标准、非目标）、上下文选择说明（必要文件清单、排除）、分阶段执行计划（探索→方案→实现→验证→总结）、修改文件边界（allow/deny）、验证计划（每步可检查标准）、风险识别、停下来问人条件、AI 任务提示词（prompt-template.md 或文档内嵌）
+1. **READ** `docs/` 下的任务规划、PRD、设计文档、实现计划
+2. 逐项检查：目标澄清（成功标准、非目标）、上下文选择说明（必要文件清单、排除）、分阶段执行计划（探索 → 方案 → 实现 → 验证 → 总结）、修改文件边界（allow/deny）、验证计划（每步可检查标准）、风险识别、停下来问人条件、AI 任务提示词（`prompt-template.md` 或文档内嵌）
 
 **扫描维度 3 — 质量保障扫描**
 
-- 检查 tests/ 目录结构、测试文件数量、CI 配置
-- 检查 SDD 规格文档（输入/输出/边界条件/异常场景/验收标准）
-- 检查 git log 中 TDD 模式（test: 提交 → feat:/fix: 提交）
-- 检查测试覆盖范围（happy path / 边界 / 异常 / 回归）、测试用例矩阵、测试运行结果
-- 检查缺陷修复代码及测试验证、Review 记录（含脆弱性/数据/安全/性能/兼容性）、风险识别文档
-- 运行项目测试命令列出测试用例
+1. **READ** `tests/` 目录结构、测试文件数量、CI 配置
+2. **READ** SDD 规格文档（输入/输出/边界条件/异常场景）+ 关键设计决策表（选择方案/拒绝方案/拒绝理由）
+3. **EXEC** `git log --oneline` → 检查 TDD 模式（`test:` 提交 → `feat:`/`fix:` 提交）
+4. **READ** 测试覆盖范围（happy path / 边界 / 异常 / 回归）、测试用例矩阵、测试运行结果
+5. **READ** 缺陷修复代码及测试验证、Review 记录（含脆弱性/数据/安全/性能/兼容性）、风险识别文档
+6. **EXEC** 项目测试命令 → 列出测试用例
+7. **READ** CI 配置 → 检查自动化检查项（lint、type-check、test 等）
 
 **扫描维度 4 — 使用过程扫描**
 
-- 查找 AI 对话记录、Prompt 记录（07-prompt-log.md）、纠偏记录
-- 查找个人复盘文档（13-retrospective.md），检查是否有「本次沉淀的新规则」段落
-- 检查 skills 和配置目录
-- 检查是否有结构化的 Prompt（五要素：目标+上下文+边界+输出格式+验证标准）
+1. **READ** AI 对话记录、Prompt 记录（`07-prompt-log.md`）、纠偏记录
+2. **READ** 个人复盘文档（`13-retrospective.md`） → 检查是否有「本次沉淀的新规则」段落
+3. **READ** skills 和配置目录
+4. 检查是否有结构化的 Prompt（五要素：目标 + 上下文 + 边界 + 输出格式 + 验证标准）
 
 **扫描维度 5 — 团队协作扫描**
 
-- 检查 git log --format='%an' 统计贡献者
-- 查找分工说明文档（需求澄清、AI 操作、测试、Review 等角色分工）
-- 查找交叉 Review 记录（Review 是否发现真实问题，不只是格式建议）
-- 检查产物风格一致性（多个文件写作风格统一，没有简单拼接）
-- 检查每个人是否有独立提交物、Review 记录或复盘说明
+1. **EXEC** `git log --format='%an'` → 统计贡献者
+2. **READ** 分工说明文档（需求澄清、AI 操作、测试、Review 等角色分工）
+3. **READ** 交叉 Review 记录 → 检查 Review 是否发现真实问题（不只是格式建议）
+4. 检查产物风格一致性（多个文件写作风格统一，没有简单拼接）
+5. 检查每个人是否有独立提交物、Review 记录或复盘说明
 
-### Step 2: 硬门槛判定
+### Step 2：硬门槛判定
 
-根据收集的证据，逐条判定 7 项硬门槛是否通过。任一不通过则在报告中醒目标注。
+**FOR** 硬门槛 #1 ~ #7：
 
-### Step 3: 逐项评分
+1. 根据 Step 1 收集的证据判定是否通过
+2. **ASSERT** 有具体证据支撑判定结果
+   - 通过 → 记录证据摘要
+   - 不通过 → 记录不通过原因 + 具体缺失项
 
-对每个二级验收项：
+**GATE** 硬门槛汇总：
 
-1. 列出找到的证据（文件路径 + 关键内容摘要）
-2. 根据验收标准给出得分（0 ~ 满分）
-3. 给出简短评语
+- [ ] 7 项硬门槛已逐条判定
+- [ ] 任一不通过项已在报告中醒目标注
+
+### Step 3：逐项评分
+
+**FOR** 每个二级验收项（5 个维度，共 24 项）：
+
+1. **ASSERT** 该项有来自 Step 1 的证据支撑 → 找不到证据 = 0 分，记录"未找到：`{搜索过的路径}`"
+2. 根据验收标准给出得分（0 ~ 满分），附带具体文件路径和内容片段
+3. **WRITE** 评语到报告
+
+> Iron Law: NO SCORE WITHOUT EVIDENCE FIRST
 
 **反虚构规则**：
 
 - 每个得分必须附带具体文件路径和内容片段作为证据
 - "文件存在但内容为占位符/模板未填充" = 0 分（不是满分）
-- **模板未填充判定**：满足以下任一条件即视为未填充 → 0 分：超过 20% 的行包含占位符（{N}/{slug}/[TODO]/[FIXME]）；总有效行数 < 5 行（仅有表头或框架）；内容与模板文件完全相同（未做任何定制化修改）
-- 找不到证据时写"未找到：{搜索过的路径}"而非空白
-- 对 TDD 流程评分（D3.2），必须验证 06-tdd-log.md 中 RED 记录的时间戳早于 GREEN 记录
+- **模板未填充判定**：满足任一即视为未填充 → 0 分：> 20% 的行含占位符（`{N}`/`{slug}`/`[TODO]`/`[FIXME]`）；有效行数 < 10（标题行/空行/分隔线不计）；内容与模板文件完全相同
+- 找不到证据时写"未找到：`{搜索过的路径}`"而非空白
+- 对 TDD 流程评分（D3.2），必须验证 `06-tdd-log.md` 中 RED 记录的时间戳早于 GREEN 记录
 - 对测试覆盖评分（D3.3），必须验证测试代码实际存在且可运行，不仅看文档声明
 
 评分档次参考：
@@ -224,9 +263,11 @@ NO SCORE WITHOUT EVIDENCE FIRST
 - **40%**: 有意识但执行不足
 - **0分**: 完全缺失
 
-### Step 4: 输出报告
+> **D4/D5 特别说明**：维度四（使用过程）和维度五（团队协作）涉及过程记录和协作行为，证据可能不在代码库中。无对应文件时标注「需现场补充」并暂不评分，待补充证据后再给分——不是直接给 0 分，也不是无证据给分。
+
+### Step 4：输出报告
 
-输出格式如下：
+**WRITE**（对话中）评分报告，格式如下：
 
 ```
 # AI 协作评分报告
@@ -254,13 +295,14 @@ NO SCORE WITHOUT EVIDENCE FIRST
 ### 五、团队协作表现（得分/10）
 ...
 
-## 总分：XX / 100
+## 总分：XX / 100（硬门槛 X/7 通过）
 
 ## 等级判定
 - 90-100: 优秀 — AI 协作能力成熟
 - 75-89: 良好 — 有体系但需完善
 - 60-74: 合格 — 基本意识具备但实践不足
 - <60: 不合格 — 需要系统学习 AI 协作方法
+- 硬门槛未全部通过：不论评分均判定为不合格
 
 ## 改进建议（按优先级排列）
 1. ...
@@ -268,27 +310,29 @@ NO SCORE WITHOUT EVIDENCE FIRST
 
 ```
 
-### Step 5: 改进建议
+### Step 5：改进建议
+
+> 改进建议直接在对话中输出，不写入文件。
 
-改进建议直接在对话中输出，不写入文件。建议按以下优先级排列：
+**WRITE** 改进建议到报告末尾，**MATCH** `priority`：
 
-1. 硬门槛不通过项（必须立即修复）
-2. 0 分项（完全缺失，投入产出比最高）
-3. 低于 60% 的项（有明显缺陷）
-4. 低于 80% 的项（可快速提升）
+- 硬门槛不通过项 → P0：必须立即修复
+- 0 分项 → P1：完全缺失，投入产出比最高
+- 低于 60% 的项 → P2：有明显缺陷
+- 低于 80% 的项 → P3：可快速提升
 
-每条建议包含：
+**FOR** 每条建议：
 
-- 当前问题
-- 具体改进动作（可操作，不是空话）
-- 预期提升分数
+1. **WRITE** 当前问题
+2. **WRITE** 具体改进动作（可操作，不是空话）
+3. **WRITE** 预期提升分数
 
 ## STOP Signals
 
-- 凭印象或推测给分，没有找到实际文件或代码作为证据
-- 找不到证据的评分项没有标注"未找到"就跳过
-- 只扫描代码目录，不检查文档、配置和测试目录
-- 评分报告不包含按优先级排列的改进建议
+- **凭印象**给分，没有找到实际文件或代码作为证据
+- **跳过**无证据的评分项而不标注"未找到"
+- **只扫描**代码目录而不检查文档和测试目录
+- **省略**按优先级排列的改进建议
 
 ## Constitutional Rules 遵守
 
@@ -300,32 +344,34 @@ NO SCORE WITHOUT EVIDENCE FIRST
 
 ## 自检门禁
 
-在报告完成状态前，执行以下自检：
-
-- [ ] 7 项硬门槛已逐条检查
-- [ ] 5 个 Agent 的证据收集已完成
-- [ ] 每个二级验收项有实际证据支撑（不是凭猜测）
-- [ ] 找不到证据的项已标注「未找到」并给 0 分
-- [ ] 改进建议按优先级排列
+- [ ] 7 项硬门槛已逐条 **ASSERT** 检查
+- [ ] 5 个维度的证据 **READ**/**EXEC** 收集已完成
+- [ ] **FOR** 每个二级验收项有实际证据支撑（不是凭猜测）
+- [ ] 找不到证据的项已标注「未找到」并给 0 分（D4/D5 过程类证据不在代码库中时标注「需现场补充」）
+- [ ] 改进建议已按 **MATCH** `priority` 排列
 
 ## 完成标志
 
-```
-状态：DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
-评分报告：已输出到对话
-硬门槛：全部通过 / 存在不通过项
-总分：{N} / 100
-等级：{优秀/良好/合格/不合格}
-```
+**MATCH** `result`：
+
+- 全部评分完成 + 改进建议已输出 → **DONE**（`总分: {N}/100`, `硬门槛: {N}/7`, `等级: {优秀/良好/合格/不合格}`, `改进建议: {N} 条`）
+- 部分评分项证据不足但已标注 → **DONE_WITH_CONCERNS**
+- 关键文件无法访问 → **NEEDS_CONTEXT**
+- 项目测试命令无法执行 → **BLOCKED**，触发 **H3**
 
 ## 集成关系
 
 **被谁调用：**
 
-- `team-orchestrator`（编排模式）
 - 用户直接调用（独立使用）
 
 **配对使用：**
 
 - `team-spec` — 需要补充规格时使用
 - `team-test` — 需要补充测试时使用
+- `team-review` — 需要补充审查资产时使用
+
+## 下一步
+
+- P0/P1 改进项 → 使用对应 Skill 补全（`team-spec` / `team-test` / `team-review`）
+- 评分报告可作为 `team-orchestrator` 验收环节的参考输入