start
$
npx mdskill add pixel-cellar/Claude-Code-Game-Studios/start此技能是新用户的入口。它不会假设你已经有了游戏创意、引擎偏好或任何经验。它先询问,然后将你路由到正确的工作流。
SKILL.md
.github/skills/startView on GitHub ↗
--- name: start description: "首次入门引导 — 询问你当前处于哪个阶段,然后引导你进入正确的工作流。不做任何假设。" argument-hint: "[无参数]" user-invocable: true allowed-tools: Read, Glob, Grep, AskUserQuestion --- # 引导式入门 此技能是新用户的入口。它不会假设你已经有了游戏创意、引擎偏好或任何经验。它先询问,然后将你路由到正确的工作流。 --- ## 工作流 ### 1. 检测项目状态(静默) 在询问任何问题之前,静默收集上下文信息,以便量身定制你的引导建议。不要主动展示这些结果 — 它们用于指导推荐,而非作为对话开场白。 检查: - **引擎已配置?** 读取 `.claude/docs/technical-preferences.md`。如果 Engine 字段包含 `[TO BE CONFIGURED]`,说明引擎未设置。 - **游戏概念是否存在?** 检查 `design/gdd/game-concept.md`。 - **源代码是否存在?** 使用 Glob 搜索 `src/` 中的源文件(`*.gd`、`*.cs`、`*.cpp`、`*.h`、`*.rs`、`*.py`、`*.js`、`*.ts`)。 - **原型是否存在?** 检查 `prototypes/` 中的子目录。 - **设计文档是否存在?** 统计 `design/gdd/` 中的 Markdown 文件数量。 - **生产工件(Production Artifacts)?** 检查 `production/sprints/` 或 `production/milestones/` 中是否有文件。 在内部保存这些发现。你将用它们来验证用户的自评结果并定制后续推荐。 --- ### 2. 询问用户当前阶段 这是用户首先看到的内容。清晰地展示以下 4 个选项: > **欢迎使用 Claude Code Game Studios!** > > 在提出建议之前,我想了解你目前的起点。你的游戏创意现在处于哪个阶段? > > **A)还没有想法** — 我完全没有任何游戏概念。我想探索并弄清楚要做什么。 > > **B)模糊的想法** — 我有一个粗略的主题、感觉或类型方向(例如"跟太空有关的东西"或"一款温馨的农场游戏"),但还没有具体内容。 > > **C)清晰的概念** — 我知道核心想法 — 类型、基本机制,可能还有一句话的推介 — 但还没有正式形成文档。 > > **D)已有成果** — 我已经有了设计文档、原型、代码或重要的规划工作。我想整理或继续这些工作。 等待用户回答。在用户回复之前不要继续。 --- ### 3. 根据回答进行路由 #### 如果选 A:还没有想法 用户在进入其他任何环节之前需要创意探索。引擎选择、技术配置 — 这些都以后再说。 1. 确认从零开始完全没问题 2. 简要说明 `/brainstorm` 的作用(使用专业框架的引导式创意发想 — MDA 框架、玩家心理学、动词优先设计) 3. 建议下一步运行 `/brainstorm open` 4. 展示推荐路径: - `/brainstorm` — 发现你的游戏概念 - `/setup-engine` — 配置引擎(brainstorm 会推荐一个) - `/map-systems` — 将概念拆解为系统并规划 GDD(游戏设计文档)编写顺序 - `/prototype` — 测试核心机制 - `/sprint-plan` — 规划第一个冲刺(Sprint) #### 如果选 B:模糊的想法 用户有一个种子想法,但需要帮助将其发展成完整概念。 1. 请他们分享模糊的想法 — 哪怕几个字就够了 2. 确认这是一个好的起点(不要评判或改变方向) 3. 建议运行 `/brainstorm [他们的线索]` 来发展它 4. 展示推荐路径: - `/brainstorm [线索]` — 将想法发展为完整概念 - `/setup-engine` — 配置引擎 - `/map-systems` — 将概念拆解为系统并规划 GDD 编写顺序 - `/prototype` — 测试核心机制 - `/sprint-plan` — 规划第一个冲刺 #### 如果选 C:清晰的概念 用户知道自己要做什么,但还没有形成文档。 1. 提出 2-3 个后续问题来了解他们的概念: - 类型和核心机制是什么?(一句话) - 有引擎偏好吗,还是需要帮助选择? - 大致规模如何?(Game Jam 游戏、小型项目、大型项目) 2. 根据他们的回答,提供两条路径: - **先正式化**:运行 `/brainstorm`,将概念结构化为正式的游戏概念文档,包含游戏支柱(Pillars)、MDA 分析和规模层级 - **直接配置引擎**:如果用户对概念很有信心,直接进入 `/setup-engine`,之后手动编写 GDD 3. 展示推荐路径(根据他们的选择调整): - `/brainstorm` 或 `/setup-engine`(由用户选择) - `/design-review` — 验证概念文档 - `/map-systems` — 将概念拆解为独立系统,标记依赖关系和优先级 - `/design-system` — 编写各系统的 GDD(引导式,逐节完成) - `/architecture-decision` — 做出第一批技术决策 - `/sprint-plan` — 规划第一个冲刺 #### 如果选 D:已有成果 用户已经有工件了。弄清楚什么存在、什么缺失。 1. 分享你在步骤 1 中的发现(现在它相关了): - "我看到你有 [X 个源文件 / Y 份设计文档 / Z 个原型]..." - "你的引擎 [已配置为 X / 尚未配置]..." 2. 建议运行 `/project-stage-detect` 进行全面分析 3. 如果引擎未配置,指出应先运行 `/setup-engine` 4. 展示推荐路径: - `/project-stage-detect` — 全面的缺口分析 - `/setup-engine` — 如果尚未配置 - `/design-system` — 如果系统索引存在但 GDD 不完整 - `/gate-check` — 验证是否准备好进入下一阶段 - `/sprint-plan` — 整理工作 --- ### 4. 继续前确认 在展示推荐路径后,询问用户想先执行哪一步。永远不要自动运行下一个技能。 > "你想从 [推荐的第一步] 开始,还是想先做其他事情?" --- ### 5. 交接 当用户选择下一步时,让他们自己调用技能,或者主动提出帮他们运行。无论哪种方式,一旦用户有了明确的下一步行动,`/start` 技能的任务就完成了。 --- ## 边界情况 - **用户选了 D 但项目为空**:温和地引导 — "看起来项目是一个全新模板,还没有任何工件。路径 A 或 B 可能更合适?" - **用户选了 A 但项目中有代码**:提及你的发现 — "我注意到 `src/` 中已有代码。你是想选 D(已有成果)吗?还是想用新概念重新开始?" - **用户是回访者(引擎已配置、概念已存在)**:完全跳过入门 — "看起来你已经配置好了!引擎是 [X],游戏概念在 `design/gdd/game-concept.md`。想从上次停下的地方继续吗?试试 `/sprint-plan`,或者直接告诉我你想做什么。" - **用户不属于任何选项**:让他们用自己的话描述情况,然后灵活适配。4 个选项是起点,不是牢笼。 --- ## 协作协议 此技能遵循协作设计原则: 1. **先询问** — 永远不要假设用户的状态或意图 2. **展示选项** — 给出清晰的路径,而非命令 3. **用户决定** — 由他们选择方向 4. **不自动执行** — 推荐下一个技能,但不要未经询问就运行 5. **灵活适配** — 如果用户的情况不符合模板,倾听并调整
More from pixel-cellar/Claude-Code-Game-Studios
- architecture-decision创建架构决策记录(Architecture Decision Record, ADR),记录重大技术决策及其背景、备选方案和影响后果。每个重大技术选择都应有对应的 ADR。
- estimate通过分析复杂度、依赖关系、历史速度和风险因素来估算任务工作量。生成包含置信水平的结构化估算。
- localize运行本地化工作流:提取字符串、验证本地化就绪状态、检查硬编码文本,并生成可供翻译的字符串表。
- map-systems将游戏概念拆解为独立系统,映射依赖关系,确定设计优先级,并创建系统索引。
- milestone-review生成全面的里程碑进度审查,包括功能完成度、质量指标、风险评估和推进/暂停建议。在里程碑检查点或评估里程碑截止日期的准备情况时使用。
- patch-notes从 git 历史记录、Sprint 数据和内部更新日志生成面向玩家的补丁说明。将开发者语言转化为清晰、有吸引力的玩家沟通内容。
- perf-profile结构化的性能分析工作流。识别瓶颈、与性能预算对比测量,并生成带有优先级排序的优化建议。
- playtest-report生成结构化的试玩报告模板,或将现有试玩笔记分析为结构化格式。用于标准化试玩反馈的收集和分析。
- project-stage-detect自动分析项目状态、检测开发阶段、识别缺失项,并根据现有工件推荐后续步骤。
- release-checklist生成全面的发布前验证清单,涵盖构建验证、合规要求、商店元数据和发布准备就绪情况。