game-design-proposal-writer

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

用户可在自己的环境中处理真实项目、私有项目或客户项目。准备公开仓库案例时，只能使用 synthetic、公开或明确授权的材料，并在发布前执行 Human Gate。

什么时候使用

当用户想写、改写、压缩或评审以下材料时，使用本 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：至少写一个看似相似但不应采用/不应投递的反例。