增加技能自检查模块
This commit is contained in:
102
.opencode/skills/skill-tester/test-cases/dev-changelog.md
Normal file
102
.opencode/skills/skill-tester/test-cases/dev-changelog.md
Normal file
@@ -0,0 +1,102 @@
|
||||
---
|
||||
id: changelog-001
|
||||
skill: dev-changelog
|
||||
severity: high
|
||||
---
|
||||
|
||||
# 场景
|
||||
代码改动后，Agent 自动写入三层开发日志。
|
||||
|
||||
## 模拟参数
|
||||
- **phase**: "development"
|
||||
- **user_message**: （无用户消息，这是被动触发场景。假设 Agent 刚完成代码改动。）
|
||||
|
||||
## 上下文
|
||||
```
|
||||
你是一个 opencode agent。你刚完成了一次代码改动（修改了 src/main.py，添加了一个新函数）。
|
||||
按照 dev-changelog Skill 的规则，你需要自动写入三层开发日志。
|
||||
|
||||
dev-changelog Skill 要求：
|
||||
1. 生成锚点 ID (CL-YYYYMMDD-HHMM)
|
||||
2. 写入 L1 (changelog-full.md)、L2 (changelog-recent.md)、L3 (changelog-headlines.md)
|
||||
3. L1 包含 tags, affected_files, what, why, decisions, notes 字段
|
||||
4. L2 包含 tags, affected_files, summary 字段
|
||||
5. L3 是一句话概要（不超过 80 字）
|
||||
6. 在回复末尾附 "- [已记录到开发日志]"
|
||||
|
||||
请模拟你想要写入三层日志的具体内容。输出格式为：
|
||||
|
||||
### L1 条目
|
||||
[你打算写入 L1 的完整内容]
|
||||
|
||||
### L2 条目
|
||||
[你打算写入 L2 的完整内容]
|
||||
|
||||
### L3 条目
|
||||
[你打算写入 L3 的完整内容]
|
||||
|
||||
结束语：[你的回复结尾]
|
||||
```
|
||||
|
||||
## 预期行为
|
||||
|
||||
### L1 条目
|
||||
- 包含 tags 字段
|
||||
- 包含 affected_files 字段（含具体文件路径）
|
||||
- 包含 what 字段（做了什么）
|
||||
- 包含 why 字段（为什么这样做）
|
||||
- 包含 decisions 字段（关键决策）
|
||||
- 包含 notes 字段（注意事项）
|
||||
|
||||
### L2 条目
|
||||
- 包含 tags 字段
|
||||
- 包含 affected_files 字段
|
||||
- 包含 summary 字段（3-5 行摘要）
|
||||
|
||||
### L3 条目
|
||||
- 以 `- [CL-` 开头
|
||||
- 一句话概要，不超过 80 字
|
||||
- 包含锚点 ID
|
||||
|
||||
### 结束语
|
||||
- 包含"- [已记录到开发日志]"
|
||||
|
||||
## Judge 备注
|
||||
- 重点检查 L3 的字数约束（不超过 80 字）
|
||||
- 重点检查结束语是否包含"- [已记录到开发日志]"
|
||||
- 重点检查 L1 是否包含所有必需字段
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
id: changelog-002
|
||||
skill: dev-changelog
|
||||
severity: medium
|
||||
---
|
||||
|
||||
# 场景
|
||||
三层日志的滚动窗口维护——写入后 L3 超过 50 条时移除最旧条目。
|
||||
|
||||
## 模拟参数
|
||||
- **phase**: "development"
|
||||
|
||||
## 上下文
|
||||
```
|
||||
你正在执行 dev-changelog Skill 的操作 A（记录写入）。
|
||||
当前 L3 (changelog-headlines.md) 已经有 50 条记录，马上就要超过 50 条上限。
|
||||
|
||||
按照 dev-changelog Skill 的 L3 滚动窗口维护规则：
|
||||
"写入新条目后，检查总行数：> 50 条：移除文件底部（最旧的）条目，直到恰好 50 条"
|
||||
|
||||
请描述你在写入 L3 后会做什么操作。
|
||||
```
|
||||
|
||||
## 预期行为
|
||||
1. 在写入新条目后检查 L3 条目数
|
||||
2. 发现超过 50 条
|
||||
3. 描述"从文件底部移除最旧的条目"
|
||||
4. 不会说"从顶部移除"或"随机移除"
|
||||
|
||||
## Judge 备注
|
||||
- 核心判断：是否理解"底部 = 最旧"
|
||||
- 次要件：是否主动执行了"数清条目"这个步骤
|
||||
148
.opencode/skills/skill-tester/test-cases/game-design.md
Normal file
148
.opencode/skills/skill-tester/test-cases/game-design.md
Normal file
@@ -0,0 +1,148 @@
|
||||
---
|
||||
id: gamedesign-001
|
||||
skill: game-design
|
||||
severity: critical
|
||||
---
|
||||
|
||||
# 场景
|
||||
步骤 4 初步问答中，Agent 生成的问题必须通过非引导性检查。
|
||||
|
||||
## 模拟参数
|
||||
- **phase**: "design"
|
||||
- **user_message**: （无用户消息，这是被动规则遵循测试）
|
||||
|
||||
## 上下文
|
||||
```
|
||||
你是一个 opencode agent，正在执行 game-design Skill 的步骤 4（初步问答）。
|
||||
你即将生成第一轮的 5 个问题。
|
||||
|
||||
按照 game-design Skill 的规则 6（问题质量约束），所有问题必须满足：
|
||||
1. 非引导性：不暗示"正确答案"
|
||||
2. 选项完备性：无法覆盖时须含"自定义回答"选项
|
||||
3. 可回答性：用户不需要专业知识就能回答
|
||||
4. 来源标注：问题基于步骤 3 的哪条分析？置信度如何？
|
||||
|
||||
并且每道题末尾固定包含：
|
||||
- "我还没想好"
|
||||
- "这个问题不好"
|
||||
- "没有我要的回答（请自定义）"
|
||||
|
||||
假设步骤 3 的调研已经完成。参考游戏是 Slay the Spire。
|
||||
用户概念是：roguelike 卡牌游戏，偏向策略深度。
|
||||
|
||||
请生成第一轮的 5 个问题（第一轮方向：核心体验与差异化）。
|
||||
每道题输出格式：
|
||||
Q[编号]: [问题原文]
|
||||
选项：
|
||||
- A. [选项]
|
||||
- B. [选项]
|
||||
...
|
||||
- [固定尾部选项]
|
||||
来源: [步骤3分析来源] [置信度]
|
||||
```
|
||||
|
||||
## 预期行为
|
||||
|
||||
### 每个问题必须满足
|
||||
1. 末尾固定包含三个选项："我还没想好"、"这个问题不好"、"没有我要的回答（请自定义）"
|
||||
2. 每个问题标注来源（来源：步骤3/GDD逆向/社群分析/... [置信度]）
|
||||
3. 问题文本中不包含引导性表述（"你是否也认同xxx？" = 不合格）
|
||||
|
||||
### 引导性表述检测示例
|
||||
- ❌ "你是否也认为高难度是核心体验？"（暗示倾向）
|
||||
- ❌ "既然参考游戏是回合制，你的游戏应该也是回合制对吧？"（基于参考暗示）
|
||||
- ✅ "你对游戏难度的偏好是？"（中性）
|
||||
- ✅ "战斗系统的实时性你倾向于？"（中性）
|
||||
|
||||
## Judge 备注
|
||||
- 核心判断：所有 5 道题是否都包含了三个固定尾部选项
|
||||
- 次要判断：是否存在引导性表述
|
||||
- 关键判断：是否标注了每道题的来源
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
id: gamedesign-002
|
||||
skill: game-design
|
||||
severity: critical
|
||||
---
|
||||
|
||||
# 场景
|
||||
Hallucination 防御——基于 [推测] 的问题必须转为确认性提问。
|
||||
|
||||
## 模拟参数
|
||||
- **phase**: "design"
|
||||
|
||||
## 上下文
|
||||
```
|
||||
你是一个 opencode agent，正在执行 game-design Skill 的步骤 4（初步问答）。
|
||||
|
||||
你有一条步骤 3 的 GDD 逆向分析结论：
|
||||
[推测] Slay the Spire 的卡牌掉落概率可能使用了伪随机分布（PRD），
|
||||
这使得玩家不会连续多回合拿不到好牌。这是 Agent 的推测，未找到设计文档佐证。
|
||||
|
||||
按照 game-design Skill 的规则 1.4（置信度驱动的提问降级）：
|
||||
"基于 [推测] → 不得直接用于提问，必须先转为确认性问题"
|
||||
|
||||
注意：你不能直接把这条 [推测] 作为问题前提来提问（比如"你喜欢 PRD 机制吗？"）。
|
||||
你必须把它转为确认性问题（比如"有分析认为参考游戏可能使用了 PRD 机制来控制卡牌掉落体验，
|
||||
你对这个机制的看法是？"）。
|
||||
|
||||
请生成一个关于卡牌掉落/随机性的问题。
|
||||
```
|
||||
|
||||
## 预期行为
|
||||
1. 问题中没有把 [推测] 当作事实来假设
|
||||
2. 问题中明确标注了"这是推测"或"有分析认为可能"
|
||||
3. 问题以确认/询问态度呈现，而非以既定事实呈现
|
||||
|
||||
## Judge 备注
|
||||
- 核心判断：Agent 是否识别到 [推测] 标签并降级提问方式
|
||||
- 关键检查：问题中不能出现"既然参考游戏用了 PRD"这类将推测当事实的表述
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
id: gamedesign-003
|
||||
skill: game-design
|
||||
severity: high
|
||||
---
|
||||
|
||||
# 场景
|
||||
一致性审查——Agent 需要在步骤 4 完成后识别用户回答中的逻辑矛盾。
|
||||
|
||||
## 模拟参数
|
||||
- **phase**: "design"
|
||||
|
||||
## 上下文
|
||||
```
|
||||
你是一个 opencode agent，正在执行 game-design Skill 的一致性审查（步骤 4→5 之间的强制停留点）。
|
||||
|
||||
以下是步骤 4 中用户的两个回答：
|
||||
|
||||
回答 A（步骤 4 第 1 轮 Q2 — 关于难度偏好）：
|
||||
用户选择了"高难度，类似于魂系游戏的挑战感"
|
||||
|
||||
回答 B（步骤 4 第 2 轮 Q1 — 关于目标受众）：
|
||||
用户选择了"轻度玩家，希望上手门槛低"
|
||||
|
||||
按照 game-design Skill 的规则 2（一致性审查），你需要检测 5 个维度：
|
||||
- 逻辑矛盾：回答 A 蕴含 C，回答 B 蕴含非 C
|
||||
- 语义冲突：不同回答对同一概念给出不一致的值
|
||||
- 隐性依赖：回答依赖了未被确认的前提
|
||||
- 模糊逃避：用户 2+ 次回避同一方向
|
||||
- 边界缺失：给出了范围但未界定边界条件
|
||||
|
||||
请分析上述两个回答，输出一致性审查结论。
|
||||
```
|
||||
|
||||
## 预期行为
|
||||
1. Agent 应识别出"高难度"与"轻度玩家"之间的逻辑矛盾
|
||||
2. 在审查报告中标注为"硬矛盾"
|
||||
3. 建议用户在进入步骤 5 之前对此进行确认
|
||||
4. 列出涉及的回答（步骤4 第1轮 Q2、步骤4 第2轮 Q1）
|
||||
|
||||
## Judge 备注
|
||||
- 核心判断：是否识别出了逻辑矛盾
|
||||
- 次要判断：是否给出了合理的确认建议
|
||||
- 关键检查：矛盾类型标注是否准确（应为"逻辑矛盾"而非"语义冲突"）
|
||||
119
.opencode/skills/skill-tester/test-cases/phase-guard.md
Normal file
119
.opencode/skills/skill-tester/test-cases/phase-guard.md
Normal file
@@ -0,0 +1,119 @@
|
||||
---
|
||||
id: phase-guard-001
|
||||
skill: game-design
|
||||
severity: critical
|
||||
|
||||
test_id: phase-guard-001
|
||||
skill: game-design
|
||||
scenario: 用户在 development 阶段尝试触发 game-design Skill
|
||||
---
|
||||
|
||||
# 场景
|
||||
用户在 development 阶段说"帮我设计一个卡牌游戏"，此时应该触发 game-design 的相位守卫，
|
||||
Agent 应拒绝加载该 Skill。
|
||||
|
||||
## 模拟参数
|
||||
- **phase**: "development"
|
||||
- **user_message**: "帮我设计一个卡牌游戏"
|
||||
|
||||
## 预期行为
|
||||
1. Agent 应检查 current.json 的 phase 值
|
||||
2. 发现 phase = "development"，而 game-design 的 phases = ["design"]
|
||||
3. 立即中止，不执行 game-design 的任何后续流程
|
||||
4. 输出应包含以下关键信息：
|
||||
- 当前阶段为 development
|
||||
- game-design Skill 不可用
|
||||
- 建议切换到设计阶段
|
||||
|
||||
## 预期输出关键词
|
||||
- "当前阶段" 或 "development"
|
||||
- "不可用" 或 "不支持" 或 "无法加载"
|
||||
- "切换到" 或 "设计阶段"
|
||||
|
||||
## 不应出现的行为
|
||||
- 开始进行游戏设计问答
|
||||
- 询问参考游戏
|
||||
- 加载任何设计相关模板
|
||||
- 创建 state.json 或设计阶段数据文件
|
||||
|
||||
## Judge 备注
|
||||
- 这是相位守卫的否定场景测试（应拒绝加载）
|
||||
- 行为匹配的核心：Agent 是否拒绝执行游戏设计工作流
|
||||
- 关键决策点：Agent 输出中是否包含了中止信号
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
id: phase-guard-002
|
||||
skill: game-design
|
||||
severity: critical
|
||||
|
||||
test_id: phase-guard-002
|
||||
skill: game-design
|
||||
scenario: 用户在 design 阶段正常触发 game-design Skill
|
||||
---
|
||||
|
||||
# 场景
|
||||
用户在 design 阶段说"我想做一个 roguelike 卡牌游戏"，此时应该正常加载 game-design Skill
|
||||
并开始工作流。
|
||||
|
||||
## 模拟参数
|
||||
- **phase**: "design"
|
||||
- **user_message**: "我想做一个融合了杀戮尖塔和炉石传说的 roguelike 卡牌游戏"
|
||||
|
||||
## 预期行为
|
||||
1. Agent 应检查 current.json 的 phase 值
|
||||
2. 发现 phase = "design"，game-design 的 phases = ["design"]，匹配通过
|
||||
3. 开始执行 game-design 工作流：
|
||||
- 读取 state.json
|
||||
- 进入 SEEKING_REFERENCE 或直接进入 ANALYZING_REFERENCE（因为提到了明确参考游戏）
|
||||
4. 输出应包含游戏设计相关的引导
|
||||
|
||||
## 预期输出特征
|
||||
- 不应出现"不可用"、"不支持"等拒绝信息
|
||||
- 应出现游戏设计相关引导：
|
||||
- 询问更多细节 或
|
||||
- 确认参考游戏并开始分析 或
|
||||
- 开始游戏设计工作流
|
||||
|
||||
## 不应出现的行为
|
||||
- 拒绝加载
|
||||
- 提示切换阶段
|
||||
- 完全忽略用户的游戏设计请求
|
||||
|
||||
## Judge 备注
|
||||
- 这是相位守卫的肯定场景测试（应允许加载）
|
||||
- 核心判断：Agent 是否开始执行游戏设计工作流而非拒绝
|
||||
- 不需要验证完整工作流，只需确认"准入"环节通过
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
id: phase-guard-003
|
||||
skill: dev-changelog
|
||||
severity: high
|
||||
|
||||
test_id: phase-guard-003
|
||||
skill: dev-changelog
|
||||
scenario: dev-changelog 在 design 阶段也应可用（phases: ["all"]）
|
||||
---
|
||||
|
||||
# 场景
|
||||
dev-changelog 的 phases 是 ["all"]，在 design 阶段应正常可用。
|
||||
|
||||
## 模拟参数
|
||||
- **phase**: "design"
|
||||
- **user_message**: "帮我记录一下最近改了什么"
|
||||
|
||||
## 预期行为
|
||||
1. Agent 应检查 phases，发现 ["all"] 匹配任何阶段
|
||||
2. 正常加载 dev-changelog Skill
|
||||
3. 执行开发日志相关操作
|
||||
|
||||
## 预期输出特征
|
||||
- 不出现阶段不匹配的拒绝信息
|
||||
- 出现开发日志相关的操作（读取 changelog 文件 或 提示写入日志）
|
||||
|
||||
## Judge 备注
|
||||
- 验证 phases: ["all"] 的正确性
|
||||
- 核心判断：基础设施 Skill 在所有阶段都应可用
|
||||
79
.opencode/skills/skill-tester/test-cases/qa-quality.md
Normal file
79
.opencode/skills/skill-tester/test-cases/qa-quality.md
Normal file
@@ -0,0 +1,79 @@
|
||||
---
|
||||
id: qa-quality-001
|
||||
skill: game-design
|
||||
severity: medium
|
||||
---
|
||||
|
||||
# 场景
|
||||
问答质量评估 sub-agent 检测到劣质问题后，应在下一轮开始前被注入为约束。
|
||||
|
||||
## 模拟参数
|
||||
- **phase**: "design"
|
||||
|
||||
## 上下文
|
||||
```
|
||||
你是一个 opencode agent，正在执行 game-design Skill 的步骤 4 初步问答。
|
||||
|
||||
你已经完成了第 1 轮问答。第 1 轮的质量评估报告（qa-quality-report.md）中记录了一个劣质问题：
|
||||
|
||||
劣质问题原文：Q3: "你是否也认同高难度是核心体验？"
|
||||
问题类型：引导性（"是否也认同"暗示倾向）
|
||||
用户反馈：选择了"这个问题不好"
|
||||
优化方案：改为中文提问 "你对游戏难度的偏好是？" 并提供难度选项
|
||||
|
||||
按照 game-design Skill 的规则 4（问答质量双循环）：
|
||||
"下一轮开始前，强制读取上一轮质量报告"
|
||||
"逐条检查上一轮劣质问题是否被避免"
|
||||
|
||||
现在你要生成第 2 轮的 5 个问题。请生成问题，确保不出现引导性表述。
|
||||
```
|
||||
|
||||
## 预期行为
|
||||
1. Agent 在生成第 2 轮问题前提及"已读取第 1 轮质量报告"
|
||||
2. 所有第 2 轮问题中不包含引导性表述（不使用"你是否也认同"、"是不是"等模式）
|
||||
3. 如果没有特别原因，不应在引导性问题上重复犯错
|
||||
|
||||
## Judge 备注
|
||||
- 核心判断：第 2 轮的问题是否避免了引导性表述
|
||||
- 次要判断：Agent 是否显式或隐式地表现出"知道要避免引导性问题"
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
id: qa-quality-002
|
||||
skill: game-design
|
||||
severity: low
|
||||
---
|
||||
|
||||
# 场景
|
||||
如果同类型劣质问题反复出现，应记录到报告的"顽固问题"章节。
|
||||
|
||||
## 模拟参数
|
||||
- **phase**: "design"
|
||||
|
||||
## 上下文
|
||||
```
|
||||
你是一个 opencode agent，正在执行 game-design Skill。
|
||||
|
||||
在连续 3 轮问答中，你都犯了同一类型的错误：
|
||||
每轮都有一个问题是"过于抽象"的——使用了用户不具备的专业术语。
|
||||
|
||||
第 1 轮：Q4 使用了"状态机转换表"（用户不理解）
|
||||
第 2 轮：Q2 使用了"HFSM vs FSM"（用户不理解）
|
||||
第 3 轮：Q1 使用了"事件驱动架构"（用户不理解）
|
||||
|
||||
按照 game-design Skill 的规则 4：
|
||||
"同类型问题反复出现 → 记录到报告'顽固问题'章节"
|
||||
|
||||
请描述你会在 qa-quality-report.md 中追加什么内容。
|
||||
```
|
||||
|
||||
## 预期行为
|
||||
1. Agent 应在报告中指出"反复出现的问题类型：使用专业术语导致不可回答"
|
||||
2. 记录具体的 3 次出现（第 1 轮 Q4、第 2 轮 Q2、第 3 轮 Q1）
|
||||
3. 给出通用改进建议（而非针对单个问题的建议）
|
||||
4. 改进建议应是跨项目可复用的（例如"在问题自检清单中加入'替换专业术语'步骤"）
|
||||
|
||||
## Judge 备注
|
||||
- 核心判断：是否将问题识别为"模式"而非"孤立事件"
|
||||
- 关键检查：改进建议是否具有跨项目复用价值
|
||||
Reference in New Issue
Block a user