Project Start Skill

1. 目标

将一个未经整理的新游戏想法，初始化为 GameStudio 标准项目。

标准流程：

新想法
→ 明确项目边界
→ 建立项目目录
→ 建立 AI 文档层
→ 整理 GAME.md
→ 拆解 TASKS.md
→ 建立 DECISIONS.md
→ 建立 BUGS.md
→ 建立 CHANGELOG.md
→ 建立 AGENTS.md
→ 更新 GameStudio 全局索引
→ 进入 Prototype 开发

本 Skill 负责“项目初始化”，不负责直接完成游戏开发。

2. 核心原则

2.1 先建立结构，再开始开发

不要在一个空文件夹里直接让 执行代理 大量写代码。

必须先建立：

• 项目身份
• 游戏设计文档
• 任务队列
• 决策记录
• Bug 记录
• AI 协作规则

然后再进入代码阶段。

2.2 不替用户决定核心玩法

如果用户只提供：

> “我想做一个类似 XXX 的小游戏。”

可以整理、提问、拆解，但不能擅自确定：

• 核心胜负规则
• 关卡数量
• 数值
• 商业模式
• 美术风格
• 操作方式
• 技术栈

如果缺失，标记：

待定义

而不是自行补全成事实。

2.3 区分三种信息

所有项目文档中的信息尽量区分：

• 已确认：用户明确提出或已经决定
• 推测：AI 根据已有信息提出的合理推断
• 待确认：目前无法确定

未经用户确认的推测不得写入“最终决策”。

2.4 小游戏优先 Prototype

初始化阶段默认目标不是“做完整游戏”，而是：

> 尽快建立一个可以运行、可以试玩、可以验证核心玩法的 Prototype。

3. 项目位置

默认 GameStudio 结构：

GameStudio/
├─ STUDIO.md
├─ STUDIO_TASKS.md
├─ _shared/
│ ├─ AI_RULES.md
│ ├─ CODING_RULES.md
│ └─ tools/
├─ 01_MainGame/
├─ 02_Prototype/
├─ 03_Experiment/
└─ ...

新项目应根据 STUDIO.md 当前项目编号和项目状态选择目录。

推荐状态：

IDEA
→ PROTOTYPE
→ MVP
→ VERTICAL_SLICE
→ PRODUCTION
→ RELEASE
→ MAINTENANCE

特殊状态：

PAUSED
ABANDONED

如果项目只是玩法验证，优先归入：

Prototype / Experiment

如果用户明确指定项目目录，服从用户指定。

4. 初始化前检查

开始创建文件之前，先检查：

1. GameStudio 根目录是否存在
2. STUDIO.md 是否存在
3. STUDIO_TASKS.md 是否存在
4. _shared/ 是否存在
5. 是否已经存在同名项目
6. 用户是否已经指定技术栈
7. 用户是否已经指定引擎
8. 用户是否已经提供旧文件或参考资料
9. 当前项目是否属于已有项目的继续开发

如果发现同名项目：

不要直接覆盖。

应报告：

• 已存在项目
• 项目路径
• 项目状态
• 是否建议继续已有项目

5. 项目命名

命名优先级：

1. 用户明确指定名称
2. 用户提供的正式项目名称
3. 已有设计文档中的项目名称
4. 创意标题
5. 临时名称

如果只能使用临时名称：

例如：

03_GridPlatformPrototype

同时在 README.md 标记：

正式项目名：待定义

不要因为方便而永久锁定临时名称。

6. 技术栈处理

如果用户已经指定：

• Unity
• Godot
• Unreal
• HTML5
• JavaScript
• TypeScript
• Python
• 其他引擎或框架

则按照用户选择初始化。

如果没有指定技术栈：

不要擅自安装依赖。

在 README.md 中写：

技术栈：待定义

并在 TASKS.md 创建：

T-001 确定项目技术栈

如果项目只是玩法验证，可以允许先使用最简单的技术方案进行 Prototype。

7. 标准项目结构

创建：

项目名/
├─ AGENTS.md
├─ README.md
├─ docs/
│ ├─ GAME.md
│ ├─ TASKS.md
│ ├─ BUGS.md
│ ├─ DECISIONS.md
│ └─ CHANGELOG.md
├─ src/ # 非引擎项目按需创建
├─ assets/ # 按需创建
├─ tests/ # 按需创建
└─ builds/ # 按需创建

如果使用 Unity / Godot / Unreal：

保留其原生目录结构。

不要为了套模板强行建立：

src/
assets/

例如 Unity 应优先保持：

Project/
├─ Assets/
├─ Packages/
├─ ProjectSettings/
└─ ...

本 Skill 标准化的是“项目文档层”，而不是强行统一所有引擎的代码目录。

8. GAME.md

GAME.md 是项目的核心设计文档。

推荐结构：

GAME

1. 项目概述

• 项目名称
• 项目类型
• 当前阶段
• 项目目标
• 当前版本

2. 核心体验

玩家应该获得什么体验？

3. 核心玩法

• 玩家是谁
• 玩家做什么
• 游戏如何反馈
• 如何获得成功
• 如何失败

4. 核心循环

例如：

进入关卡
→ 探索
→ 操作
→ 获得反馈
→ 做出决策
→ 完成目标
→ 下一阶段

5. 游戏规则

只记录已经确认的规则。

6. 关卡设计

如果尚未设计：

待定义

7. 数值设计

如果尚未确定：

待定义

8. UI

记录已经确定的 UI。

9. 美术

记录已经确定的风格和资源需求。

10. 音频

记录已经确定的音频需求。

11. 技术要求

• 引擎
• 平台
• 输入
• 性能目标
• 存档
• 网络
• 其他

12. 当前已知问题

不要在这里详细管理 Bug。

只保留影响设计理解的重要问题。

9. TASKS.md

TASKS.md 是 执行代理 的主要执行入口。

使用：

T-001
T-002
T-003

状态：

TODO
DOING
DONE
BLOCKED

优先级：

P0
P1
P2

推荐格式：

T-001

• 状态：TODO
• 优先级：P0
• 类型：Design / Code / Art / Test / Tool
• 目标：
• 前置条件：
• 需求：
• 验收标准：
• 相关文档：

重要原则：

任务必须尽可能可以被单独执行和验收。

不要把：

“把游戏做出来”

作为一个任务。

应该拆成：

T-001 创建玩家控制
T-002 创建基础场景
T-003 创建核心交互
T-004 创建胜利条件
T-005 创建失败条件
T-006 建立最小 UI
T-007 完成 Prototype 测试

10. MVP / Prototype 拆解规则

对于新小游戏，默认先建立：

P0：能玩

必须包括：

• 玩家进入游戏
• 核心操作
• 核心规则
• 最基本反馈
• 最基本胜负条件

P1：好玩

包括：

• 数值调整
• 关卡变化
• 反馈优化
• 操作手感
• 基础 UI
• 基础音效

P2：完整

包括：

• 内容扩充
• 美术优化
• 更多关卡
• 存档
• 设置
• 商业化
• 发布准备

不要在 P0 阶段大量开发 P2 功能。

11. DECISIONS.md

只记录已经确定的决策。

例如：

D-001

决策

游戏采用俯视视角。

原因

便于玩家观察空间关系。

日期

YYYY-MM-DD

状态

FINAL

禁止把：

• AI 提议
• 用户犹豫
• 多个候选方案
• 尚未验证的假设

直接写成 FINAL。

12. BUGS.md

初始化时建立空 Bug 数据库：

BUGS

暂无已确认 Bug。

推荐格式：

BUG-001

• 状态：OPEN
• 严重程度：P0 / P1 / P2
• 现象：
• 复现步骤：
• 预期：
• 实际：
• 相关任务：
• 修复方案：
• 验证：

13. CHANGELOG.md

新项目没有历史版本时：

不要伪造历史。

初始化记录：

Unreleased

Added

• 创建项目
• 建立标准项目文档
• 建立 AI 协作规则

如果后续完成：

Prototype v0.1
MVP v0.2

再正式记录。

14. README.md

README.md 用于让任何 AI 或开发者快速理解项目。

必须包括：

Project Name

项目状态

项目类型

技术栈

当前目标

核心玩法一句话

项目结构

AI 协作方式

策划助手

负责：

• 游戏设计
• 需求分析
• 数值分析
• 任务拆解
• Bug 分析
• 设计评审

执行代理

负责：

• 编码
• 文件修改
• 测试
• Bug 修复
• 技术实现

用户

负责：

• 最终设计决策
• 游戏体验判断
• 验收

15. AGENTS.md

为 执行代理 建立项目级规则。

至少包括：

项目规则

1. 开始任务前读取 README.md。
2. 涉及游戏规则时读取 docs/GAME.md。
3. 按 docs/TASKS.md 执行任务。
4. 不得擅自改变已经确认的核心玩法。
5. 不得把推测当成需求。
6. 优先进行最小修改。
7. 不进行无关重构。
8. 不擅自升级引擎。
9. 不擅自安装依赖。
10. 完成后必须测试。
11. 测试失败必须记录。
12. 修改核心规则前必须先更新设计决策。
13. 不访问其他项目目录，除非用户明确要求。
14. 不复制其他项目代码，除非用户明确授权。
15. 不读取或输出密钥、Token、密码等敏感信息。

16. 初始任务生成

初始化完成后，至少创建以下任务：

如果玩法尚未明确：

T-001 明确核心玩法
T-002 明确玩家操作
T-003 明确胜负条件
T-004 确定技术栈

如果玩法已经明确：

T-001 创建最小可运行场景
T-002 实现玩家控制
T-003 实现核心玩法
T-004 实现胜利条件
T-005 实现失败条件
T-006 Prototype 测试

任务必须根据实际项目调整。

不要机械生成不存在的功能。

17. STUDIO.md 更新

创建项目后，必须更新 GameStudio/STUDIO.md。

推荐：

如果 STUDIO.md 原本采用其他格式：

保持原格式，不要强行重写。

18. STUDIO_TASKS.md 更新

只添加跨项目任务。

例如：

ST-001

• 项目：Project A
• 目标：完成核心玩法 Prototype
• 状态：DOING

不要把所有 T-001、T-002 都复制到 STUDIO_TASKS.md。

Studio 层只负责：

> 项目级目标

Project 层负责：

> 具体执行任务

19. 策划助手 使用方式

策划助手 默认负责：

> 想清楚

新项目阶段可以使用：

“分析这个游戏创意，不写代码。判断核心玩法、玩家循环、主要风险，并把确认内容整理进 GAME.md，同时把需要我决定的问题列出来。”

当设计基本确定：

“读取项目文档，将当前设计拆成可执行的 Prototype 任务，更新 TASKS.md，不写代码。”

20. 执行代理 使用方式

执行代理 默认负责：

> 做出来

推荐最小 Prompt：

“读取项目文档。执行 TASKS.md 中的 T-001。完成后测试并报告。”

不要每次把完整游戏设计重新粘贴给 执行代理。

文件就是长期上下文。

21. 设计变更流程

如果用户提出：

> “把玩家移动方式改成跳跃。”

不要直接让 执行代理 修改代码。

流程：

用户提出修改
→ 策划助手 分析影响
→ 更新 GAME.md
→ 如为正式决策，记录 DECISIONS.md
→ 更新 TASKS.md
→ 执行代理 执行
→ 测试
→ 更新 CHANGELOG.md

22. Bug 流程

用户：

> “刚才那个关卡过不去了。”

策划助手：

1. 判断是否为设计问题还是程序 Bug
2. 如果是 Bug，创建 BUG-XXX
3. 分析原因
4. 创建或关联 T-XXX
5. 不直接进行大规模代码修改

执行代理：

1. 读取 BUGS.md
2. 定位问题
3. 最小修改
4. 测试
5. 更新 Bug 状态

23. 项目隔离

处理 Project A 时：

默认只能读取：

• Project A
• GameStudio/_shared
• GameStudio/STUDIO.md
• GameStudio/STUDIO_TASKS.md

不要自动读取：

• Project B
• Project C
• 其他实验项目

除非用户明确要求。

这样可以避免：

• 设计串项目
• 代码串项目
• AI 上下文污染
• 错误复用

24. 可复用系统

如果新项目产生了可能适用于其他项目的：

• UI 系统
• 存档系统
• 输入系统
• 工具
• 编辑器工具
• 通用脚本

先标记：

Reusable Candidate

不要立即移动到：

_shared/

经过实际验证后，再由用户决定是否提取。

25. 安全规则

不得：

• 删除用户已有文件
• 覆盖已有项目
• 自动删除代码
• 自动升级引擎
• 自动升级依赖
• 自动执行危险命令
• 泄露 .env
• 输出 API Key
• 输出 Token
• 输出密码
• 修改其他项目

如果发现敏感文件：

只记录：

发现潜在敏感配置文件，未读取或复制其敏感内容。

26. 初始化完成后的输出

完成后不要输出大量文件内容。

只报告：

项目

项目名：

路径：

状态：

技术栈：

已创建

• AGENTS.md
• README.md
• docs/GAME.md
• docs/TASKS.md
• docs/BUGS.md
• docs/DECISIONS.md
• docs/CHANGELOG.md

当前 P0

• T-001
• T-002
• T-003

待确认

• 技术栈
• 核心规则
• 平台
• 其他关键问题

下一步

建议：

> 先完成 P0 Prototype，不要提前扩展完整内容。

27. 标准工作流

新游戏：

创意
↓
project-start
↓
项目初始化
↓
GAME.md
↓
用户确认设计
↓
DECISIONS.md
↓
TASKS.md
↓
执行代理 执行 P0
↓
Prototype
↓
试玩
↓
BUGS.md
↓
修复
↓
再次试玩
↓
MVP

28. 与 Project Intake Archiver 的关系

两个 Skill 配套使用：

新项目

project-start

负责：

> 创意 → 标准项目

外部已有项目

project-intake-archiver

负责：

> 外部项目 → GameStudio 标准项目

二者最终都应该进入相同的：

• AGENTS.md
• README.md
• GAME.md
• TASKS.md
• BUGS.md
• DECISIONS.md
• CHANGELOG.md

因此无论项目来自：

• 新创意
• AI 生成
• 外部文件夹
• 旧项目
• 其他开发环境

最终都能进入统一的 GameStudio 工作流。

29. 推荐调用方式

新建小游戏：

> 创建一个新项目，名字叫“XXX”，使用 Unity。按照 project-start 初始化，不要写游戏代码。

已有创意但没有技术栈：

> 把这个游戏创意初始化成 GameStudio 项目。先整理设计，不要写代码，并把所有待确认问题列出来。

进入开发：

> 读取项目文档，执行 TASKS.md 中的下一个 P0 任务。

30. 最终原则

这个 Skill 的核心不是“自动生成一个游戏”。

而是：

> 把一个模糊的游戏想法，变成一个 AI 可以长期、低 Token、低污染、高可控地参与开发的项目。

最终分工：

策划助手 = 想清楚
执行代理 = 做出来
文档 = 记住
用户 = 决定和验收
GameStudio = 管理多个项目

31. Aseprite 美术资产初始化

初始化标准项目时，除 AGENTS.md / README.md / docs/* 外，一并建立美术文档层：

• docs/ART_GUIDE.md：美术规范（风格、视角、像素基准尺寸、调色板、轮廓、透明背景、帧布局、验收标准）
• docs/ASSET_REGISTRY.md：资产登记表（ASSET-XXX、源文件、导出文件、规格、版本、状态、关联任务与验收记录）

模板来源：<工作区根>/_shared/templates/（由 game-studio 首次初始化工作区时生成）。只填写已确认内容，未定项一律写"待确认"，不替用户决定美术风格、尺寸或调色板。

目录建议（仅在确实需要素材时创建，不强制，引擎原生结构优先）：

assets/source/aseprite/ Aseprite 源文件
assets/export/ 导出文件（按引擎实际目录调整）
assets/preview/ 预览与对比图
assets/references/ 参考资料

规则：

1. 不覆盖、删除或修改 Aseprite 源文件与用户原稿。
2. 美术需求整理、资产登记与状态流转交由 art-asset-manager 处理。
3. 只有 ASSET_REGISTRY 中状态为 APPROVED 的素材才能建立正式接入任务。
4. 初始化本身不构成开发授权，不调用 执行代理。