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

.opencode/phase/current.json

@@ -0,0 +1,5 @@
+{
+  "phase": "design",
+  "switched_at": null,
+  "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,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 中的指令逻辑

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

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

.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": <true/false，阈值 4.0>,
+  "specific_findings": {
+    "matched": ["<具体符合预期的地方>", "..."],
+    "missed": ["<未达到预期的具体问题>", "..."],
+    "surprising": ["<意料之外但可能是好的行为>", "..."]
+  },
+  "improvement_suggestions": "<如果未通过，给出具体的改进建议；如果通过，留空字符串>",
+  "confidence": "<high/medium/low — 你对此评估的自信程度>"
+}
+```
+
+## 重要提醒
+
+1. **客观评分**：你评估的是 Agent 输出与预期行为的匹配度，不是输出本身的"质量"
+2. **关注关键行为**：对核心决策点（加载/拒绝、中止/继续）的评估权重大于措辞细节
+3. **允许合理的上下文适应**：如果 Agent 输出与预期有差异但是是因为模拟场景缺失真实上下文，不算偏差
+4. **标注低置信度**：如果某个判断你不太确定，在 confidence 中标注并在 specific_findings 中说明原因

.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 备注
+- 核心判断：是否理解"底部 = 最旧"
+- 次要件：是否主动执行了"数清条目"这个步骤

.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 备注
+- 核心判断：是否识别出了逻辑矛盾
+- 次要判断：是否给出了合理的确认建议
+- 关键检查：矛盾类型标注是否准确（应为"逻辑矛盾"而非"语义冲突"）

.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 在所有阶段都应可用

.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 备注
+- 核心判断：是否将问题识别为"模式"而非"孤立事件"
+- 关键检查：改进建议是否具有跨项目复用价值

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