response-rater

响应评估技能

响应评估器 - 根据质量标准评估响应和计划，提供评分、反馈和改进建议。 - 根据评分标准评估响应 - 验证计划质量 - 提供改进反馈 - 生成质量报告

步骤 1：定义评分标准

根据内容类型使用适当的评分标准：

对于计划：

维度	权重	描述
完整性	20%	包含所有必需章节
可行性	20%	计划现实可行且能够实现
风险缓解	20%	识别风险并提出缓解措施
Agent 覆盖情况	20%	分配了适当的 Agent
集成度	20%	与现有系统相适配

对于响应：

维度	权重	描述
正确性	25%	技术上准确
完整性	25%	满足所有要求
清晰度	25%	易于理解
可执行性	25%	提供明确的后续步骤

步骤 2：评估各个维度

为每个维度打 1–10 分：

## Dimension Scores

### Completeness: 8/10

- Has objectives, steps, and timeline
- Missing risk assessment section

### Feasibility: 7/10

- Most steps are achievable
- Step 3 timeline is aggressive

### Risk Mitigation: 5/10

- Only 1 risk identified
- No mitigation strategies

### Agent Coverage: 9/10

- All steps have assigned agents
- Good agent-task matching

### Integration: 8/10

- Uses existing APIs
- Minor compatibility concerns

步骤 3：计算总分

计算加权平均分：

Overall = (8×0.2) + (7×0.2) + (5×0.2) + (9×0.2) + (8×0.2) = 7.4/10

步骤 4：生成建议

提供可执行的改进建议：

## Recommendations

### High Priority

1. Add risk assessment section with 3-5 risks
2. Include mitigation strategies for each risk

### Medium Priority

3. Extend Step 3 timeline by 2 days
4. Add fallback plan for external API dependency

### Low Priority

5. Add success metrics for each step

步骤 5：作出通过/不通过决定

应用最低分数门槛：

任务类型	最低分数
标准	7/10
企业级	8/10
关键	9/10

## Decision

**Score**: 7.4/10
**Threshold**: 7/10 (Standard)
**Result**: PASS ✅

Plan approved with recommendations for improvement.

</execution_process>

<best_practices>

1. 评分标准一致：对可比较的内容使用相同的维度
2. 明确门槛：事先定义通过/不通过标准
3. 反馈可执行：提出具体改进措施
4. 按优先级排序问题：按影响程度排列建议
5. 记录理由：说明评分依据

</best_practices>

**计划评分请求**：

Rate this plan for user authentication implementation

响应：

## Plan Rating: User Authentication

### Scores

- Completeness: 8/10 - Good structure, missing tests section
- Feasibility: 9/10 - Realistic timeline and approach
- Risk Mitigation: 6/10 - Only 1 risk identified
- Agent Coverage: 9/10 - Good agent assignments
- Integration: 8/10 - Compatible with existing auth

### Overall: 8.0/10 ✅ PASS

### Top Recommendations

1. Add risk section with security and dependency risks
2. Include test plan for each authentication flow
3. Add rollback procedure for failed deployment

</usage_example>

铁律

1. 始终使用相同的评分维度评估可比较的内容——维度不一致会使评分失去意义，也无法在不同会话间进行有效比较。
2. 绝不在未记录各维度评分依据的情况下作出通过/不通过决定——缺乏依据的评分无法复核、质疑或改进。
3. 始终应用已定义的最低分数门槛（标准 7/10、企业级 8/10、关键 9/10）——随意设定门槛会导致审批标准不一致，削弱评分系统的可信度。
4. 绝不给出含糊的建议——每条建议都必须指出所针对的具体维度，并说明需要采取的具体改动。
5. 始终按影响程度排列建议——必须明确区分会显著提高评分的高优先级事项与影响较小的建议。

反模式

反模式	失败原因	正确做法
对可比较的内容使用不同的评分标准维度	不同会话之间的分数无法比较；评分失去了评估价值	始终使用相同的评分标准（计划使用计划评分标准，响应使用响应评分标准）
未说明各个维度的评分理由	没有理由的评分无法审核、验证或用于采取行动	记录每个维度评分的具体依据（有哪些内容、缺少哪些内容）
每次会话随意设定阈值	阈值不一致会导致通过／不通过门槛失效；团队会对审批失去信心	始终采用既定阈值：标准为 7/10，企业级为 8/10，关键级为 9/10
给出含糊的建议（“提升质量”“添加更多细节”）	含糊的反馈无法落实；评审不会带来任何改变	每条建议都要指出具体维度、分数差距和所需的具体改动
列出建议时未按优先级排序	将反馈视为同等重要，会导致评分人员先处理影响较小的事项	始终按影响程度排序：高（影响通过／不通过阈值）优先，其次是中，最后是低

记忆协议（强制）

开始前：

cat .claude/context/memory/learnings.md

完成后：

• 新模式 -> .claude/context/memory/learnings.md
• 发现问题 -> .claude/context/memory/issues.md
• 作出决策 -> .claude/context/memory/decisions.md

假设会发生中断：你的上下文可能会重置。如果未记录在记忆中，就等于没有发生。