OpenCodeInit/.opencode/skills/game-design/SKILL.md

name, phases, description

name	phases	description
game-design	design	游戏设计全流程辅助系统。从创意概念到设计大纲，通过参考游戏分析、多轮结构化问答、 一致性审查和深度探索，帮助设计师系统化地完成游戏设计前期工作。

相位守卫（Phase Guard）

本 Skill 加载后的首个强制动作：

1. 读取 .opencode/phase/current.json
2. 若 phase 值不在本 Skill 的 phases 列表中：
   • 立即中止，输出："当前阶段为 [phase]，game-design Skill 不可用。请切换到设计阶段。"
   • 不得执行本 Skill 的任何后续流程
3. 若 phase 匹配：继续执行

---

状态机速查

状态	含义	下一状态
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 过程中发现的必要检查项。