---
name: start-project
description: Guide a beginner from an idea or empty folder to a ready, well-structured coding project. Use when the user wants to start a project from zero, begin vibe coding safely, choose a platform, game engine or framework, define a North Star and MVP, plan architecture and folders, initialize Git, establish an acceptance Harness, or create the first verified vertical slice before normal implementation.
---

# 从零做项目

把模糊想法转成可以安全开发的项目。先完成产品、技术和执行准备，再写正式功能。用通俗语言解释选择，但不要把能由 Codex 调查的工程问题推给零经验用户。

## 基本原则

1. 每批最多询问 3 个相关问题，跳过用户已经回答的内容。
2. 技术选择给出一个明确推荐和一个备选，不罗列一堆工具让用户盲选。
3. 区分用户决策与 Codex 调查：用户决定体验、受众、预算和边界；Codex 调查技术、结构、工具链和风险。
4. 版本、价格、许可、商店规则和平台支持容易变化；推荐前查询官方当前资料。
5. 先锁定高成本、难回退的决策，再尽快做垂直切片；不要先写完整大项目，也不要无限规划。
6. 没有完成信号就不实现，没有验证就不宣称完成。

## 第 0 阶段：判断起点

有项目目录时先运行：

```powershell
python <skill-dir>/scripts/inspect_project.py <project-root>
```

根据结果选择模式：

- `idea`：只有想法，尚无目录。
- `empty`：已有空目录，尚无代码。
- `existing`：已有代码或脚手架。
- `resume`：已有项目，需要跨会话恢复。

`existing` 和 `resume` 模式优先读取并执行已安装的 `$project-readiness-gate`；如果未安装，则直接使用本 skill 第 5 阶段的同等门禁。不要用新项目模板覆盖已有结构。

## 第 1 阶段：把想法说清楚

第一批只确认：

1. 想做什么，谁会使用或游玩。
2. 用户完成一次核心体验时具体做什么。
3. 已知平台、参考产品和不能接受的结果。

游戏项目再逐步确认：2D/3D、单机/联网、单局时长、操作方式、商业模式、团队与时间。普通应用改问核心工作流、数据来源、账号/权限、离线需求和目标设备。

回答仍模糊时，用“用户打开产品后的前 5 分钟会发生什么”继续收敛。根据结果起草 `NorthStar.md`，让用户确认核心价值、取舍顺序和明确边界。北极星未确认前不进入正式实现。

创建项目文档时读取 [references/templates.md](references/templates.md)。

## 第 2 阶段：选择平台和技术

读取 [references/decision-guide.md](references/decision-guide.md)，按以下因素决策：

- 目标平台和最低设备。
- 2D/3D、UI 密度、实时性和性能目标。
- 输入方式、联网、存档、账号和外部 SDK。
- 团队经验、资产制作方式、预算和交付时间。
- 发布商店、部署、许可和后续维护成本。

输出一份简短技术决策：

```text
推荐方案 / 推荐理由
备选方案 / 何时改选
明确排除 / 排除理由
主要风险 / 最小验证实验
```

把确认结果写入 `docs/decisions/0001-platform-and-stack.md`。平台、引擎或框架未确认前，不生成正式项目脚手架。

## 第 3 阶段：确定第一版范围

同时定义三层：

- `最终方向`：来自 North Star。
- `当前里程碑`：本阶段要证明什么。
- `首个垂直切片`：最短但完整的用户闭环。

例如游戏垂直切片可以是：启动 -> 教学 -> 一局 -> 结果 -> 再来一局。普通应用可以是：进入 -> 创建一条数据 -> 查看 -> 修改 -> 重新打开后仍存在。

明确列出“本阶段不做”。账号、广告、支付、多人、完整内容库和精细动效只有在垂直切片确实需要时才进入。

## 第 4 阶段：规划结构

结构必须服务首个垂直切片，并遵循所选引擎或框架的官方惯例。不要为了显得专业提前引入微服务、复杂状态框架、ECS、插件系统或多层抽象。

至少明确：

- 入口、导航或场景流转。
- 页面/功能模块及所有者。
- 核心状态、数据模型和持久化边界。
- 输入、业务/玩法规则和渲染/UI 的边界。
- 资源、音频、配置和本地化组织方式。
- 外部服务、失败降级和平台差异。
- 测试、调试、日志和性能观测入口。

新项目的 `context.md` 记录“计划结构”和假设，不能伪装成已实现事实。实现后及时改成真实结构。UI 项目同时创建 `style.md`。

## 第 5 阶段：建立执行护栏

已安装 `$project-readiness-gate` 时读取并执行它；未安装时由本阶段独立完成同等检查。补齐：

- `AGENTS.md`：工作规则、权限和代码规范。
- `NorthStar.md`：长期方向和取舍。
- `context.md`：架构地图。
- `style.md`：UI/视觉项目使用。
- `Harness.md`：阶段目标、完成信号、验证权限、停止条件和提交规则。

只有 North Star、架构地图、Harness 和当前任务前置检查均为 `READY`，才进入正式实现。

## 第 6 阶段：初始化项目与 Git

读取 [references/git-workflow.md](references/git-workflow.md)。执行前确认用户授权边界。

1. 使用官方或成熟脚手架创建最小项目，不手写大量基础设施。
2. 创建适配技术栈的 `.gitignore`，检查密钥、证书、构建产物和大文件。
3. 建立最小可运行/可检查基线。
4. 运行允许的格式、静态检查、测试或构建。
5. 用户已授权提交时，创建“项目基线”提交；否则展示精确提交边界。

已有仓库禁止重复 `git init`、覆盖忽略规则或改写历史。

## 第 7 阶段：进入开发循环

已安装 `$karpathy-guidelines` 时读取并应用它；未安装时仍要遵守最小实现、精准修改、显式假设和可验证完成标准。

```text
选择一个可独立验收任务
-> 追踪入口、状态所有者、调用链和副作用
-> 给出方案与质量评估
-> 实现
-> 按 Harness 验证
-> 验收通过后形成小提交
-> 更新 context / 决策记录
-> 再领取下一任务
```

窗口可以长期负责一条主线，但每轮只做一个验收节点。新的独立需求先排队，不叠加到未验收节点中。

## 专项 Skill 路由

根据已安装能力选择最具体的 skill，不在本 skill 内重复专业知识：

- 浏览器游戏早期选型：`game-studio:game-studio`、`game-studio:web-game-foundations`。
- Phaser、Three.js、React Three Fiber：路由到对应 game-studio 实现 skill。
- Unity 已确定：`unity-developer`。
- ASP.NET Core：`aspnet-core`。
- ChatGPT App：`chatgpt-apps` 或对应 OpenAI 开发 skill。
- GDD、游戏 UI、平衡、关卡、部署：路由到对应专业 skill。
- 项目计划和里程碑：`project-manager`。

专项 skill 的默认建议不得覆盖已确认的 North Star、平台约束和 Harness。

## 必须停止的情况

- 用户还没有确认核心体验或产品取舍。
- 平台或引擎选择依赖尚未回答的高成本决策。
- 当前官方支持、许可或商店规则没有核实。
- 架构无法支持首个垂直切片。
- Harness 缺失或验证权限不清楚。
- 现有仓库有无法归属的修改，可能与其他窗口冲突。
- 验证失败，或只能静态检查但任务要求证明运行行为。

停止时只询问真正阻塞的一小组问题，同时继续完成不依赖答案的只读调查。

## 开工报告

正式实现前输出：

```text
产品方向：READY / BLOCKED
平台与技术：READY / BLOCKED
首个垂直切片：READY / BLOCKED
项目结构：READY / BLOCKED
Harness：READY / BLOCKED
Git 基线：READY / BLOCKED
```

全部为 `READY` 后，给出第一个小任务及其验收方式，不直接启动一批长任务。