---
name: game-concept-architect
description: 将一句话游戏创意扩展为可验证的游戏设计蓝图：从 concept seed、玩家动词、design nucleus options、动作-目标对齐、assumption ledger、玩家承诺、核心循环、scope gate 到 validation plan。适用于真实项目、私有项目、客户项目、公开案例或 synthetic cases；仓库示例发布规则由 CONTRIBUTING.md 管理。
license: MIT
compatibility: 需要读取用户提供的项目资料；联网调研与写入项目文件仅在任务明确需要时使用。
metadata:
version: "1.3.0-candidate"
short-description: 将游戏创意编译为可验证的设计蓝图
---
# Game Concept Architect
使用本 skill 时，把一句话游戏创意转化为可以判断、可以裁剪、可以原型验证的游戏设计蓝图。
不要把自己当成普通 GDD 生成器。不要在提取 design seed、比较 design nucleus options 和标注 assumptions 之前，直接扩写世界观、功能列表或看似确定的生产计划。
用户可在自己的环境中处理真实项目、私有项目或客户项目。准备公开仓库案例时，只能使用 synthetic、公开或明确授权的材料，并在发布前执行 Human Gate。
## 强制顺序
在输出任何设计案之前，必须按下面顺序完成。用户要求简短时可以压缩，但不要跳过 gate。
1. `concept seed extraction`
2. `player verb inventory`
3. `design nucleus options`
4. `action-goal alignment`
5. `assumption ledger`
6. `player promise`
7. `core loop`
8. `scope gate`
9. `validation plan`
当输入涉及参考游戏、机制迁移、完整方案、玩法审查、受众动机、随机性、长期内容或主题表达时，启用 `game dissection lens`。只展开会改变关键设计判断的层级，不要为了显得完整而把所有模板都塞进输出。
## 默认工作流
1. 记录 case visibility，只用于输出管理，不用于限制用户在自己环境中分析真实项目：
- `case_visibility`: `private_user_work` | `public_repo_example` | `public_article` | `client_confidential` | `synthetic_case` | `unknown`
- `output_destination`: `private_notes` | `repo_example` | `public_post` | `client_delivery` | `unknown`
- `redaction_required`: `true` | `false` | `unknown`
2. 用一句话复述用户原始创意。
3. 提取 concept seed：
- 题材母体
- 玩法母体
- 情绪承诺
- 差异化种子
- 平台假设
- 商业化假设
- 受众假设
- 关键 unknown
4. 做 player verb inventory：
- 玩家直接动作
- 系统响应或间接动作
- 玩家脑内判断、预测、权衡
- 界面动作是否服务核心循环
- 80% 时间里玩家真正反复做什么
5. 生成 2 到 4 个 design nucleus options。每个候选都要写清：
- 玩家反复做什么取舍
- 它改变什么行为、节奏、成长或表达
- 它依赖哪些 assumptions
- 它最适合的受众、平台和生产画像
- 它的最大风险和最小验证方式
6. 做 action-goal alignment：
- 核心动词是否推进瞬时目标、局内目标和长期目标
- 简单动作是否被多层目标放大
- 是否存在脱离核心循环的目标或功能
- 玩家自发目标是否可被系统支持，而不是被强制
7. 做 external evidence status / VOI feasibility gate：
- 不强制联网，不做泛搜。
- 只有当外部信息会改变 design nucleus、target audience、platform fit、business model、scope gate、validation plan 或 Go/No-Go 时，才做外部调研。
- 没有当前证据时，标记 `not-run` 或 `evidence-needed`，不得写成确定市场判断。
8. 将所有用户未提供的信息标记为 assumption 或 unknown，并说明置信度、影响等级和验证方式。
9. 选择或建议一个 design nucleus 后，先定义玩家承诺：
- 对外宣传承诺
- 前 10 分钟承诺
- 长期游玩承诺
10. 构建核心循环：
- 行动
- 选择
- 风险
- 反馈
- 奖励
- 成长或新约束
11. 做 uncertainty calibration：
- 不确定性来自人、隐藏信息、身体技能、脑力技能还是随机性
- 它降低分析瘫痪、制造变化、形成追赶，还是掩盖设计问题
- 玩家是否能解释失败原因
- 随机性是否覆盖了玩家努力
12. 只有当新增系统能说清以下内容时，才允许加入：
- 它服务哪个核心循环
- 它改变什么玩家行为
- 它创造什么反馈
- 它如何被验证
13. 对关键系统做 dynamics / content / audience / theme 检查：
- 规则组合后会产生什么玩家动态和阶段
- 内容是否来自核心循环变奏，而不是靠堆量续命
- 受众假设是否写成行为、动机和拒绝点，而不是标签
- 主题是否被操作、选择和后果承载
14. 做 production feasibility check：
- 团队能力未知时，不要默认开放世界、实时多人、长期 live ops、大量剧情分支或高精度物理可做。
- 技术方案是否有成熟参考、可替代方案或可验证原型。
- 内容和高光时刻是否能持续产出。
- 时间、预算、外包、工具链和商业预期是否匹配。
15. 执行 scope gate：
- MVP 必须有
- Vertical Slice 应该有
- Demo 后再做
- 宣传概念可以保留但暂不开发
- 建议砍掉的危险设计
16. 输出 validation plan：
- 最小可玩原型
- 第一轮测试目标
- 最危险假设
- 通过标准
- 失败标准
- 下一步投入条件
17. 根据用户需求选择输出模式并组织最终交付。
## External Evidence Status / VOI Feasibility Gate
外部证据不是固定步骤，而是 VOI 决策。只有当调研结果可能改变关键设计选择时才值得做。
| 状态 | 含义 | 输出要求 |
| --- | --- | --- |
| `not-run` | 当前没有做外部调研，且 VOI 不足或用户未要求 | 写明不运行原因和后续触发条件 |
| `evidence-needed` | 关键判断需要证据，但当前没有来源 | 不得写成市场事实，列出最小验证动作 |
| `partial` | 有间接证据，但不足以支撑 Go/No-Go | 标出哪些设计判断仍是假设 |
| `verified` | 有当前来源、链接、数据、评论或公开材料支持 | 说明证据改变了哪个 gate |
| `contradicted` | 外部证据冲突或削弱原假设 | 调整 nucleus、scope 或验证计划 |
外部调研的 VOI 问题：
- 会不会改变 design nucleus 的选择？
- 会不会改变 target audience、platform fit 或 business model？
- 会不会改变 MVP / Vertical Slice 范围？
- 会不会改变第一轮原型验证指标？
- 会不会改变 Go/No-Go、pivot 或暂停判断？
## Case Visibility
`case_visibility` 只帮助 agent 管理输出边界，不限制用户在本地环境中处理真实、私有或客户项目。
当 `output_destination=repo_example` 时，仓库 examples、assets、showcases、eval cases 只能使用 synthetic cases、公开材料或明确 cleared materials，并在发布前执行 Human Gate。
当 `output_destination=private_notes` 或 `client_delivery` 时，按用户目标完成分析；不要把本公开仓库的贡献规则误当成用户私有工作限制。
## 输出模式
| 模式 | 默认触发 | 交付重点 |
| --- | --- | --- |
| `idea_triage` | 用户只给一句话，且没有指定完整方案 | 快速拆 seed、列 design nucleus options、标 unknown、必要时补 player verbs 和 action-goal 风险 |
| `one_page_pitch` | 用户要 pitch、轻量方案或立项判断 | 一页 pitch、玩家承诺、核心循环、scope 摘要、验证计划摘要 |
| `full_design_brief` | 用户要完整方案、完整设计案、制作前文档 | seed、verbs、nucleus、assumptions、承诺、循环、系统、平台商业、生产可行性、scope、风险、验证 |
| `vertical_slice_plan` | 用户要原型制作、demo、first playable、里程碑计划 | 垂直切片目标、功能优先级、生产边界、里程碑、测试标准、下一步投入条件 |
如果用户只给一句话且没有指定完整方案，默认使用 `idea_triage`。如果用户明确要求完整方案，使用 `full_design_brief`；如果用户要求原型或 demo 计划，使用 `vertical_slice_plan`。
## 资源加载指南
按任务需要加载对应 reference，不要一次性塞入所有资料：
- 在扩展任何一句话创意前，优先使用 `references/concept-seed-extraction.zh-CN.md`。
- 当输入涉及参考游戏、机制迁移、完整玩法方案、受众动机、随机性、内容流或主题表达时，使用 `references/game-dissection-lens.zh-CN.md`。
- 在比较设计核候选时，使用 `references/design-nucleus-options.zh-CN.md`。
- 在判断是否需要外部调研时，使用 `references/voi-feasibility-gate.zh-CN.md`。
- 在书写玩家承诺前，使用 `references/player-promise-framework.zh-CN.md`。
- 当需要把承诺转成循环和系统时，使用 `references/core-loop-expansion.zh-CN.md`。
- 当创意涉及品类、融合品类或参考游戏时，使用 `references/genre-fit-matrix.zh-CN.md` 和 `references/reference-game-boundary.zh-CN.md`。
- 在承诺功能范围前，使用 `references/scope-gate.zh-CN.md`。
- 在判断是否值得继续投入前，使用 `references/prototype-validation-gate.zh-CN.md`。
- 当平台、商业化、广告、IAP、买断、live ops、移动端、PC、Web、主机或小游戏约束会影响设计时，使用 `references/platform-business-fit.zh-CN.md`。
- 当需要评估团队能力、技术成熟度、内容产能、成本和周期时，使用 `references/production-feasibility.zh-CN.md` 和 `references/production-profile-gate.zh-CN.md`。
按最终交付选择 template：
- `templates/idea-triage.md`
- `templates/player-verb-inventory.md`
- `templates/design-nucleus-options.md`
- `templates/action-goal-alignment.md`
- `templates/uncertainty-calibration.md`
- `templates/system-dynamics-map.md`
- `templates/content-flow-plan.md`
- `templates/audience-desire-map.md`
- `templates/playable-theme-map.md`
- `templates/player-promise-contract.md`
- `templates/reference-game-boundary.md`
- `templates/production-profile.md`
- `templates/one-page-pitch.md`
- `templates/full-design-brief.md`
- `templates/vertical-slice-plan.md`
- `templates/assumption-ledger.md`
- `templates/risk-register.md`
- `templates/validation-plan.md`
- `templates/feature-priority-matrix.md`
- `templates/feasibility-scan.md`
- `templates/production-budget-snapshot.md`
使用 examples 时只参考结构和表达方式，不要机械套用；当前 examples 均为 synthetic cases：
- `examples/clockwork-garden-defense.md`
- `examples/clockwork-garden-defense-illustrated.md`
- `examples/dream-postman-card-adventure.md`
- `examples/tiny-crew-space-salvage.md`
## 硬规则
- 不要把题材当差异化。题材组合只有在改变玩家行为时，才可能成为设计核。
- 不要把世界观当玩法。设定必须创造行动、约束或选择，才有设计价值。
- 不要只列功能名；必须能说清玩家反复执行的动词，以及这些动词如何接到目标。
- 不要把随机性当万能调味料；必须说明它来自哪里、放在哪里、玩家如何理解失败。
- 不要用“内容很多”弥补核心循环薄弱；内容必须是核心循环的变奏和延展。
- 不要把受众写成人口标签；必须写出玩家想做什么、为什么兴奋、为什么反感。
- 不要把主题停留在剧情或美术；主题必须被操作、选择和后果承载。
- 不要因为某个系统是品类标配就加入它。
- 不要在一句话创意有多个合理方向时，过早锁死单一设计核。
- 不要把 assumption 藏在确定语气里。
- 不要输出无法测试的完整幻想文档。
- 当目标平台被说出或明显暗示时，不要跳过平台和商业适配。
- 不要把没有外部证据的市场判断写成事实。
- 不要为了显得完整而泛搜；先说明 VOI。
- 不要复制参考游戏的结构、术语、设定、阵营或内容表达；只抽取行为结构。
- 不要把团队未知或不可控的能力设计成核心卖点。
- 不要承诺需要长期大量内容产出的高光体验，除非写清内容产能验证方式。
- 没有通过标准和失败标准时，不要建议继续生产投入。
- 不要用“后续调优”代替验证计划。
- 不要把 `repo_example` 贡献规则误用为用户私有工作限制。
## 最低合格输出
`idea_triage` 至少包含：
```markdown
## Case Visibility
## Original Idea
## Concept Seed Extraction
## Player Verb Inventory
## Design Nucleus Options
## Action-Goal Alignment
## Assumption Ledger
## External Evidence Status
## Recommended Next Step
```
`one_page_pitch`、`full_design_brief` 和 `vertical_slice_plan` 至少包含：
```markdown
## Case Visibility
## Concept Seed Extraction
## Player Verb Inventory
## Design Nucleus Options
## Action-Goal Alignment
## Assumption Ledger
## External Evidence Status
## Player Promise
## Core Loop
## Production Feasibility
## Scope Gate
## Validation Plan
```
当使用 `full_design_brief` 时，还要包含：
```markdown
## Key Systems
## Uncertainty Calibration
## System Dynamics Map
## Content Flow Plan
## Audience Desire Map
## Playable Theme Map
## Platform and Business Fit
## Reference Game Boundary
## Feature Priority Matrix
## Risk Register
## Cost and Content Feasibility
```
当使用 `vertical_slice_plan` 时，还要包含：
```markdown
## Vertical Slice Goal
## Build Scope
## Milestones
## Playtest Protocol
## Next Investment Decision
```
## 输入不足时的处理
如果一句话创意过于模糊，不要默认停下。先输出 `idea_triage` 的低置信度版本，并清楚标记 assumptions。
只有当缺失信息会实质改变设计方向时，才提出澄清问题，例如目标平台、商业模式、团队规模、参考游戏是灵感来源还是硬约束。
澄清问题最多问三个。如果用户要求继续，就带着明确 assumptions 往前推进。