game-design-proposal-writer

name	game-design-proposal-writer
description	将调研、概念架构、体验诊断、验证计划、脑图/xmind/系统设计图、已有策划案和生产约束收束为商业游戏策划案、独立游戏设计案、立项评审稿、发行/投资 pitch 或 vertical slice 设计文档。适用于一句话创意先经 game-concept-architect 生成概念契约后再成案、玩法/系统脑图转可落地策划案、审核并改进已有策划案。强调证据边界、受众与商业适配、scope gate、里程碑、风险、决策请求和下一步投入条件；不替代上游创意生成或体验诊断。
metadata	{"short-description":"Write decision-ready commercial and indie game design proposals"}

Game Design Proposal Writer

使用本 skill 时，把已经存在的调研材料、创意方案、玩家承诺、竞品证据、体验诊断、ED 实验、生产约束和商业目标，整理成可以被制作人、老板、发行、投资人、合作方或独立团队成员评审的游戏策划案/独游设计案。

它不是普通 GDD 生成器，也不是把一句话创意扩写成长文的工具。创意还没有被拆出 design nucleus 时，优先提醒使用 game-concept-architect；样本体验还没有证据层时，优先提醒使用 game-experience-analyzer；需要一周体验实验时，优先提醒使用 game-experience-density-optimizer。本 skill 的核心工作是把上游产物变成一份有受众、有论证、有取舍、有风险、有下一步决策的文档。

如果用户给的是一句话创意，但明确要求“写策划案/立项案/独游设计案/pitch/GDD”，不要直接跳过上游。先调用 game-concept-architect 产出 concept brief、player-promise-contract、core loop、scope gate 和 validation plan，再用本 skill 成案。最终文档要标注“上游概念由本轮自动生成，证据等级仍为 assumption / needs_research”。

Users may use this skill with their own real projects or confidential projects in their own environment. Repository examples are governed by CONTRIBUTING.md, not by runtime restrictions.

什么时候使用

当用户想写、改写、压缩或评审以下材料时，使用本 skill：

• 商业游戏策划案、立项案、产品方案、项目建议书。
• 独立游戏设计案、GDD、Steam/发行 pitch、Demo/Vertical Slice 方案。
• 给老板、制作人、发行、投资人、合作方或团队看的项目说明。
• 把调研报告、创意方案、竞品分析、玩家承诺和验证计划整合成一份文档。
• 把一句话创意先经 game-concept-architect 拆成概念契约，再整理成正式策划案。
• 把玩法脑图、系统设计脑图、xmind、OPML、Markdown 大纲、Word/Excel 导出的设计表，整理成可落地策划案。
• 审核、重写、压缩或改进已有商业策划案、独游设计案、GDD、pitch outline、vertical slice 文档。
• 把过长、幻想化、没有决策点的设计案改成可评审版本。
• 需要说明平台、商业模式、目标用户、核心循环、系统范围、制作成本、里程碑和风险。

以下请求要强触发：

• 写一份商业游戏策划案
• 写一份独游设计案
• 写 GDD / Game Design Document
• 写立项案 / 项目方案 / 产品方案 / pitch deck 文案
• 给发行 / 投资人 / 老板看的游戏方案
• 把这个创意整理成正式策划案
• 只有一句话创意，帮我写成策划案 / 立项案 / pitch
• 这个 xmind / 脑图 / 系统图帮我做成可落地策划案
• 审核这份策划案 / 改进这份 GDD / 帮我把已有方案改成能评审的版本
• 把调研和创意合成一份文档
• 改成能立项评审的版本
• 做 vertical slice 文档 / demo 方案

不适用场景

如果用户只有一句话创意，并且目标是判断创意是否成立，应优先使用 game-concept-architect。如果用户同时要求产出策划案，本 skill 应作为第二步，在 game-concept-architect 输出后接续成案。

如果用户给的是录屏、PV、截图或试玩反馈，并希望诊断体验问题，应优先使用 game-experience-analyzer。

如果用户要的是首局节奏、反馈、具身感、氛围、认知负荷、留存或一周 A/B 实验，应优先使用 game-experience-density-optimizer。

如果用户只是要宣传文案、商店页短描述、众筹页面、PR 文案或广告脚本，本 skill 可以给文档中的定位和承诺，但不应替代专门的 marketing copywriting。

项目内上游产物审核门

写案前先做一次项目内协作自检，但不要把本 skill 退化成泛品类设计回答。本 skill 只负责把项目内其他 skill 或用户已有材料收束成评审文档，不继承项目外的全局设计总师口径。

• primary_category：先判断主品类/副品类、平台、商业模型和项目阶段。
• core_player_action：先看玩家反复做什么，再看题材、系统和文案。
• anti_pollution：商业案、独游案、Steam pitch、手游立项、Demo 文档不要互相套模板。
• proof_of_play：对外 pitch 必须说明 playable build、gameplay video、demo、vertical slice、玩家反馈或指标的状态。
• scope_feasibility：所有系统、内容、预算和里程碑都必须受团队能力约束。
• negative_example：至少写一个看似相似但不应采用/不应投递的反例。

如果用户的真实需求还停留在一句话创意、媒体样本诊断或体验浓度实验，应先交给项目内对应 skill 形成稳定上游产物，再由本 skill 负责整理成评审文档：

• game-concept-architect：输出 concept brief、player-promise-contract、core loop、scope gate 和 validation plan。
• game-experience-analyzer：输出 evidence-index、issue-card、sample boundary 和体验诊断。
• game-experience-density-optimizer：输出 ED handoff、一周实验、埋点字段、决策规则和 rollback 条件。
• game-design-source-curator：输出 source notes、reference boundary 和可追溯知识条目。

三类新增触发流程

一句话创意 -> 自动概念架构 -> 策划案

当输入只有一句话创意但目标是策划案时，按两段式执行：

1. 先用 game-concept-architect 生成 concept brief、player-promise-contract、core loop、scope gate、validation plan。
2. 再用本 skill 选择输出模式，生成商业策划案、独游设计案、一页 memo、pitch outline 或 vertical slice 文档。
3. 在 Source Artifact Inventory 里标注 generated_this_turn_by_game-concept-architect，不要伪装成用户已提供证据。

脑图 / xmind / 系统设计图 -> 可落地策划案

当用户给出 xmind、脑图截图、OPML、Markdown 大纲、Word/Excel 导出、玩法系统表或系统设计结构图时，先读取 references/mindmap-and-existing-proposal-input.zh-CN.md：

• 保留脑图层级，不要把节点直接散文化。
• 识别核心循环、系统模块、资源流、玩家行为、产出/消耗、成长线、内容范围、未决问题和冲突节点。
• 把“想法树”改成“制作树”：MVP、Vertical Slice、Demo、Release、Post-launch、Cut。
• 输出可落地策划案时必须补 owner、里程碑、验证标准和砍项理由。

审核 / 改进已有策划案

当用户给出已有策划案、GDD、pitch、立项文档或 vertical slice 文档并要求审核、重写、改进、压缩、变正式时：

• 先输出 proposal review，指出缺失、过度承诺、scope 风险、证据伪装、读者不匹配、无法执行的里程碑。
• 再输出 revision plan，说明保留什么、重写什么、删除什么、需要补什么证据。
• 用户要求直接改时，给出改写版，并保留 Change Log 和 Remaining Unknowns。

强制顺序

在写任何完整策划案前，必须按下面顺序完成。用户要求短稿时可以压缩，但不要跳过边界、证据、scope 和决策门。

1. proposal intake：确认文档受众、使用场景、输出模式、平台、商业模式、项目阶段和材料来源。
2. source artifact inventory：列出已有材料，例如 concept brief、player-promise-contract、validation plan、evidence-index、issue-card、ed-handoff、market/source notes、production profile。
3. case visibility：记录可见性、输出去向和是否需要脱敏。它只用于输出管理，不限制用户在本地环境处理真实项目。
4. document purpose：明确这份文档要推动什么决策，而不是只追求完整。
5. evidence and assumption boundary：把事实、引用、用户提供信息、模型推断、assumption 和 unknown 分开。
6. proposal mode selection：选择商业游戏策划案、独游设计案、一页决策 memo、发行 pitch outline 或 vertical slice design doc。
7. proposal spine：先写一句话定位、玩家承诺、核心循环、目标玩家、平台/商业假设和差异化边界。
8. scope and production gate：区分 MVP、Vertical Slice、Demo/公开试玩、Release、Post-launch、暂不开发和建议砍掉。
9. risk and validation narrative：写清最大风险、验证动作、通过/失败标准、下一步投入条件。
10. document assembly：再按选定模板写成正式文档。
11. quality gate：检查是否可评审、可执行、可删减、可验证，且没有把未知写成确定事实。

默认工作流

1. 读取 templates/proposal-intake.md，建立输入边界。若用户没有提供足够材料，不要停下；先产出 assumption draft，并最多提出 3 个会改变文档方向的问题。
2. 读取 references/proposal-intake-router.zh-CN.md，判断输出模式。
3. 如果用户给出上游产物，先抽取可复用 contract：玩家承诺、核心循环、验证计划、证据索引、问题卡、ED 实验、scope gate。不要改写成无法追溯的散文。
4. 如果用户给的是脑图/xmind/OPML/Markdown 大纲/系统图/已有策划案，读取 references/mindmap-and-existing-proposal-input.zh-CN.md，先做结构提取或 review，再成案。
5. 读取 references/evidence-assumption-boundary.zh-CN.md，把每个关键判断标成 provided、derived、external_evidence、assumption、unknown 或 needs_research。
6. 读取 references/commercial-game-proposal-framework.zh-CN.md 或 references/indie-design-dossier-framework.zh-CN.md，根据文档目标建立章节结构。
7. 读取 references/audience-business-scope-gate.zh-CN.md，检查目标玩家、平台、商业模式和 scope 是否互相支持。
8. 当任务涉及发行、投资、平台、Steam、孵化器、pitch deck、store page 或外部提交时，读取 references/publisher-platform-proof-gate.zh-CN.md，补齐 proof of play、publisher/platform fit、ask、budget、timeline 和 recheck gate。
9. 读取 references/scope-and-milestone-gates.zh-CN.md，输出里程碑和下一步投入条件。
10. 读取 references/pitch-document-quality-gate.zh-CN.md，执行最终文档门。
11. 按任务选择模板：

• templates/commercial-game-proposal.md
• templates/indie-design-dossier.md
• templates/one-page-decision-memo.md
• templates/publisher-pitch-outline.md
• templates/vertical-slice-design-doc.md
• templates/proposal-evidence-ledger.md
• templates/milestone-gate-plan.md
• templates/risk-register.md
• templates/existing-proposal-review.md

输出模式

模式	默认触发	交付重点
commercial_product_proposal	商业游戏、手游、网游、小游戏、F2P、内部立项、老板评审	产品定位、目标玩家、核心体验、系统与商业闭环、平台渠道、制作成本、指标、风险和立项决策
indie_design_dossier	独立游戏、Steam、主机/PC 买断、solo/small team、发行 pitch	创作命题、玩家幻想、可卖点、最小内容策略、vertical slice、制作边界、社区/发行验证和风险
one_page_decision_memo	用户要求快速判断、老板只看一页、会前材料	结论、为什么值得看、最大风险、最小验证、需要什么决策
publisher_pitch_outline	发行、投资、合作方、比赛/孵化器	可被外部人快速理解的 pitch 结构、卖点证明、demo 计划、团队可信度和请求
vertical_slice_design_doc	Demo、first playable、vertical slice、下一阶段制作	切片目标、功能边界、体验路径、资产/系统清单、里程碑、测试和 Go/No-Go
proposal_review_and_rewrite	审核/改进已有策划案、GDD、pitch、立项文档	问题诊断、证据/范围/读者/执行性修正、改写计划、可选改写版

如果用户说商业游戏策划案，默认使用 commercial_product_proposal。如果用户说独游设计案，默认使用 indie_design_dossier。如果用户说只要一页或先给老板看，默认使用 one_page_decision_memo。如果用户说给发行或投资人看，默认使用 publisher_pitch_outline。如果用户说做 demo 或 vertical slice，默认使用 vertical_slice_design_doc。

如果用户说“审核/改进/重写已有策划案/GDD/pitch”，默认使用 proposal_review_and_rewrite，除非用户明确只要最终改写版。

Case Visibility

case_visibility 只帮助 agent 管理输出边界，不限制用户在本地环境处理真实、私有或客户项目。

可选字段：

• 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 | publisher_pitch | internal_review | unknown
• redaction_required: true | false | unknown

当 output_destination=repo_example 时，必须提醒用户遵守 CONTRIBUTING.md。仓库 examples、assets、showcases、eval cases 只能使用 synthetic cases、公开材料或明确 cleared materials。

证据规则

• 没有来源时，不要写成市场事实。
• 没有用户提供团队规模、周期、预算或技术能力时，不要承诺大型在线、开放世界、实时多人、长期 live ops、大量剧情分支或高精度资产量产。
• 没有当前平台、商店、发行、竞品、买量或政策证据时，只能写成 assumption 或 needs_research。
• 发行方、投资方、孵化器和平台规则会变化；真实投递前必须重新检查目标页面，状态写成 verified_current、needs_recheck 或 unknown。
• 对外 pitch 不能只靠概念图、设定或 AI 视觉稿。没有 playable build、gameplay video、demo、vertical slice、玩家反馈或指标时，必须把 proof 写成 missing。
• 外部调研不是固定动作。只有当调研结果会改变定位、目标玩家、平台/商业模型、scope gate、风险等级或 Go/No-Go 时，才建议执行。
• 文档可以有愿景，但愿景必须和可验证路径分开。
• 参考游戏只能作为行为结构、受众动机、体验节奏或生产边界的参照；不要复制设定、术语、阵营、剧情、关卡或商业表达。
• 脑图、xmind 和系统图只说明“结构关系”，不自动等于已验证设计。节点必须转成玩家行为、系统责任、scope、风险和验证项。

商业游戏策划案硬规则

商业游戏策划案必须让评审者知道三件事：为什么值得做、做成什么算成立、下一步要花多少钱或多少人力去验证。

• 受众不能只写年龄、性别或泛二次元/泛休闲；必须写玩家行为、动机、付出意愿、拒绝点和相邻产品。
• 商业模式不能先行吞掉核心体验；广告、IAP、订阅、买断、赛季、付费皮肤、UGC 或 LiveOps 都要说明和玩家承诺的关系。
• 系统列表必须回连核心循环，不允许堆功能名。
• 指标不能只写 DAU、留存、收入；必须说明这些指标如何验证玩家承诺、循环强度或商业假设。
• 立项建议必须包含最大风险、最小验证、通过标准、失败标准和下一步投入条件。

独游设计案硬规则

独游设计案必须保护创作锋利度和制作边界。不要把商业游戏的全系统模板套进小团队项目。

• 先写创作命题、玩家幻想、可卖点和玩法承诺，再写系统清单。
• 目标玩家要写成细分动机和拒绝点，例如喜欢短局解谜中的顿悟、喜欢低压探索中的环境叙事、拒绝刷数值或强操作压力。
• 内容策略必须说明少量资产如何产生足够变化，而不是承诺大量关卡、剧情、角色或区域。
• 美术和音频方向要写 production boundary：哪些风格可以用小团队做，哪些会拖垮。
• Demo/Vertical Slice 要证明最独特的体验，而不是做一个正式版小切片。
• 发行、社区、愿望单、展会、众筹、媒体、创作者传播等内容必须标注为当前证据或待调研，不得写成确定机会。

最低合格输出

commercial_product_proposal 至少包含：

## Case Visibility
## Proposal Intake
## Source Artifact Inventory
## Executive Summary
## Product Positioning
## Target Player and Desire
## Player Promise
## Core Loop and Key Systems
## Platform and Business Fit
## Scope Gate
## Production Feasibility
## Milestone and Gate Plan
## Metrics and Validation Plan
## Risk Register
## Decision Request
## Evidence and Assumption Ledger

indie_design_dossier 至少包含：

## Case Visibility
## Proposal Intake
## Source Artifact Inventory
## Creative Thesis
## Store-Page Promise
## Target Player and Niche
## Player Verbs and Core Loop
## Design Pillars
## Content Minimalism Strategy
## Art and Audio Direction Boundary
## Vertical Slice Plan
## Production Plan
## Release and Community Validation
## Risk Register
## Next Investment Decision
## Evidence and Assumption Ledger

one_page_decision_memo 至少包含：

## Decision Memo
## Why This, Why Now
## Core Promise
## Biggest Assumptions
## Minimum Validation
## Scope and Cost Boundary
## Recommendation
## Decision Needed

publisher_pitch_outline 至少包含：

## Pitch Goal
## One-Line Pitch
## Market/Reference Boundary
## Player Promise
## Proof of Play
## Publisher / Platform Fit
## Demo or Vertical Slice Plan
## Production Credibility
## Ask, Budget, and Timeline
## Risk and Validation
## Materials Checklist
## Recheck Before Submission

vertical_slice_design_doc 至少包含：

## Slice Goal
## Experience Path
## Must-Prove Assumptions
## Build Scope
## Feature Priority
## Asset and Content Scope
## Milestones
## Playtest Protocol
## Go/No-Go Criteria
## Handoff Checklist

proposal_review_and_rewrite 至少包含：

## Review Target
## Reader and Decision Fit
## Structure Diagnosis
## Evidence and Assumption Problems
## Scope and Production Risks
## Missing Proof / Missing Decisions
## Revision Plan
## Suggested Rewrite
## Change Log
## Remaining Unknowns

输入不足时的处理

如果缺失信息很多，不要直接停下。先写低置信度版本，并明确标注 assumption 和 unknown。只有当缺失信息会改变文档模式或关键判断时，才提出澄清问题。最多问三个问题。

优先追问这些会改变文档方向的问题：

1. 文档受众是谁：内部老板、制作人、发行、投资人、团队成员，还是自己梳理？
2. 目标平台和商业模式是否已定？
3. 团队规模、周期、预算或当前项目阶段是什么？

如果用户要求继续，就带着明确假设往前推进。

输出门

最终输出前检查：

• 是否先写文档目标，再写章节内容。
• 如果输入是一句话创意，是否先形成 game-concept-architect 上游产物，再进入本 skill 成案。
• 如果输入是脑图/xmind/系统图，是否保留层级并转成可执行 scope、里程碑和验证项。
• 如果输入是已有策划案，是否先 review 再改写，而不是直接润色。
• 是否区分已提供事实、外部证据、推断、assumption、unknown 和 needs_research。
• 是否从玩家承诺和核心循环组织文档，而不是从功能清单堆起。
• 商业案是否说明目标玩家、商业模式、平台渠道、制作成本、指标和立项请求。
• 独游案是否保护创作命题、最小内容策略、制作边界和 demo 验证。
• 是否有 scope gate，而不是把所有想法都塞进正式版。
• 是否有里程碑、owner、成功标准、失败标准和下一步投入条件。
• 是否说明最大风险和最小验证。
• 是否避免没有证据的市场断言、收入承诺、愿望单承诺或买量判断。
• 对外 pitch 是否说明发行方/平台匹配、proof of play、ask、budget、timeline 和投递前重新检查项。
• 是否能被目标读者在 5 分钟内理解项目为什么值得继续看。