.opencode/canonical-manifest.json

@@ -19,7 +19,8 @@
     ".opencode/skills/pitfall-journal/",
     ".opencode/skills/problem-distillery/",
     ".opencode/skills/profile-memory/",
-    ".opencode/skills/spec-docs/"
+    ".opencode/skills/spec-docs/",
+    ".opencode/skills/game-design/"
   ],
   "template_data_files": [
     ".opencode/data/changelog/changelog-full.md",
@@ -36,6 +37,15 @@
     ".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": "上一轮冲突备份残留" },

.opencode/data/changelog/changelog-full.md

@@ -4,4 +4,27 @@
 
 ## 记录
 
+### [CL-20260503-2105] 2026-05-03 21:05 — 实现游戏设计全流程辅助系统（阶段注入 + game-design Skill）
+- **tags**: phase-system, game-design, skill-creation, architecture, infra
+- **affected_files**:
+  - AGENTS.md
+  - .opencode/skills/（9个 SKILL.md，含新增 game-design 与 8个现有修改）
+  - .opencode/skills/game-design/templates/（5个新增模板文件）
+  - .opencode/skills/game-design/prompts/（2个新增 sub-agent 提示文件）
+  - .opencode/phase/（current.json + 7个设计阶段数据文件，新增）
+  - .opencode/skills/epee-orchestrator/registry.md
+  - .opencode/canonical-manifest.json
+- **what**: 实现基于阶段（phase）的项目工作流系统 + game-design Skill。AGENTS.md 新增"阶段检查"块作为启动序列最高优先级；8 个现有 Skill 追加 `phases: ["all"]`；新增 game-design Skill（`phases: ["design"]`）实现创意概念→参考分析→多轮问答→设计大纲全链路。
+- **why**: Skill 增多导致上下文膨胀；设计阶段缺少结构化工具。阶段机制按需注入，game-design Skill 将非结构化的游戏设计讨论编码为可追踪、可恢复的结构化工作流。
+- **decisions**: 
+  - 阶段隔离采用"Skill 入口守卫"模式（每个 SKILL.md 加载后首个动作验证 phase），配合"立即+下次"双重切换机制
+  - Hallucination 三级防御：置信度标注（确认/推断/推测）+ 来源 URL 锚定 + 局限性声明
+  - 五维一致性审查作为步骤 4→5 强制停留点
+  - 不可逆决策三级标记（🔴不可逆/🟠高成本回退/🟢可回退）+ 强制确认
+  - 问答质量预防+反馈双循环
+  - 状态管理事务化（in_progress 标记 + checkpoint 恢复）
+  - SKILL.md 主干分支分离（主文件 ~110 行 + 7 个独立模板按需加载）
+  - Devil's Advocate 语气约束（"挑战前提"非"质疑"）
+- **notes**: game-design 仅 design 阶段可加载；跨会话恢复依赖 state.json；设计大纲在开发阶段自动注入；qa-quality-report 项目本地存储；canonical-manifest.json 新增 template_phase_files 分组
+
 <!-- 新条目追加在此行上方 -->

.opencode/data/changelog/changelog-headlines.md

@@ -2,4 +2,5 @@
 
 最近 ~50 次改动的一句话概要，按时间倒序排列。每次会话自动注入上下文。
 
+- [CL-20260503-2105] 实现阶段注入系统与 game-design Skill：新增 phase 机制区分设计/开发阶段，实现五步游戏设计全流程辅助（参考分析→多轮问答→一致性审查→设计大纲），含 Hallucination 三级防御与事务化状态管理
 <!-- 新条目追加在此行上方 -->

.opencode/data/changelog/changelog-recent.md

@@ -3,4 +3,10 @@
 最近 ~10 次改动的摘要记录，按时间倒序排列。
 当 Agent 检测到当前任务与近期改动相关时自动读取。
 
-<!-- 新条目追加在此行上方 -->
+### [CL-20260503-2105] 2026-05-03 — 实现游戏设计全流程辅助系统（阶段注入 + game-design Skill）
+- **tags**: phase-system, game-design, skill-creation, architecture
+- **affected_files**: AGENTS.md, 9个 SKILL.md（修改8个+新增1个）, 7个模板/提示文件, phase/ 目录结构, registry.md, canonical-manifest.json
+- **summary**: 
+  新增阶段（phase）系统：通过 current.json 控制项目处于设计/开发/QA/量化阶段，AGENTS.md 启动时读取并约束 Skill 加载。8 个现有 Skill 标记 phases: ["all"]，新增 game-design Skill 标记 phases: ["design"]。
+  game-design Skill 实现五步游戏设计工作流：参考游戏发现→并行 sub-agent 反拆 GDD+社群分析→Devil's Advocate 前提挑战→3轮×5题初步问答→3+轮深度问答→输出含 VISTA 框架的设计大纲。
+  内建 Hallucination 三级防御、五维一致性审查、不可逆决策标记、问答质量双循环、事务化状态管理。

.opencode/phase/current.json

@@ -0,0 +1,6 @@
+{
+  "phase": "design",
+  "switched_at": "2026-05-03T20:57:00+08:00",
+  "switched_by": "init",
+  "previous_phase": null
+}

.opencode/phase/data/design/qa-quality-report.md

@@ -0,0 +1,17 @@
+# 问答质量评估报告
+
+本文件记录设计工作流中每轮问答的质量评估结果。每次评估追加，不覆盖。
+
+## 评估维度
+
+- **劣质问题类型**：引导性 / 过于抽象 / 遗漏选项 / 不可回答 / 基于推测
+- **问题原文**：保留用户质疑的原问题
+- **用户反馈**：用户的具体质疑或自定义回答
+- **优化方案**：改进后的提问方式
+- **通用建议**：可跨项目复用的经验
+
+---
+
+## 质量报告
+
+<!-- 新条目按时间倒序追加 -->

.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
+}

.opencode/skills/deferred-decisions/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: deferred-decisions
+phases: ["all"]
 description: >-
   记录开发中被延期的技术方案/决策，并在关联任务出现时主动提醒用户。
   当对话中出现"以后再做"、"先不做"、"defer"、"延期方案"、"备选方案"、

.opencode/skills/dev-changelog/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: dev-changelog
+phases: ["all"]
 description: >-
   三层开发进程记录系统。在 Agent 完成代码改动后自动记录，提供从一句话概要到完整日志的
   多级上下文，帮助 Agent 在跨会话场景下保持对项目开发进展的感知。

.opencode/skills/epee-orchestrator/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: epee-orchestrator
+phases: ["all"]
 description: >-
   EPEE Skill Orchestrator：元层调度系统。检测任务是否可由已有 Skill 处理并分流，
   或发现 Skill 缺口并引导创建新 Skill。当 Agent 遇到手动配置密集、重复模式明确、

.opencode/skills/epee-orchestrator/registry.md

@@ -76,3 +76,11 @@
 - **输出**: 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 维度矛盾检测）、不可逆决策标记、问答质量预防+反馈双循环、事务化状态管理；支持跨会话恢复

.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. 若 `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 过程中发现的必要检查项。

.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`

.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`

.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 的交接，以"下一步行动"形式写，不重复前面的设计内容

.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 的问题生成
+- 回避/模糊的回应 → 记录为"弱信号"，带入一致性审查
+- 用户要求跳过 → 跳过，但记录"用户选择跳过挑战环节"

.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 轮没有给出新的模糊回答

.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: ...
+```

.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。

.opencode/skills/opencode-init/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: opencode-init
+phases: ["all"]
 description: >-
   初始化新项目的 .opencode 结构，以及将实际项目中孵化出的跨项目能力整合回模板框架。
   三种触发方式：

.opencode/skills/pitfall-journal/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: pitfall-journal
+phases: ["all"]
 description: >-
   踩坑经验记录系统。在调试完成或发现非显而易见的坑后记录根因和解决方式，
   后续遇到同类问题时自动检索匹配，避免重复踩坑。

.opencode/skills/problem-distillery/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: problem-distillery
+phases: ["all"]
 description: >-
   从顽固问题中蒸馏方法论的渐进式知识系统。追踪反复出现且未被彻底解决的问题，
   记录解决过程和弯路，定期提炼精炼认知，经实践验证后自动升级为常规注入。

.opencode/skills/profile-memory/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: profile-memory
+phases: ["all"]
 description: >-
   渐进式用户/项目画像系统。两条触发路径：
   （1）被动检测（主路径）——由 AGENTS.md checklist 前置项 A 触发短路扫描，

.opencode/skills/spec-docs/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: spec-docs
+phases: ["all"]
 description: >-
   规范文档全生命周期管理系统。在 Agent 执行架构/规范类任务前自动提醒是否需要创建文档，
   周期性审查文档与 changelog/代码的一致性（遗漏、陈旧、互斥检测），写入/更新规范文档。

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 必须完成以下自检序列：