engine ignition update

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