diff --git a/.opencode/canonical-manifest.json b/.opencode/canonical-manifest.json index 750238e..890ea36 100644 --- a/.opencode/canonical-manifest.json +++ b/.opencode/canonical-manifest.json @@ -19,7 +19,9 @@ ".opencode/skills/pitfall-journal/", ".opencode/skills/problem-distillery/", ".opencode/skills/profile-memory/", - ".opencode/skills/spec-docs/" + ".opencode/skills/spec-docs/", + ".opencode/skills/game-design/", + ".opencode/skills/skill-tester/" ], "template_data_files": [ ".opencode/data/changelog/changelog-full.md", @@ -36,10 +38,19 @@ ".opencode/data/profile/project-profile-log.md", ".opencode/data/spec-docs/state.json" ], + "template_phase_files": [ + ".opencode/phase/current.json", + ".opencode/phase/data/design/state.json", + ".opencode/phase/data/design/concept.md", + ".opencode/phase/data/design/design-outline.md", + ".opencode/phase/data/design/qa-quality-report.md", + ".opencode/phase/data/design/reference-analysis/gdd-reverse.md", + ".opencode/phase/data/design/reference-analysis/community-iteration.md" + ], "cleanup_delete_patterns": [ { "pattern": ".opencode/*.log", "note": "调试日志" }, { "pattern": ".opencode/_init-backup/", "note": "上一轮冲突备份残留" }, - { "pattern": ".opencode/_gitignore-preview", "note": "阶段 5.5 临时预览文件" } + { "pattern": ".opencode/skills/skill-tester/reports/*.md", "note": "测试报告（运行时产物）" } ], "sentinel": ".opencode/.init-done" } diff --git a/.opencode/phase/current.json b/.opencode/phase/current.json new file mode 100644 index 0000000..dfe4c0d --- /dev/null +++ b/.opencode/phase/current.json @@ -0,0 +1,5 @@ +{ + "phase": "design", + "switched_at": null, + "previous_phase": null +} diff --git a/.opencode/phase/data/design/concept.md b/.opencode/phase/data/design/concept.md new file mode 100644 index 0000000..e69de29 diff --git a/.opencode/phase/data/design/design-outline.md b/.opencode/phase/data/design/design-outline.md new file mode 100644 index 0000000..e69de29 diff --git a/.opencode/phase/data/design/qa-quality-report.md b/.opencode/phase/data/design/qa-quality-report.md new file mode 100644 index 0000000..9eb0b1d --- /dev/null +++ b/.opencode/phase/data/design/qa-quality-report.md @@ -0,0 +1,17 @@ +# 问答质量评估报告 + +本文件记录设计工作流中每轮问答的质量评估结果。每次评估追加，不覆盖。 + +## 评估维度 + +- **劣质问题类型**：引导性 / 过于抽象 / 遗漏选项 / 不可回答 / 基于推测 +- **问题原文**：保留用户质疑的原问题 +- **用户反馈**：用户的具体质疑或自定义回答 +- **优化方案**：改进后的提问方式 +- **通用建议**：可跨项目复用的经验 + +--- + +## 质量报告 + + diff --git a/.opencode/phase/data/design/reference-analysis/community-iteration.md b/.opencode/phase/data/design/reference-analysis/community-iteration.md new file mode 100644 index 0000000..e69de29 diff --git a/.opencode/phase/data/design/reference-analysis/gdd-reverse.md b/.opencode/phase/data/design/reference-analysis/gdd-reverse.md new file mode 100644 index 0000000..e69de29 diff --git a/.opencode/phase/data/design/state.json b/.opencode/phase/data/design/state.json new file mode 100644 index 0000000..e2f699d --- /dev/null +++ b/.opencode/phase/data/design/state.json @@ -0,0 +1,15 @@ +{ + "workflow_state": "WAITING_FOR_CONCEPT", + "concept_summary": "", + "reference_games": [], + "in_progress": { + "active": false, + "operation": null, + "started_at": null, + "detail": null + }, + "checkpoints": [], + "sessions": [], + "created_at": null, + "updated_at": null +} diff --git a/.opencode/skills/deferred-decisions/SKILL.md b/.opencode/skills/deferred-decisions/SKILL.md index 2d05939..925034c 100644 --- a/.opencode/skills/deferred-decisions/SKILL.md +++ b/.opencode/skills/deferred-decisions/SKILL.md @@ -1,5 +1,6 @@ --- name: deferred-decisions +phases: ["all"] description: >- 记录开发中被延期的技术方案/决策，并在关联任务出现时主动提醒用户。 当对话中出现"以后再做"、"先不做"、"defer"、"延期方案"、"备选方案"、 diff --git a/.opencode/skills/dev-changelog/SKILL.md b/.opencode/skills/dev-changelog/SKILL.md index 6d694dd..c046322 100644 --- a/.opencode/skills/dev-changelog/SKILL.md +++ b/.opencode/skills/dev-changelog/SKILL.md @@ -1,5 +1,6 @@ --- name: dev-changelog +phases: ["all"] description: >- 三层开发进程记录系统。在 Agent 完成代码改动后自动记录，提供从一句话概要到完整日志的 多级上下文，帮助 Agent 在跨会话场景下保持对项目开发进展的感知。 diff --git a/.opencode/skills/epee-orchestrator/SKILL.md b/.opencode/skills/epee-orchestrator/SKILL.md index 943bf6c..a5c9d41 100644 --- a/.opencode/skills/epee-orchestrator/SKILL.md +++ b/.opencode/skills/epee-orchestrator/SKILL.md @@ -1,5 +1,6 @@ --- name: epee-orchestrator +phases: ["all"] description: >- EPEE Skill Orchestrator：元层调度系统。检测任务是否可由已有 Skill 处理并分流， 或发现 Skill 缺口并引导创建新 Skill。当 Agent 遇到手动配置密集、重复模式明确、 diff --git a/.opencode/skills/epee-orchestrator/registry.md b/.opencode/skills/epee-orchestrator/registry.md index d8dcd09..8c1259e 100644 --- a/.opencode/skills/epee-orchestrator/registry.md +++ b/.opencode/skills/epee-orchestrator/registry.md @@ -76,3 +76,19 @@ - **输出**: docs/ 下 architecture/conventions/specs/reference 子目录的规范文档、.opencode/data/spec-docs/state.json、审查报告 - **路径**: .opencode/skills/spec-docs/SKILL.md - **备注**: 操作 B 具备 changelog 不可信假设与代码搜索 fallback 的互斥检测能力 + +### game-design +- **类型**: 项目级 +- **能力**: 游戏设计全流程辅助系统 — 从创意概念到设计大纲，通过参考游戏分析（GDD 逆向 + 社群口碑）、3 轮 × 5 题初步问答、一致性审查、3+ 轮深度问答，最终产出包含 VISTA 框架的设计大纲 +- **触发场景**: "我想做一个xxx游戏"、"设计一个xxx玩法"、"帮我设计游戏"、用户提出游戏创意时；仅在 `design` 阶段可用 +- **输出**: `.opencode/phase/data/design/` 下的 state.json、concept.md、reference-analysis/*.md、qa-initial/*.md、qa-deep/*.md、design-outline.md、qa-quality-report.md +- **路径**: .opencode/skills/game-design/SKILL.md +- **备注**: 仅 `phases: ["design"]`；内建 Hallucination 三级防御（置信度标注+来源锚定+局限性声明）、一致性审查（5 维度矛盾检测）、不可逆决策标记、问答质量预防+反馈双循环、事务化状态管理；支持跨会话恢复 + +### skill-tester +- **类型**: 基础设施 +- **能力**: SKILL 体系自动化回归测试工具 — 基于 LLM-as-Judge 模式模拟 Agent 行为并评分，验证 Skill 的阶段守卫、规则遵循、输出格式等维度，支持单 Skill 测试和全量回归 +- **触发场景**: "测试Skill"、"测试 [Skill名]"、"回归测试"、"skill test"、"跑测试"、"测试覆盖率" +- **输出**: skill-tester/reports/ 下的测试报告、每个用例的评分 JSON +- **路径**: .opencode/skills/skill-tester/SKILL.md +- **备注**: `phases: ["all"]`；测试分两层——Layer 1 静态文件合规检查（未来实现）、Layer 2 LLM-as-Judge 行为测试（本 Skill 实现）；不测试 opencode 的 Skill 加载机制本身，仅测试 SKILL.md 中的指令逻辑 diff --git a/.opencode/skills/game-design/SKILL.md b/.opencode/skills/game-design/SKILL.md new file mode 100644 index 0000000..50d747f --- /dev/null +++ b/.opencode/skills/game-design/SKILL.md @@ -0,0 +1,158 @@ +--- +name: game-design +phases: ["design"] +description: >- + 游戏设计全流程辅助系统。从创意概念到设计大纲，通过参考游戏分析、多轮结构化问答、 + 一致性审查和深度探索，帮助设计师系统化地完成游戏设计前期工作。 +--- + +# 相位守卫（Phase Guard） + +**本 Skill 加载后的首个强制动作：** +1. 读取 `.opencode/phase/current.json` +2. 若 `phases` 不包含 `"all"` 且当前 `phase` 值不在 `phases` 列表中： + - 立即中止，输出："当前阶段为 [phase]，game-design Skill 不可用。请切换到设计阶段。" + - 不得执行本 Skill 的任何后续流程 +3. 否则：继续执行 + +--- + +# 状态机速查 + +| 状态 | 含义 | 下一状态 | +|------|------|---------| +| `WAITING_FOR_CONCEPT` | 等待用户提出游戏概念 | `SEEKING_REFERENCE` | +| `SEEKING_REFERENCE` | 询问参考游戏 | `ANALYZING_REFERENCE` / `SEARCHING_REFERENCES` | +| `SEARCHING_REFERENCES` | 搜索推荐参考游戏 | `SEEKING_REFERENCE`（用户选定） / `INITIAL_QA`（无参考模式） | +| `FALLBACK_SEARCH` | 搜索其他媒介参考 | `SEEKING_REFERENCE`（找到） / `INITIAL_QA`（未找到，经提示后继续） | +| `ANALYZING_REFERENCE` | 并行 sub-agent 反拆参考游戏 | `DEVILS_ADVOCATE` | +| `DEVILS_ADVOCATE` | 设计前提挑战 | `INITIAL_QA` | +| `INITIAL_QA` | 3 轮 × 5 题初步问答 | `CONSISTENCY_CHECK` | +| `CONSISTENCY_CHECK` | 一致性审查 | `DEEP_QA`（通过） / `INITIAL_QA`（有矛盾需回退） | +| `DEEP_QA` | 3+ 轮不限数量深度问答 | `COMPLETED` | +| `COMPLETED` | 生成设计大纲 | -（结束） | + +**状态文件位置**：`.opencode/phase/data/design/state.json` + +--- + +# 启动入口 + +## 触发条件 + +当前 phase 为 `design`，且用户表达了创建游戏的意图。触发关键词族： +- "我想做一个...游戏" / "设计一个...玩法" / "我有一个游戏想法" +- "帮我设计..." / "开始游戏设计" +- 或 Agent 从对话中检测到用户正在系统化地讨论一个新游戏的构思 + +## 入口行为 + +1. 读取 `state.json` 判断当前工作流状态 +2. 若已有进行中的工作流 → 从当前状态恢复 +3. 若首次使用 → 设置 `WAITING_FOR_CONCEPT`，提示用户描述游戏创意 + +## 退出条件 + +用户主动表示"退出设计"、"切换到XX阶段"、"暂停设计" → 保存当前状态到 state.json，正常退出。 + +--- + +# 步骤分发 + +各步骤的详细执行指令在独立模板文件中，仅在进入该步骤时读取： + +| 步骤 | 文件 | +|------|------| +| 步骤 1-2：参考游戏发现 | `templates/reference-search-prompt.md` | +| 步骤 3：反拆分析 | `prompts/sub-agent-gdd-reverse.md` + `prompts/sub-agent-community.md` | +| 步骤 4：初步问答 | `templates/qa-initial-questions.md` | +| 步骤 5：深度问答 | `templates/qa-deep-guide.md` | +| 设计前提挑战 | `templates/devils-advocate.md` | +| 输出：设计大纲 | `templates/design-outline-template.md` | + +--- + +# 跨步骤强制规则 + +## 规则 1：Hallucination 防御（三步走） + +### 1.1 输出标注 +所有 sub-agent 产出必须对每条声明标注置信度： +- `[确认]` — 有明确来源 URL +- `[推断]` — 有间接证据但未经逐字确认 +- `[推测]` — 无来源，纯推理 + +### 1.2 来源锚定 +`[确认]` 条目必须附带来源 URL，无 URL 则最高标为 `[推断]`。 + +### 1.3 局限性声明 +每个 sub-agent 产出末尾必须包含"局限性声明"章节，列出未能找到确切来源的设计点和建议用户独立验证的清单。 + +### 1.4 置信度驱动的提问降级 +- 基于 `[确认]` → 正常提问 +- 基于 `[推断]` → 问题中标注"以下问题基于推断，如有偏差请指出" +- 基于 `[推测]` → 不得直接用于提问，必须先转为确认性问题 + +## 规则 2：一致性审查（强制停留点） + +步骤 4 完成后、步骤 5 开始前，**必须执行**一致性审查，不可跳过。 + +检测维度： +- **逻辑矛盾**：回答 A 蕴含 C，回答 B 蕴含非 C +- **语义冲突**：不同回答对同一概念给出不一致的值 +- **隐性依赖**：回答依赖了未被确认的前提 +- **模糊逃避**：用户 2+ 次回避同一方向的提问 +- **边界缺失**：给出了范围但未界定边界条件 + +审查输出到用户面前： +- 硬矛盾 > 0 → 必须让用户确认后才能进入步骤 5 +- 只有弱信号 → 可进入步骤 5，弱信号作为首批高优先级提问 + +## 规则 3：不可逆决策标记 + +步骤 5 中，Agent 检测用户的回答是否构成不可逆设计决策： +- 🔴 不可逆：一旦确认极难回退（如 2D vs 3D、买断 vs F2P） +- 🟠 高成本回退：回退需要大量返工（如多人支持、引擎选型） +- 🟢 可回退：后期调整成本低（如 UI 风格） + +检测到不可逆决策时，必须明示确认："你刚才的回答可能构成一个不可逆的设计决策，因为[原因]。你确认吗？" + +## 规则 4：问答质量双循环 + +### 预防层 +问题生成前自检：非引导性、选项完备性、可回答性、来源标注。 + +### 反馈层 +每轮结束后： +1. 并行 sub-agent 生成本轮质量报告 → 写入 `qa-quality-report.md` +2. 下一轮开始前，**强制读取**上一轮质量报告 +3. 逐条检查上一轮劣质问题是否被避免 +4. 同类型问题反复出现 → 记录到报告"顽固问题"章节 + +## 规则 5：状态事务化（写入前先标记 in_progress） + +任何状态写入前： +1. 设置 `state.json` 的 `in_progress` 字段 +2. 执行写入操作 +3. 成功后清除 `in_progress`，记录 checkpoint +4. 若 Agent 恢复时发现 `in_progress.active = true` → 提示用户上次中断，从最近的 checkpoint 恢复 + +## 规则 6：问题质量约束 + +所有生成的问题必须满足： +1. **非引导性**：不暗示"正确答案" +2. **选项完备性**：无法覆盖时须含"自定义回答"选项 +3. **可回答性**：用户不需要专业知识就能回答 +4. **来源标注**：问题基于步骤 3 的哪条分析？置信度如何？ + +## 规则 7：进度提示 + +Sub-agent 执行期间不得沉默： +- 开始前：告知用户 sub-agent 正在执行什么任务，预计用时 +- 完成后：告知产物文件路径，等待用户确认 + +--- + +# 自迭代日志 + +本节记录使用本 Skill 过程中发现的必要检查项。 diff --git a/.opencode/skills/game-design/prompts/sub-agent-community.md b/.opencode/skills/game-design/prompts/sub-agent-community.md new file mode 100644 index 0000000..877fde2 --- /dev/null +++ b/.opencode/skills/game-design/prompts/sub-agent-community.md @@ -0,0 +1,109 @@ +# Sub-agent 提示：社群口碑与品类迭代分析 + +你是一个游戏市场分析师（Game Market Analyst）。你的任务是收集一款指定参考游戏的 +社群反馈和同品类市场迭代情况。 + +## 核心原则 + +### Hallucination 防御（强制执行） +每一条声明必须标注以下置信度标签之一： +- **[确认]** — 有明确来源 URL（必须附带 URL） +- **[推断]** — 来源于间接证据，标注推理依据 +- **[推测]** — 纯推理，无任何来源 + +没有来源 URL 的条目不得标注为 [确认]，最高只能标 [推断]。 + +## 输入 + +- **参考游戏名称**：[由主 Agent 提供] +- **参考游戏发布时间**：[由主 Agent 提供] +- **用户游戏概念**：[由主 Agent 提供，用于聚焦分析方向] + +## 研究维度 + +### 1. 好评分析（TOP 5 好评点 + 深层原因） +- 找出玩家最常提及的 5 个好评点 +- 每个好评点的**深层原因**：为什么这个设计赢得了玩家的认可？ + （不止是"战斗很爽"，而是"因为 X 机制让 Y 行为产生了 Z 反馈"） +- 好评点是否与你用户的游戏概念有交集？ + +### 2. 差评分析（TOP 5 差评点 + 设计根因） +- 找出玩家最常提及的 5 个差评点 +- 每个差评点的**设计根因推测**：这个差评是设计的 bug 还是 feature？ + - 如果是 bug → 这个 bug 能否在设计中规避？ + - 如果是 feature（设计师有意为之但玩家不喜欢）→ 交替方案是什么？ +- 差评点是否与你的用户概念有潜在冲突？ + +### 3. 用户"还想要什么"（未满足的需求） +- 社群中最常出现的"希望加入/改进"的呼声 +- 这些呼声反映了什么未被满足的设计需求？ +- MOD 社区中高频出现的内容方向（MOD 往往是未满足需求的自发回应） + +### 4. 同品类成功迭代产品（3-5 个） +- 参考游戏发布后，有哪些同品类的成功产品？ +- 每个成功产品的主要迭代点是什么？（在参考游戏的基础上改了什么？） +- 迭代方向分类：机制深化 / 简化 / 融合其他品类 / 叙事突破 / 技术升级 + +### 5. 同品类失败产品（2-3 个） +- 有哪些同品类尝试但失败的产品？ +- 失败原因分析：抄袭太像 / 改了不该改的 / 改了但没改到位 / 市场时机 / 品质问题 +- 失败案例对你的用户概念有什么警示意义？ + +## 输出格式 + +```markdown +# [游戏名] — 社群口碑与品类迭代分析 + +> 分析时间：[timestamp] +> 分析方法：主要基于 [Agent 已有知识 / Web 搜索] + +--- + +## 1. 好评 TOP 5 +| # | 好评点 | 深层原因 | 与你概念的关联 | 置信度 | 来源 | +|---|--------|---------|--------------|--------|------| +| 1 | ... | ... | ... | [确认/推断/推测] | [URL] | +| ... | ... | ... | ... | ... | ... | + +## 2. 差评 TOP 5 +| # | 差评点 | 设计根因 | 潜在规避方案 | 置信度 | 来源 | +|---|--------|---------|-------------|--------|------| +| 1 | ... | ... | ... | [确认/推断/推测] | [URL] | +| ... | ... | ... | ... | ... | ... | + +## 3. 未满足的需求 +| # | 呼声 | 反映的设计需求 | MOD/社区回应 | 置信度 | +|---|------|--------------|-------------|--------| +| 1 | ... | ... | ... | ... | + +## 4. 成功迭代产品 +### [产品名] [年份] +- **迭代点**：[在参考游戏基础上做了什么] +- **迭代方向**：[机制深化 / 简化 / 融合 / 叙事 / 技术] +- **市场表现**：[大致数据] +- **置信度**：[确认/推断/推测] + +### ... + +## 5. 失败产品 +### [产品名] [年份] +- **失败原因**：[具体分析] +- **警示**：[对你的概念的借鉴意义] +- **置信度**：[确认/推断/推测] + +### ... + +--- + +## 局限性声明 + +以下信息 Agent 未能从公开来源获取： +- [列出未能确认的代表性数据点] +- [列出 Agent 知识截止日期后发布的可能相关产品] + +建议用户在以下方面进行独立验证： +- [建议验证清单] +``` + +## 输出目标文件 +`.opencode/phase/data/design/reference-analysis/community-iteration.md` diff --git a/.opencode/skills/game-design/prompts/sub-agent-gdd-reverse.md b/.opencode/skills/game-design/prompts/sub-agent-gdd-reverse.md new file mode 100644 index 0000000..de62980 --- /dev/null +++ b/.opencode/skills/game-design/prompts/sub-agent-gdd-reverse.md @@ -0,0 +1,103 @@ +# Sub-agent 提示：GDD 逆向分析 + +你是一个游戏设计分析师（Game Design Analyst）。你的任务是深入研究一款指定的参考游戏， +产出一份结构化的 Game Design Document 逆向分析报告。 + +## 核心原则 + +### Hallucination 防御（强制执行） +每一条设计声明必须标注以下置信度标签之一： +- **[确认]** — 有明确来源 URL（必须附带 URL） +- **[推断]** — 来源于间接证据（社区讨论、开发者访谈、设计模式推理），标注推理依据 +- **[推测]** — 纯推理，无任何来源，这是你自己的设计推测 + +没有来源 URL 的条目不得标注为 [确认]，最高只能标 [推断]。 + +## 输入 + +- **参考游戏名称**：[由主 Agent 提供] +- **用户游戏概念**：[由主 Agent 提供，用于聚焦分析方向] + +## 研究维度 + +### 1. 核心游戏循环 (Core Loop) +- 玩家在一次完整的体验循环中做什么？（操作 → 反馈 → 决策 → 重复） +- 这个循环的节奏是怎样的？（紧张期 vs 放松期） +- 循环的"钩子"在哪里？（为什么玩家会想再玩一次） + +### 2. 系统架构 (Systems Architecture) +- 列出主要子系统及其职责 +- 子系统之间的依赖关系 +- 哪些系统是"必须的"？哪些是"锦上添花"的？ +- 哪些系统可以独立运作？哪些必须协同？ + +### 3. 经济与数值设计 (Economy & Numbers) +- 核心资源类型及其流转关系 +- 数值增长曲线的大致特征（线性/指数/S形/...） +- 平衡机制（正向反馈 vs 负向反馈） + +### 4. 叙事与世界观 (Narrative & World) +- 故事的讲述方式（环境叙事 / 对白驱动 / 碎片化 / 线性的） +- 世界观设定的深度和一致性 +- 叙事与玩法的关系（驱动/装饰/脱节的） + +### 5. UI/UX 设计模式 +- 信息架构（HUD、菜单、状态面板的结构） +- 玩家引导方式（教程、提示、渐进式解锁） +- 反直觉/被诟病的交互设计 + +### 6. 开创性设计点 +- **这个游戏做了什么别人没做的事？**（这是最重要的部分） +- 这个设计在当时解决了什么问题？ +- 为什么竞品没有/不能复制这个设计？ + +### 7. 设计意图推测 +- 基于以上分析，推测设计师的意图：为什么这样设计？ +- 哪些设计可能是妥协的结果？（技术限制、商业考量、时间压力） +- 区分"有意为之的设计选择"和"可能是意外的产物" + +## 输出格式 + +```markdown +# [游戏名] GDD 逆向分析 + +> 分析时间：[timestamp] +> 分析方法：主要基于 [Agent 已有知识 / Web 搜索]，知识截止于 [日期] + +--- + +## 1. 核心循环 +[内容，每条标注置信度] + +## 2. 系统架构 +[内容，每条标注置信度] + +## 3. 经济与数值 +[内容，每条标注置信度] + +## 4. 叙事与世界观 +[内容，每条标注置信度] + +## 5. UI/UX +[内容，每条标注置信度] + +## 6. 开创性设计点 +[内容，每条标注置信度] + +## 7. 设计意图推测 +[内容，每条标注置信度] + +--- + +## 局限性声明 + +以下信息 Agent 未能从公开来源获取，以下分析可能包含推测： +- [列出未能找到确切来源的设计点] +- [列出 Agent 知识截止日期后可能已变化的信息] + +建议用户在以下方面进行独立验证： +- [建议验证清单，每条对应一个高不确定性的结论] +``` + +## 输出目标文件 +`.opencode/phase/data/design/reference-analysis/gdd-reverse.md` diff --git a/.opencode/skills/game-design/templates/design-outline-template.md b/.opencode/skills/game-design/templates/design-outline-template.md new file mode 100644 index 0000000..a2d4422 --- /dev/null +++ b/.opencode/skills/game-design/templates/design-outline-template.md @@ -0,0 +1,132 @@ +# 设计大纲生成 — 最终输出模板 + +## 前置 + +步骤 5 全部完成，进入 `COMPLETED` 状态后生成。 + +## 输出文件 + +`.opencode/phase/data/design/design-outline.md` + +## 大纲结构 + +--- + +# 游戏设计大纲 + +> 基于步骤 4（初步问答）+ 步骤 5（深度问答）的设计方向总结。 +> 生成时间：[timestamp] + +--- + +## 一、设计方向摘要 + +仅根据问题与用户回答总结，**不含任何方案建议**。 +每一条标注来源，确保可追溯。 + +### 核心方向 + +| # | 设计意向 | 来源 | +|---|---------|------| +| 1 | [设计方向陈述] | 步骤4 第1轮 Q1 | +| 2 | [设计方向陈述] | 步骤5 第2轮 Q3 | +| ... | ... | ... | + +### 已确认的不可逆决策 + +| 决策 | 级别 | 确认来源 | 影响范围 | +|------|------|---------|---------| +| [2D 像素风格] | 🔴 不可逆 | 步骤5 第1轮 Q2 — 用户确认 | 美术管线、引擎选型、UI 设计 | +| ... | ... | ... | ... | + +### 设计约束 + +| 约束 | 来源 | 刚性程度 | +|------|------|---------| +| [团队 3 人 / 6 个月] | 步骤5 第1轮 Q1 | 硬约束 | +| [目标平台 iOS + Android] | 步骤4 第3轮 Q4 | 硬约束 | +| ... | ... | ... | + +--- + +## 二、设计方案 + +基于第一部分的 Agent 设计方案建议，包含 VISTA 框架。 + +### Vision（愿景） +[一句话核心体验承诺] + +### Interaction（交互） +- **核心输入**：[玩家在做什么] +- **核心反馈**：[游戏如何回应] +- **单次交互循环**：[一个完整的操作→反馈闭环] + +### Systems（系统架构） +``` +[核心系统 1] ←→ [核心系统 2] + ↕ ↕ +[子系统 A] [子系统 B] ← [子系统 C] +``` + +- **[系统名]**：[职责] + [与其他系统的关系] +- ... + +### Target（目标层次） +- **短期目标**：每分钟在做什么 +- **中期目标**：每局/每段的目标 +- **长期目标**：整个游戏进程的目标 + +### Aesthetics（美学） +- **视觉关键词**：[] +- **听觉关键词**：[] +- **总体氛围**：[] + +--- + +## 三、待明确核心问题 + +记录设计方向中不明确但**极其重要**的点。 + +| 优先级 | 问题 | 不可逆性 | 依赖 | 影响范围 | +|--------|------|---------|------|---------| +| P0 | [核心问题描述] | 🔴 / 🟠 / 🟢 | [哪些决策依赖此答案] | [影响哪些系统] | +| P1 | ... | ... | ... | ... | +| P2 | ... | ... | ... | ... | + +### 不可逆决策特别说明 +以下是设计中的 🔴不可逆 决策，请在进入开发阶段前再次确认： +1. [决策 1] — 一旦确认，后续开发将基于此假设，回退成本极高 +2. ... + +### 可以推迟到开发阶段的决策 +以下是 P2 及以下优先级的问题，可在开发阶段通过原型验证： +1. [问题 1] — 延迟原因：[] +2. ... + +--- + +## 四、开发阶段交接 + +自动生成，供开发阶段 Agent 参考。 + +### 优先级最高的技术任务 +1. [从不可逆决策中提取的第一优先级任务] +2. ... + +### 可并行的探索任务 +1. [可回退决策对应的原型验证] +2. ... + +### 设计阶段遗留的"待验证"项 +- [列出所有 [推测] 标记的低置信度条目，建议用原型验证] +- [列出 Devil's Advocate 环节的"弱信号"] + +--- + +## 生成约束 + +1. **第一部分必须是纯总结**，每条标注来源（步骤X 第Y轮 QZ），不包含 Agent 自己的建议 +2. **第二部分允许 Agent 发挥**，但每项建议在本段应有对应的用户回答依据 +3. **第三部分的优先级**必须经 Agent 判定（P0/P1/P2），不可全部标 P0 +4. **不可逆决策必须单独列出**并解释回退成本 +5. **第四部分**是给开发阶段 Agent 的交接，以"下一步行动"形式写，不重复前面的设计内容 diff --git a/.opencode/skills/game-design/templates/devils-advocate.md b/.opencode/skills/game-design/templates/devils-advocate.md new file mode 100644 index 0000000..c80fdb6 --- /dev/null +++ b/.opencode/skills/game-design/templates/devils-advocate.md @@ -0,0 +1,40 @@ +# 设计前提挑战 — Devil's Advocate + +## 位置 + +步骤 3（反拆分析）用户确认后，步骤 4（初步问答）开始前。 + +## 目的 + +在正式问答前，用 3-5 个挑战性问题检验用户核心设计前提的稳健性。 +这不是否定用户的想法，而是帮助发现被忽略的盲区。 + +## 语气约束 + +- 使用"挑战前提"而非"质疑" +- 使用"帮你发现盲区"而非"指出你的错误" +- 每条挑战附带一个建设性的探索方向 +- 如果用户对某个挑战表示坚持原方向，立即接受并记录为设计约束 + +## 问题生成逻辑 + +基于以下信息生成挑战： +1. 用户的初始概念描述 +2. 参考游戏的 GDD 逆向分析（特别是 [推断] 和 [推测] 标记的部分） +3. 社群分析中的差评点和失败案例 + +### 挑战角度 + +| 角度 | 示例问题模板 | +|------|------------| +| 内在矛盾 | "你提到想做 [A]，但参考游戏的社群反馈表明 [A] 与 [B] 往往冲突。你怎么看？" | +| 品类陷阱 | "[类似案例] 是 F2P + 硬核战斗的组合，结果遭遇了 [具体问题]。你考虑过这个风险吗？" | +| 参考惯性 | "参考游戏是 [单人/多人]，但你提到了 [相反的社交元素]。这两者在设计层面通常互相侵蚀。你的处理思路是？" | +| 可行性 | "参考游戏需要 [资源量] 的制作规模。以你预期的团队规模，这个方向的可实现性你如何评估？" | +| 差异化盲区 | "如果去掉参考游戏的 [核心特征]，你的游戏剩下什么？这可能是你最需要想清楚的部分。" | + +## 用户回答后的处理 + +- 有说服力的回应 → 将其作为设计约束，注入步骤 4 的问题生成 +- 回避/模糊的回应 → 记录为"弱信号"，带入一致性审查 +- 用户要求跳过 → 跳过，但记录"用户选择跳过挑战环节" diff --git a/.opencode/skills/game-design/templates/qa-deep-guide.md b/.opencode/skills/game-design/templates/qa-deep-guide.md new file mode 100644 index 0000000..0188bbf --- /dev/null +++ b/.opencode/skills/game-design/templates/qa-deep-guide.md @@ -0,0 +1,108 @@ +# 深度问答 — 步骤 5 执行模板 + +## 结构 + +3+ 轮，每轮问题数量不限，开放式问题为主。 + +## 前置条件 + +步骤 4 的 3 轮全部完成 + 一致性审查通过后，方可进入步骤 5。 + +## 每轮流程 + +``` +1. 读取一致性审查报告 +2. 读取步骤 4 全部回答（摘要形式，非全文） +3. 读取上一轮深度问答质量报告（如为首轮则跳过） +4. 生成本轮问题（不限数量） +5. 用户回答后 → 写入 qa-deep/round-N.md +6. 并行 sub-agent 生成本轮质量报告（追加到 qa-quality-report.md） +7. 提示用户可继续或暂停 +``` + +## 每轮方向 + +### 第一轮：设计约束与边界 +聚焦实际限制条件，将设计的"空中楼阁"落地： +- 团队规模与技能组合 +- 时间与预算约束 +- 技术限制（引擎、平台、性能） +- 目标平台的具体限制 +- IP 或合规约束 + +**关键动作**：在此轮中检测用户回答是否构成不可逆决策。 +若识别到 🔴不可逆 或 🟠高成本回退 的决策，必须明示确认。 + +### 第二轮：核心机制细化 +基于步骤 4 回答 + 第一轮约束，细化具体系统： +- 核心循环的具体规则 +- 关键数值的范围和比例 +- 系统间的依赖关系 +- 可能的技术实现难点 + +### 第三轮及以后：依赖关系梳理与边界测试 +- 系统 A 依赖系统 B 的哪部分决策？ +- 如果系统 C 在后期被砍掉，哪些系统受影响？ +- 设计的"单点故障"在哪里？（哪一个环节出问题会导致整体崩溃） +- 哪些决策可以推迟到开发阶段再做？哪些不行？ + +### 额外轮次触发条件 +- 一致性审查中有"弱信号"未解决 → 追加一轮聚焦解决 +- 用户在某轮出现了新的不稳定回答 → 追加一轮澄清 +- 核心问题（P0 优先级）仍有 ≥ 3 个未明确 → 追加一轮 + +## 不可逆决策检测 + +每道用户的回答，Agent 检测是否构成不可逆决策： + +``` +检测维度： +- 2D vs 3D → 🔴 不可逆（影响美术管线、引擎选型、全系统设计） +- 买断 vs F2P → 🔴 不可逆（影响经济系统、内容节奏、商业模式） +- 多人支持 → 🟠 高成本回退（影响网络架构、同步模型） +- 引擎选型 → 🟠 高成本回退（迁移成本极高） +- UI 风格 → 🟢 可回退（后期可迭代） +- 具体数值 → 🟢 可回退（可调参） + +若检测到 🔴 或 🟠 级别的决策： +"你刚才的回答可能构成一个 [级别] 的设计决策： +[决策内容] → 后果：[一旦确认/如需回退的代价]。 +你确认这个方向吗？" +``` + +## 问题类型 + +深度问答以开放式问题为主，不提供预设选项（除非是二选一的不可逆决策）： + +| 类型 | 适用场景 | 示例 | +|------|---------|------| +| 细化追问 | 步骤 4 回答太笼统 | "你说'中等难度'，能否具体到'核心循环中哪个环节最难'？" | +| 边界测试 | 探索设计的极限情况 | "如果资金只够做 50% 的内容，你优先保留哪部分？" | +| 依赖追踪 | 理清系统间关系 | "这个系统如果没做好，哪些系统会直接废掉？" | +| 矛盾解析 | 解决一致性审查中的硬矛盾 | "你同时想要 A 和 B，但它们通常冲突。你认为哪个优先级更高？" | +| 假设挑战 | 验证设计前提 | "如果去掉 [参考游戏的核心特征]，你的游戏还成立吗？" | + +## 问答记录格式 + +```markdown +# 步骤 5 — 第 N 轮深度问答 + +**时间**：[timestamp] +**轮次方向**：[设计约束 / 核心机制 / 依赖关系] +**本轮的不可逆决策检测**： +- 🔴 [决策内容] — 用户已确认 / 待确认 + +## Q1: [问题原文] +**问题类型**：[细化追问 / 边界测试 / 依赖追踪 / 矛盾解析 / 假设挑战] +**来源**：[基于步骤4第X轮QY的回答] +**用户回答**：[全文] + +## Q2: ... +``` + +## 终止条件 + +达到以下任一条件，可进入 COMPLETED 状态生成设计大纲： +1. 3 轮全部完成 +2. 用户主动表示"可以了，出大纲" +3. Agent 判断核心问题已充分明确（P0 问题 ≤ 1 个），且用户连续 2 轮没有给出新的模糊回答 diff --git a/.opencode/skills/game-design/templates/qa-initial-questions.md b/.opencode/skills/game-design/templates/qa-initial-questions.md new file mode 100644 index 0000000..bf834e1 --- /dev/null +++ b/.opencode/skills/game-design/templates/qa-initial-questions.md @@ -0,0 +1,92 @@ +# 初步问答 — 步骤 4 执行模板 + +## 结构 + +3 轮，每轮 5 个问题，每轮方向逐层深入。 + +## 每轮流程 + +``` +1. 读取上一轮质量报告（如为首轮则跳过） +2. 基于以下信息生成 5 个问题： + - 用户概念描述 + - 步骤 3 的调研结果（如有） + - Devil's Advocate 的结论（如有） + - 前一（几）轮用户的回答 +3. 每个问题提供 3-6 个选项 + 固定尾部选项 +4. 输出问题，等待用户回答 +5. 用户回答后 → 写入 qa-initial/round-N.md +6. 并行 sub-agent 生成本轮质量报告 +7. 提示用户："可以暂停，下次会话从当前进度继续" +``` + +## 每轮方向 + +### 第一轮：核心体验与差异化 +| # | 问题域 | 示例 | +|---|-------|------| +| 1 | 目标情感 | "你希望玩家在游戏结束后感受到什么？" | +| 2 | 难度曲线偏好 | "目标受众的游戏经验水平是？" | +| 3 | 单局/单次时长 | "一次完整的游戏体验你希望持续多久？" | +| 4 | 核心乐趣来源 | "游戏的'好玩'主要来自哪个维度？" | +| 5 | 差异化定位 | "与参考游戏相比，你最想改变的是什么？" | + +### 第二轮：系统与机制 +| # | 问题域 | 示例 | +|---|-------|------| +| 1 | 成长系统 | "玩家成长的驱动力主要来自？" | +| 2 | 随机性与可控性 | "随机要素的程度你偏好？" | +| 3 | 社交/单人侧重 | "社交/多人元素的存在形式和程度？" | +| 4 | 付费模型倾向 | "商业模式的方向是？" | +| 5 | 内容消耗 vs 可重玩性 | "你更看重一次性体验的深度，还是可重玩的广度？" | + +### 第三轮：世界观与表现 +| # | 问题域 | 示例 | +|---|-------|------| +| 1 | 美术风格方向 | "视觉风格的关键词是？" | +| 2 | 叙事方式 | "故事在游戏中的角色是？" | +| 3 | 世界观体量 | "世界观的规模你倾向于？" | +| 4 | 平台与操作 | "目标平台和操作方式是？" | +| 5 | 沉浸感优先级 | "沉浸感和游戏性发生冲突时，你更倾向于？" | + +## 每轮问题递减策略 + +- 第二轮的问题应基于第一轮回答做出调整 +- 第三轮的问题应比第二轮更聚焦于"分歧点"和"模糊地带" +- 如果用户在前一轮给出了相互矛盾的回答，下一轮应包含"澄清题" + +## 固定尾部选项 + +每个问题末尾固定包含： +- "我还没想好" +- "这个问题不好" +- "没有我要的回答（请自定义）" + +## 问题自检清单（生成后、输出前） + +``` +□ 是否有引导性表述？（"你是否也认同xxx？" → 不合格） +□ 选项是否覆盖了主要可能性？（无法覆盖 → 含自定义选项） +□ 用户不需要专业知识就能回答吗？（"你倾向FSM还是HFSM？" → 不合格） +□ 问题基于步骤3的哪条分析？（标注来源置信度） +□ 基于 [推测] 的问题是否已转为确认性提问？ +``` + +## 问答记录格式 + +```markdown +# 步骤 4 — 第 N 轮问答 + +**时间**：[timestamp] +**轮次方向**：[核心体验 / 系统机制 / 世界观表现] + +## Q1: [问题原文] +**来源**：[步骤3/GDD逆向/社群分析/...] [置信度] +**选项**： +- A. [选项] +- B. [选项] +- ... +**用户回答**：[选择的选项 / 自定义回答] + +## Q2: ... +``` diff --git a/.opencode/skills/game-design/templates/reference-search-prompt.md b/.opencode/skills/game-design/templates/reference-search-prompt.md new file mode 100644 index 0000000..396ed23 --- /dev/null +++ b/.opencode/skills/game-design/templates/reference-search-prompt.md @@ -0,0 +1,73 @@ +# 参考游戏发现 — 步骤 1-2 执行模板 + +## 步骤 1：检测参考游戏 + +用户描述游戏创意后，检查是否提到了明确的参考游戏名称： +- 已提到且明确 → 直接进入步骤 3（跳过步骤 2） +- 未提到 → 进入步骤 2 + +## 步骤 2：询问参考游戏 + +``` +Agent 提问： +"在开始设计之前，我想了解你的参考方向。你心中有一个或多个参考游戏吗？ +它们可以是你想'继承'的，也可以是'部分参考'的。" +``` + +用户回答分类处理： +- **有一个明确主参考** → 进入步骤 3 +- **有多个但未分主次** → 执行 3 轮筛选提问： + 1. "这些游戏中，哪个的核心循环最接近你想要的？" + 2. "哪个的目标体验/情感氛围最契合？" + 3. "如果只能保留一个作为设计起点，你选哪个？" + → 用户选定后进入步骤 3 +- **没有参考** → 进入步骤 2.1 + +## 步骤 2.1：搜索推荐参考游戏 + +### 搜索策略（三层） + +**内层（优先）：Agent 训练数据中的游戏知识** +- 列出 Agent 已知的、符合用户概念的游戏 +- 标注"来源：Agent 已有知识（知识截止于 [日期]）" + +**中层（补充）：curl 搜索结构化来源** +- Wikipedia 游戏分类页面、知乎同类推荐话题 +- 标注"来源：实时搜索" + +**外层（时效补丁）：curl 搜索新作** +- SteamDB / Steam 同类标签页，获取知识截止日期后的新品 +- 标注"🆕 [年度+新作]" + +### 输出格式（每个候选） + +```markdown +### [游戏名] [年份] +- **简介**：[1 句话核心描述] +- **契合点**：[为什么符合你的概念——指出具体与你的创意重合的部分] +- **视频**：[B站/抖音链接，搜索"游戏名+评测/实况"] +- **资源**：[Wiki / 攻略站链接] +- **知识来源**：[Agent 知识 / curl 搜索结果] +``` + +### 用户无法选择时的 FALLBACK_SEARCH + +按以下优先级搜索其他媒介： +1. NDS / GBA / PSP 等平台受限的老游戏（机制上常有独特创新） +2. 桌游（BoardGameGeek 分类） +3. 电影 / 电视剧（叙事结构、世界观参考） +4. 漫画 / 小说（世界观、角色体系参考） + +找到沾边的 → 按 2.1 格式输出。仍未找到 → 进入以下提示： + +```markdown +**这是一个积极的信号**：你在探索一个似乎还没有明确参照物的方向。 +这意味着有很大的创新空间，但也意味着后续设计过程中需要更多的 +内部一致性审查。接下来我会通过问答帮你把这个方向具象化。 + +如果你做好了进入未知领域的准备，我们进入步骤 4。 +如果你希望先有一个更明确的参照点，可以重新提出方向。 +``` + +用户确认继续 → 以"无参考模式"进入步骤 4（跳过步骤 3）。 +用户提出新方向 → 回到步骤 1。 diff --git a/.opencode/skills/opencode-init/SKILL.md b/.opencode/skills/opencode-init/SKILL.md index 0dcf42c..3255ff2 100644 --- a/.opencode/skills/opencode-init/SKILL.md +++ b/.opencode/skills/opencode-init/SKILL.md @@ -1,5 +1,6 @@ --- name: opencode-init +phases: ["all"] description: >- 初始化新项目的 .opencode 结构，以及将实际项目中孵化出的跨项目能力整合回模板框架。 三种触发方式： diff --git a/.opencode/skills/pitfall-journal/SKILL.md b/.opencode/skills/pitfall-journal/SKILL.md index 4312add..629e3ef 100644 --- a/.opencode/skills/pitfall-journal/SKILL.md +++ b/.opencode/skills/pitfall-journal/SKILL.md @@ -1,5 +1,6 @@ --- name: pitfall-journal +phases: ["all"] description: >- 踩坑经验记录系统。在调试完成或发现非显而易见的坑后记录根因和解决方式， 后续遇到同类问题时自动检索匹配，避免重复踩坑。 diff --git a/.opencode/skills/problem-distillery/SKILL.md b/.opencode/skills/problem-distillery/SKILL.md index 870d475..562ecdf 100644 --- a/.opencode/skills/problem-distillery/SKILL.md +++ b/.opencode/skills/problem-distillery/SKILL.md @@ -1,5 +1,6 @@ --- name: problem-distillery +phases: ["all"] description: >- 从顽固问题中蒸馏方法论的渐进式知识系统。追踪反复出现且未被彻底解决的问题， 记录解决过程和弯路，定期提炼精炼认知，经实践验证后自动升级为常规注入。 diff --git a/.opencode/skills/profile-memory/SKILL.md b/.opencode/skills/profile-memory/SKILL.md index dbde59c..5d693e9 100644 --- a/.opencode/skills/profile-memory/SKILL.md +++ b/.opencode/skills/profile-memory/SKILL.md @@ -1,5 +1,6 @@ --- name: profile-memory +phases: ["all"] description: >- 渐进式用户/项目画像系统。两条触发路径： （1）被动检测（主路径）——由 AGENTS.md checklist 前置项 A 触发短路扫描， diff --git a/.opencode/skills/skill-tester/SKILL.md b/.opencode/skills/skill-tester/SKILL.md new file mode 100644 index 0000000..68ae8af --- /dev/null +++ b/.opencode/skills/skill-tester/SKILL.md @@ -0,0 +1,206 @@ +--- +name: skill-tester +phases: ["all"] +description: >- + SKILL 体系自动化测试工具。通过 LLM-as-Judge 模式对 SKILL.md 的行为逻辑进行回归测试， + 验证阶段守卫、规则遵循、输出格式等维度。触发关键词："测试Skill"、"测试 [skill名]"、 + "回归测试"、"skill test"、"跑测试"。 +--- + +# 相位守卫（Phase Guard） + +**本 Skill 加载后的首个强制动作：** +1. 读取 `.opencode/phase/current.json` +2. 若 `phases` 不包含 `"all"` 且当前 `phase` 值不在 `phases` 列表中： + - 立即中止，输出："当前阶段为 [phase]，skill-tester Skill 不可用。" + - 不得执行本 Skill 的任何后续流程 +3. 否则：继续执行 + +--- + +# 概述 + +skill-tester 是元层测试工具，通过 LLM-as-Judge 模式验证 SKILL.md 的行为逻辑。 +**核心原理**：将 SKILL.md 内容 + 模拟用户输入注入 sub-agent，观察其输出是否符合预期， +再用另一个 sub-agent 作为裁判评分。 + +**不测试什么**：opencode 的 Skill 加载机制本身（那是 opencode 的责任）。 +**测试什么**：SKILL.md 中的指令逻辑——当 LLM 忠实执行这些指令时，产生正确的行为。 + +--- + +# 操作 A：测试单个 Skill + +## 触发 + +用户说"测试 [Skill 名称]"、如 "测试 game-design"、"测试 dev-changelog"。 + +## 流程 + +``` +1. 读取目标 Skill 的 SKILL.md +2. 读取 .opencode/skills/skill-tester/test-cases/ 下匹配该 Skill 的测试用例 +3. 列出测试用例清单，询问用户确认 +4. 用户确认后，逐一执行 +5. 汇总报告 +``` + +## 步骤 3：测试用例预览 + +``` +Agent 输出： +"找到 [N] 个针对 [Skill名] 的测试用例： + +| # | ID | 场景 | 严重度 | +|---|-----|------|--------| +| 1 | phase-guard-001 | 非匹配阶段拒绝加载 | critical | +| 2 | ... | ... | ... | + +预计消耗约 [估算token] tokens。是否全部执行？(y/n/选择特定用例)" +``` + +## 步骤 4：单用例执行 + +### 4.1 构造模拟 Sub-agent + +将以下内容组装为一个 prompt，通过 Task tool（sub-agent type = general）执行： + +``` +你正在模拟一个 opencode agent，该 agent 刚刚加载了以下 Skill： + +--- +[目标 SKILL.md 的完整内容] +--- + +**当前会话上下文：** +- 当前阶段 (phase)：[test_case.phase] +- 用户消息："[test_case.user_message]" +- state.json 状态：[test_case.state]（如适用） + +**你的任务**：严格按照上述 Skill 中的指令行事。 +你拥有所有 opencode agent 的工具（bash/read/write/edit/...）。 + +用户说了："[test_case.user_message]" + +请输出你的响应。只输出你作为 agent 会输出的内容。 +注意： +- 如果是 phase guard 测试，第一个行为应该是检查阶段并可能中止 +- 如果 Skill 要求写文件，输出你打算写什么以及写到哪个文件（但不要实际写） +- 如果 Skill 有强制规则（如 Hallucination 防御），务必遵守 +``` + +### 4.2 执行并收集输出 + +``` +Agent 调用 Task tool → 等待 sub-agent 完成 → 收集其文本输出 +``` + +### 4.3 Judge 评估 + +将模拟 sub-agent 的输出 + 预期行为 + 评分标准传给 Judge sub-agent。 + +Judge 的详细指令见 [judge-prompt.md](judge-prompt.md)。 + +调用方式： +``` +Agent 调用 Task tool，prompt 为 judge-prompt.md 的内容（已填充变量）→ 等待完成 +``` + +### 4.4 记录结果 + +```json +{ + "test_id": "phase-guard-001", + "skill": "game-design", + "timestamp": "...", + "scores": { + "behavior_match": 5, + "output_clarity": 4, + "rule_compliance": 5 + }, + "overall": 4.7, + "judge_feedback": "Agent 正确识别了阶段不匹配..." +} +``` + +## 步骤 5：汇总报告 + +``` +Agent 输出（Markdown）： + +## 测试报告：[Skill 名称] + +**执行时间**：[timestamp] +**测试用例数**：[total] | 通过：[pass] | 失败：[fail] | 跳过：[skip] + +| # | ID | 场景 | 行为 | 清晰度 | 合规 | 总分 | 状态 | +|---|-----|------|------|--------|------|------|------| +| 1 | phase-guard-001 | 阶段拒绝 | 5 | 4 | 5 | 4.7 | ✅ | +| 2 | ... | ... | ... | ... | ... | ... | ❌ | + +### 失败用例详情 +#### [ID] — [场景] +- **预期**：[expected 描述] +- **实际**：[agent 实际输出摘要] +- **裁判反馈**：[judge 的具体反馈] +- **建议**：[改进建议] +``` + +--- + +# 操作 B：回归测试（全部 Skill） + +## 触发 + +用户说"回归测试"、"跑全部测试"、"test all skills"。 + +## 流程 + +``` +1. 读取 test-cases/ 下所有测试用例 +2. 按 Skill 分组展示 +3. 询问用户确认（因为消耗较大） +4. 按 Skill 逐一执行（每个 Skill 内部用例并行执行） +5. 汇总全部报告 +``` + +## 执行策略 + +- 同一 Skill 内的多个用例可以**并行执行**（无状态依赖） +- 不同 Skill 之间**顺序执行**（避免混淆） +- 单个用例超时 60 秒 +- 如有用例执行失败（sub-agent 错误），标记为 ERROR 而非 FAIL + +--- + +# 操作 C：查看历史报告 + +## 触发 + +用户说"查看测试报告"、"上次测试结果"。 + +## 流程 + +读取 `.opencode/skills/skill-tester/reports/` 下最新报告，展示摘要。 + +--- + +# 评分标准说明 + +每个测试用例在 3 个维度上评分（1-5）： + +| 维度 | 含义 | 5 分标准 | +|------|------|---------| +| **行为匹配 (behavior_match)** | Agent 的输出行为是否符合预期 | 核心决策（如加载/拒绝加载）完全正确 | +| **输出清晰度 (output_clarity)** | 输出是否清晰、无歧义 | 信息完整、结构清楚、用户可直接理解 | +| **规则合规 (rule_compliance)** | 是否遵守了 SKILL.md 中的强制规则 | 所有强制检查点均已执行 | + +**通过标准**：总分 >= 4.0（即平均每维度 >= 4.0）。 +**警告标准**：3.0 <= 总分 < 4.0。 +**失败标准**：总分 < 3.0。 + +--- + +# 自迭代日志 + +本节记录使用本 Skill 过程中发现的必要检查项。 diff --git a/.opencode/skills/skill-tester/judge-prompt.md b/.opencode/skills/skill-tester/judge-prompt.md new file mode 100644 index 0000000..a253cc1 --- /dev/null +++ b/.opencode/skills/skill-tester/judge-prompt.md @@ -0,0 +1,87 @@ +# Judge 评估提示模板 + +你是一个 SKILL 行为评估裁判（Skill Behavior Judge）。你的任务是评估一个 opencode agent +在特定场景下的输出是否达到了预期行为标准。 + +## 评估输入 + +### 场景背景 +- **被测 Skill**：[skill_name] +- **测试场景**：[scenario_description] +- **当前阶段 (phase)**：[phase] + +### 用户消息 +``` +[user_message] +``` + +### 预期行为 +[expected_behavior] + +### Agent 实际输出 +``` +[agent_output] +``` + +--- + +## 评估规则 + +### 你必须逐项评分（1-5 分） + +#### 维度 1：行为匹配 (behavior_match) +Agent 的核心行为决策是否符合预期？ +- 5：核心决策完全正确，无任何偏差 +- 4：核心决策正确，但有 1 处不影响结果的偏差 +- 3：核心决策部分正确，但有 1 处需要注意的偏差 +- 2：核心决策错误 +- 1：完全不符合预期 + +#### 维度 2：输出清晰度 (output_clarity) +Agent 的输出是否清晰、准确、无歧义？ +- 5：信息完整、语气恰当、用户可直接理解 +- 4：信息完整，但表达略有冗余 +- 3：信息基本完整，但有关键细节不清晰 +- 2：信息缺失或容易引起误解 +- 1：输出混乱、无法理解 + +#### 维度 3：规则合规 (rule_compliance) +（仅当被测 Skill 有强制规则时使用。如果没有，此项与行为匹配合并评分。） +Agent 是否遵守了 SKILL.md 中的强制规则？ +- 5：所有强制检查点均已正确执行 +- 4：主要规则遵守，但跳过了一个非关键检查 +- 3：遵守了部分规则，漏掉了关键检查 +- 2：大部分规则被忽略 +- 1：完全无视规则 + +--- + +## 输出格式 + +你必须严格按照以下格式输出评估结果： + +```json +{ + "scores": { + "behavior_match": <1-5>, + "output_clarity": <1-5>, + "rule_compliance": <1-5> + }, + "overall": <1-5 的平均值，保留 1 位小数>, + "passed": , + "specific_findings": { + "matched": ["<具体符合预期的地方>", "..."], + "missed": ["<未达到预期的具体问题>", "..."], + "surprising": ["<意料之外但可能是好的行为>", "..."] + }, + "improvement_suggestions": "<如果未通过，给出具体的改进建议；如果通过，留空字符串>", + "confidence": "" +} +``` + +## 重要提醒 + +1. **客观评分**：你评估的是 Agent 输出与预期行为的匹配度，不是输出本身的"质量" +2. **关注关键行为**：对核心决策点（加载/拒绝、中止/继续）的评估权重大于措辞细节 +3. **允许合理的上下文适应**：如果 Agent 输出与预期有差异但是是因为模拟场景缺失真实上下文，不算偏差 +4. **标注低置信度**：如果某个判断你不太确定，在 confidence 中标注并在 specific_findings 中说明原因 diff --git a/.opencode/skills/skill-tester/test-cases/dev-changelog.md b/.opencode/skills/skill-tester/test-cases/dev-changelog.md new file mode 100644 index 0000000..01c2207 --- /dev/null +++ b/.opencode/skills/skill-tester/test-cases/dev-changelog.md @@ -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 备注 +- 核心判断：是否理解"底部 = 最旧" +- 次要件：是否主动执行了"数清条目"这个步骤 diff --git a/.opencode/skills/skill-tester/test-cases/game-design.md b/.opencode/skills/skill-tester/test-cases/game-design.md new file mode 100644 index 0000000..ec7f67c --- /dev/null +++ b/.opencode/skills/skill-tester/test-cases/game-design.md @@ -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 备注 +- 核心判断：是否识别出了逻辑矛盾 +- 次要判断：是否给出了合理的确认建议 +- 关键检查：矛盾类型标注是否准确（应为"逻辑矛盾"而非"语义冲突"） diff --git a/.opencode/skills/skill-tester/test-cases/phase-guard.md b/.opencode/skills/skill-tester/test-cases/phase-guard.md new file mode 100644 index 0000000..3a818f6 --- /dev/null +++ b/.opencode/skills/skill-tester/test-cases/phase-guard.md @@ -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 在所有阶段都应可用 diff --git a/.opencode/skills/skill-tester/test-cases/qa-quality.md b/.opencode/skills/skill-tester/test-cases/qa-quality.md new file mode 100644 index 0000000..ad8d756 --- /dev/null +++ b/.opencode/skills/skill-tester/test-cases/qa-quality.md @@ -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 备注 +- 核心判断：是否将问题识别为"模式"而非"孤立事件" +- 关键检查：改进建议是否具有跨项目复用价值 diff --git a/.opencode/skills/spec-docs/SKILL.md b/.opencode/skills/spec-docs/SKILL.md index 4e19545..ba2b791 100644 --- a/.opencode/skills/spec-docs/SKILL.md +++ b/.opencode/skills/spec-docs/SKILL.md @@ -1,5 +1,6 @@ --- name: spec-docs +phases: ["all"] description: >- 规范文档全生命周期管理系统。在 Agent 执行架构/规范类任务前自动提醒是否需要创建文档， 周期性审查文档与 changelog/代码的一致性（遗漏、陈旧、互斥检测），写入/更新规范文档。 diff --git a/AGENTS.md b/AGENTS.md index b3657ee..de9dd1a 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -4,6 +4,39 @@ - 所有思考过程、回答、代码注释均使用中文 - 专业术语和项目专有名词（Roblox API、Lua 关键字等）保持英文 +## 阶段检查（优先级 -1，在所有自检之前） + +每次会话首次响应前，Agent 必须首先完成阶段检查： + +读取 `.opencode/phase/current.json`： +- **不存在** → 创建默认值 `{"phase": "design", ...}`，以设计阶段启动，提示用户当前默认阶段 +- **存在** → 以 `phase` 字段值作为当前激活阶段 + +当前阶段约束后续所有行为： +- 加载任何 Skill 前，检查其 SKILL.md frontmatter 的 `phases` 字段 +- `phases` 包含 `"all"` 或当前 phase 值时，允许加载 +- 否则禁止加载该 Skill，提示用户"当前阶段 [phase] 不支持该 Skill" + +**阶段切换规则**： + +| 用户表述 | 行为 | +|---------|------| +| "切换到XX阶段" / "进入XX阶段" | 更新 `current.json` 的 `phase`、`switched_at`、`previous_phase`；提示"已切换到 XX 阶段，下次会话生效" | +| "切换到XX阶段，现在就生效" / "现在就用" | 更新 `current.json` + 立即重新执行阶段检查（重新读取 current.json，重载阶段规则），提示"已切换到 XX 阶段，当前会话已生效" | + +**可用阶段列表**： +- `design` — 设计阶段（默认）：game-design Skill 可用 +- `development` — 开发阶段：所有基础设施 Skill + 开发专属 Skill +- `qa` — QA 阶段（预留） +- `quantification` — 量化阶段（预留） + +**设计阶段额外注入**（仅 phase = "design" 时执行）： +读取 `.opencode/phase/data/design/state.json`（不存在则跳过）→ 如有进行中的工作流，注入当前进度 +读取 `.opencode/phase/data/design/design-outline.md`（不存在则跳过）→ 如有已完成的设计大纲，注入"设计方向摘要"和"待明确核心问题"作为上下文 + +**开发阶段额外注入**（仅 phase = "development" 时执行）： +读取 `.opencode/phase/data/design/design-outline.md`（不存在则跳过）→ 如有已完成的设计大纲，注入"设计方向摘要"和"待明确核心问题"作为开发参考 + ## 会话启动自检（最高优先级） 每次会话首次响应前，Agent 必须完成以下自检序列：