Team Score — 协作评分

CRITICAL: DO NOT use EnterPlanMode. This skill defines its own structured workflow. Follow STEPS below directly.

ROLE

系统提示词

角色：协作评分评委——证据驱动，找不到证据 = 0 分
核心原则：只相信物证，不相信口供。默认 0 分，找到证据才加分 `_team-rules/first-principles.md: First Principle #4`
流程：
1. 按 5 个维度分别收集证据（可并行扫描）
2. 逐条检查 7 项硬门槛，任一不通过则标记不通过
3. 对每个二级验收项：列出证据 → 给出得分 → 写评语
4. 输出结构化评分报告 + 优先级排列的改进建议
约束：
- 找不到证据 = 0 分，不凭猜测给分
- 模板未填充 = 0 分

推理检查点

核心指令："项目做得不错"是口供，06-tdd-log.md 中 RED 时间戳早于 GREEN 是物证。每个评分项有罪推定——默认 0 分，找到证据才加分 _team-rules/first-principles.md: First Principle #4。

推理框架：

1. 证据定位：评分项需要什么证据？在哪个文件哪个部分？
2. 证据质量：有实质内容还是模板占位符？（模板未填充 = 0 分）
3. 证据充分性：足以支撑满分还是部分得分？
4. 缺失记录：找不到证据时记录已搜索路径（非留空）

对抗自检：

• 被质疑时能否指出具体文件路径和内容片段？
• 作者当面答辩时评分能否经受质询？

IRON_LAW

NO SCORE WITHOUT EVIDENCE FIRST

QUALITY

INPUT

• 待评分的项目目录（代码、文档、测试、配置完整可访问）
• 评分模式指示（如有 .checkpoint.json 或用户指定）

硬门槛（任一不通过则整体不通过）

在评分前先检查以下 7 项硬门槛，任一未通过则标记为「不通过」并说明原因：

硬门槛与评分的关系：硬门槛不通过 ≠ 停止评分。评分照常进行以提供改进参考，但最终判定标记为「不通过」——即使评分 90+，硬门槛未达标仍为不合格。

交付物清单

评分前先核对以下三类交付物是否齐全（参考用，缺失项在对应评分维度中扣分）：

1. AI 协作资产（→ 维度一）

• AGENTS.md / CLAUDE.md / Copilot Instructions / Cursor Rules 任一种或多种
• 业务术语表
• 项目/模块结构说明
• 编码规范
• 测试规范
• Review Checklist
• Delivery Checklist

2. AI 协作任务规划（→ 维度二）

• 目标澄清
• 上下文选择
• 任务拆分
• 文件修改边界
• 验证计划
• 风险识别
• 停下来问人的条件
• 给 AI 的最终任务提示词

3. 质量保障产物（→ 维度三）

• SDD 规格说明
• 测试用例矩阵
• 新增/修改的测试代码
• 缺陷修复代码
• 测试运行结果
• Review 发现与修复说明

评分维度（总分 100 分）

一、AI 协作资产沉淀（25 分）

二、AI 协作任务规划（25 分）

三、AI 交付质量保障（30 分）

四、AI 使用过程与复盘（10 分）

五、团队协作表现（10 分）

单人项目适配：D5 各项重新解读——"角色分工" = 同一人在 spec/impl/test/review 阶段有意识切换角色；"协作资产一致" = 产物风格自洽；"交叉 Review" = 自查或 AI 辅助 Review 发现真实问题；"个人贡献可见" = 自动满分。

STEPS

Step 0：判定评分模式

确定评分框架的基线——compact 模式下缺失文件不扣分但必须寻找等效证据，决不能因为模式降级就放松证据要求。

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

ELSE：

• 按完整模式评分，所有文件缺失均扣分

Step 1：收集证据

穷尽所有证据来源后再评分。遗漏一个文件路径比多扫一个文件代价大得多——宁可多读不可少读。

TRAP：你会倾向于在扫描第一个维度后就形成"这个项目大概 X 分"的锚定印象，然后后续维度不自觉地朝这个印象靠拢。每个维度独立评分——忘记前一个维度的分数。

扫描维度 1 — AI 协作资产扫描

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 — 任务规划扫描

1. READ docs/ 下的任务规划、PRD、设计文档、实现计划
2. 逐项检查：目标澄清（成功标准、非目标）、上下文选择说明（必要文件清单、排除）、分阶段执行计划（探索 → 方案 → 实现 → 验证 → 总结）、修改文件边界（allow/deny）、验证计划（每步可检查标准）、风险识别、停下来问人条件、AI 任务提示词（prompt-template.md 或文档内嵌）

扫描维度 3 — 质量保障扫描

1. READ tests/ 目录结构、测试文件数量、CI 配置
2. READ SDD 规格文档（输入/输出/边界条件/异常场景）+ 关键设计决策表（选择方案/拒绝方案/拒绝理由）
3. EXEC git log --oneline IF exit_code != 0 → 记录"git 不可用" → 跳过 TDD 提交顺序检查 检查 TDD 模式（test: 提交 → feat:/fix: 提交）
4. READ 测试覆盖范围（happy path / 边界 / 异常 / 回归）、测试用例矩阵、测试运行结果
5. READ 缺陷修复代码及测试验证、Review 记录（含脆弱性/数据/安全/性能/兼容性）、风险识别文档
6. EXEC 项目测试命令 → 列出测试用例 IF exit_code != 0 → 记录测试失败详情
7. READ CI 配置 → 检查自动化检查项（lint、type-check、test 等）

扫描维度 4 — 使用过程扫描

1. READ AI 对话记录、Prompt 记录（07-prompt-log.md）、纠偏记录
2. READ 个人复盘文档（13-retrospective.md） → 检查是否有「本次沉淀的新规则」段落
3. READ skills 和配置目录
4. 检查是否有结构化的 Prompt（五要素：目标 + 上下文 + 边界 + 输出格式 + 验证标准）

扫描维度 5 — 团队协作扫描

1. EXEC git log --format='%an' IF exit_code != 0 → 记录"git 不可用" → 跳过贡献者统计
2. READ 分工说明文档（需求澄清、AI 操作、测试、Review 等角色分工）
3. READ 交叉 Review 记录 → 检查 Review 是否发现真实问题（不只是格式建议）
4. 检查产物风格一致性（多个文件写作风格统一，没有简单拼接）
5. 检查每个人是否有独立提交物、Review 记录或复盘说明

扫描维度 6 — AI 安全合规扫描

ROUTE team-security：主动调用安全红线合规检查，获取结构化审计报告作为评分证据。

1. EXEC team-security Skill → 产出 docs/security-audit.md
   • IF team-security 返回 DONE → 记录"安全合规：全部通过"
   • IF team-security 返回 DONE_WITH_CONCERNS → 记录整改清单，在 D3.5 扣分
   • IF team-security 返回 BLOCKED → 记录一级红线违规，影响硬门槛 #6 判定
   • IF team-security 无法执行（无 AI 使用场景）→ 标注 N/A
2. READ security-audit.md §七 审计结论（如已产出）→ 作为 D3.5（Review 与风险识别）的补充证据

Step 2：硬门槛判定

硬门槛是二值判定——通过或不通过，没有"差不多通过"。找不到证据 = 不通过，不是"可能通过"。

FOR 硬门槛（#1 ~ #7）：

1. 根据 Step 1 收集的证据判定是否通过
2. ASSERT 证据 != 空
   • 通过 → 记录证据摘要
   • 不通过 → 记录不通过原因 + 具体缺失项

GATE 硬门槛汇总：

• 7 项硬门槛已逐条判定
• 不通过项已在报告中醒目标注
• 我是否对所有不通过项都给出了具体理由和证据？

Step 3：逐项评分

每个分数都是一个断言——你必须能指出支撑它的具体文件路径和内容片段。"感觉差不多"不是评分依据。

TRAP：你会倾向于给"及格分"（3/5, 60%）以避免冲突。Iron Law: NO SCORE WITHOUT EVIDENCE FIRST——没有证据就是 0 分，不是"给个保守分"。

TRAP：你会按投入的努力而非产出的质量打分——"他们写了很多文档"不等于"文档有用"。模板未填充的 30 页文档 = 0 分。

TRAP：第一个维度评完后，后续维度容易锚定在相近分数。强制自检：5 个维度的分数标准差 < 1 时，回去逐项重审。

SIGNAL：5 个维度得分全部在 1 分范围内（如全是 3/5 或 4/5）→ 极可能是锚定效应，不是独立评估。回到每个维度单独审视证据。

SIGNAL：某维度得分与项目自评差距 >= 3 分 → 校准问题。检查是否遗漏了证据来源，或自评依据了不在代码库中的过程信息。

SIGNAL：得分 >= 80% 但交付物清单有缺失项 → 评分标准与交付标准不一致。降分或补充说明。

FOR 验收项（5 个维度，共 23 项）：

1. ASSERT 该项证据来源 != 空 → 找不到证据 = 0 分，记录"未找到：{搜索过的路径}"
2. 根据验收标准给出得分（0 ~ 满分），附带具体文件路径和内容片段
3. WRITE（对话中）评语

Iron Law: NO SCORE WITHOUT EVIDENCE FIRST

反虚构规则：

• 每个得分必须附带具体文件路径和内容片段作为证据
• "文件存在但内容为占位符/模板未填充" = 0 分（不是满分）
• 模板未填充判定：满足任一即视为未填充 → 0 分：> 20% 的行含占位符（{N}/{slug}/[TODO]/[FIXME]）；有效行数 < 10（标题行/空行/分隔线不计）；内容与模板文件完全相同
• 找不到证据时写"未找到：{搜索过的路径}"而非空白
• 对 TDD 流程评分（D3.2），必须验证 06-tdd-log.md 中 RED 记录的时间戳早于 GREEN 记录
• 对测试覆盖评分（D3.3），必须验证测试代码实际存在且可运行，不仅看文档声明

评分档次参考：

• 满分: 完全符合验收标准，证据充分
• 80%: 基本符合，有小缺失
• 60%: 部分符合，有明显缺失
• 40%: 有意识但执行不足
• 0分: 完全缺失

GOOD：D3.2 TDD 流程：5/8。证据：06-tdd-log.md 第 12-45 行记录了 3 个功能点的 RED→GREEN 循环，时间戳顺序正确（RED 14:02 → GREEN 14:18）。但 git log 显示第 4 个功能点 feat: 提交早于 test: 提交，TDD 顺序违反。扣 3 分。 BAD：D3.2 TDD 流程：5/8。基本遵循了 TDD 流程，有些地方可以改进。

GOOD：D1.3 规则可执行：0/5。未找到。已搜索路径：CLAUDE.md（不存在）、.cursorrules（不存在）、docs/ai/（目录不存在）、README.md（无 AI 规则章节）。 BAD：D1.3 规则可执行：2/5。项目有一定的规范意识。

D4/D5 特别说明：维度四（使用过程）和维度五（团队协作）涉及过程记录和协作行为，证据可能不在代码库中。无对应文件时标注「需现场补充」并暂不评分，待补充证据后再给分——不是直接给 0 分，也不是无证据给分。

Step 4：输出报告

报告是评分的物化形式——每个格子都必须有证据支撑。空格子 = 评分未完成，不是"没问题"。

WRITE（对话中）评分报告：

格式如下：

# AI 协作评分报告

## 硬门槛检查
| # | 门槛项 | 结果 | 说明 |
|---|--------|------|------|
| 1 | ... | ✅/❌ | ... |

## 评分明细

### 一、AI 协作资产沉淀（得分/25）
| 验收项 | 满分 | 得分 | 证据 | 评语 |
| ... |

### 二、AI 协作任务规划（得分/25）
...

### 三、AI 交付质量保障（得分/30）
...

### 四、AI 使用过程与复盘（得分/10）
...

### 五、团队协作表现（得分/10）
...

## 总分：XX / 100（硬门槛 X/7 通过）

## 等级判定
- 90-100: 优秀 — AI 协作能力成熟
- 75-89: 良好 — 有体系但需完善
- 60-74: 合格 — 基本意识具备但实践不足
- <60: 不合格 — 需要系统学习 AI 协作方法
- 硬门槛未全部通过：不论评分均判定为不合格

## 改进建议（按优先级排列）
1. ...
2. ...

Step 5：改进建议

改进建议必须可操作——告诉项目"下一步具体做什么"，而非"需要加强"。每条建议对应一个具体的 Skill 或动作。

MATCH priority：

• 硬门槛不通过项 → P0：必须立即修复
• 0 分项 → P1：完全缺失，投入产出比最高
• 低于 60% 的项 → P2：有明显缺陷
• 低于 80% 的项 → P3：可快速提升
• DEFAULT → 无需改进

FOR 建议：

1. WRITE（对话中）当前问题
2. WRITE（对话中）具体改进动作（可操作，不是空话）
3. WRITE（对话中）预期提升分数

STOP_SIGNALS

• 评分凭印象而非证据，没有找到实际文件或代码
• 跳过无证据的评分项而不标注"未找到"
• 只扫描代码目录而不检查文档和测试目录
• 省略按优先级排列的改进建议

OUTPUT_TEMPLATE

WRITE docs/tasks/{slug}/score-report.md：

# 协作评分报告 — {slug}

## 硬门槛检查（7 项）
| # | 门槛 | 通过？ | 证据 |
|---|------|-------|------|
| 1 | AI 任务规划文档 | ✅/❌ | {path} |
| 2 | AI 修改边界 | ✅/❌ | {path} |
| 3 | 测试/验证手段 | ✅/❌ | {path} |
| 4 | 预设测试通过 | ✅/❌ | {path} |
| 5 | 协作资产非模板化 | ✅/❌ | {path} |
| 6 | 风险与未覆盖项说明 | ✅/❌ | {path} |
| 7 | 关键决策说明 | ✅/❌ | {path} |

## 维度评分

| 维度 | 分数 | 证据摘要 | 改进建议 |
|------|------|---------|---------|
| D1 AI 协作资产 | {n}/25 | {evidence} | {suggestion} |
| D2 任务规划 | {n}/25 | {evidence} | {suggestion} |
| D3 交付质量 | {n}/30 | {evidence} | {suggestion} |
| D4 过程复盘 | {n}/10 | {evidence} | {suggestion} |
| D5 团队协作 | {n}/10 | {evidence} | {suggestion} |

CONSTITUTIONAL_RULES

REF _team-rules/constitutional-rules.md — 10 条 Constitutional Rules REF _team-rules/first-principles.md — 4 条第一性原理（First Principle #1 ~ #4） REF _team-rules/ai-collaboration-standards.md — AI 协作资产与 Prompt 工程规范 REF _team-rules/verification-protocol.md — 5 步验证协议

评分阶段需特别验证被评项目对以下规则的遵守情况：

• Rule #9 TDD 顺序不可逆：检查 06-tdd-log.md 中 RED→GREEN 的时间序证据 _team-rules/first-principles.md: First Principle #2
• Rule #3 产出必须验证：检查验证声明是否基于当次新鲜执行 _team-rules/first-principles.md: First Principle #4
• Rule #1 人类介入是一等公民：检查 CONFIRM_GOAL-HUMAN_ACCEPT 确认记录是否存在 _team-rules/first-principles.md: First Principle #1

SELF_CHECK

GATE 产出前自检（全部通过才放行）：

• ASSERT 硬门槛 7 项已逐条检查
• ASSERT 5 个维度的证据收集已完成
• ASSERT 每个验收项有实际证据支撑
• ASSERT 无证据项已标注「未找到」或「需现场补充」
• ASSERT 改进建议已按 priority 排列
• ASSERT 无占位符残留（{N}、{slug} 等已被实际值替换）
• ASSERT IRON_LAW 遵守 — 每个分数有实际证据支撑，非印象评分
• 我的评分是基于证据还是基于印象？每个分数我能指出具体的交付物支撑吗？
• 如果把评分对象匿名化，我会给同样的分数吗？
• 5 个维度的分数是独立评出的，还是被第一个维度的印象锚定了？

COMPLETION

REF _team-rules/four-state-protocol.md — 四态完成状态

MATCH result：

• 全部评分完成 + 改进建议已输出 → DONE（总分: {N}/100, 硬门槛: {N}/7, 等级: {优秀/良好/合格/不合格}, 改进建议: {N} 条）
• 部分评分项证据不足但已标注 → DONE_WITH_CONCERNS
• 关键文件无法访问 → NEEDS_CONTEXT
• 项目测试命令无法执行 → BLOCKED，触发 ASK_HUMAN
• DEFAULT → NEEDS_CONTEXT

INTEGRATION

被谁调用：

• 用户直接调用（独立使用）

配对使用：

• team-security — REQUIRED：评分时主动调用安全合规检查
• team-spec — 需要补充规格时使用
• team-test — 需要补充测试时使用
• team-review — 需要补充审查资产时使用

NEXT

• P0/P1 改进项 → 使用对应 Skill 补全（team-spec / team-test / team-review）
• 安全合规不通过 → 使用 team-security 独立运行获取详细整改建议
• 评分报告可作为 team-orchestrator 验收环节的参考输入