/start

name: start
description: "Guides a first-time user through onboarding and picks the right workflow. Use when the user is new, just cloned or installed the studio, has no idea or engine yet, asks where to begin, or wants to bring in an existing game. A request for a game itself ('make me a game where...') is /prototype's."
argument-hint: "[no arguments]"
user-invocable: true
allowed-tools: Read, Glob, Grep, AskUserQuestion, Skill, Bash(bash .claude/scripts/project-state.sh*), Bash(bash .claude/scripts/set-stage.sh *), Bash(bash .claude/scripts/config-set.sh *)
model: sonnet

Guided Onboarding

The entry point for a new user. It assumes no game idea, no engine and no experience: it reads the project, asks where the user is starting from, shows what it assumes about the project, and names the one next step. It never runs that step itself, except for a game the person described in their own words, which goes straight to `/prototype` (One-shot 1).

The main path leads: make a game (`/prototype`), change it after play, grow it into a project. The design documents, the agents and the `team-*` pipelines are studio mode, the path at rigor `standard` and `full` (Phase 6).

It writes these settings to `project.yaml`, all through helpers, and only after an explicit yes: `project.stage` (with its legacy mirror `production/stage.txt`), `project.goal`, `modes.rigor` and `modes.automation`. It never writes `modes.review_mode` or `production/review-mode.txt`, and none of the other knobs rigor fronts (`modes.workflow`, `docs.density`, `qa.level`, `modes.story_granularity`, `team.size`): a written value pins that knob over the rigor expansion, and a mirror file outranks it. The make-me-a-game route writes nothing: `/prototype`'s card is that route's assumptions card.

Ask with the question tool. Without one, list the options numbered and end your turn to wait. The question is the last thing in the reply: no path, note or advice after it. A skipped or dismissed question is not an answer: ask again in plain text.

The questions in Phases 2, 4 and 5 shape the project, so they are asked in every automation mode. The engine is not one of them: `/setup-engine` chooses it. Phase 6's last question follows a `modes.automation` already in `project.yaml`, per `.claude/docs/automation-modes.md`; with none set, ask it.

Phase 1: Read the project

**A game already asked for.** When the message that started this skill asks for a game itself ("make me a game", or a description of one: "a game where you herd sheep with a dog") and the person did not type `/start`, ask nothing and read nothing. Say in one line that you are taking them straight to the build, then start `/prototype` with the Skill tool and no arguments: it reads their message as their words and asks only what is missing. This is the one step this skill runs itself, and only because it was started for them: a typed `/start` runs its turn on this skill's own model, and the build must run on the session's (Phase 7).

**A game brought.** When that message brings a game the person already has (a path to an `.html` file or a folder, or "bring in my game"), do the same with `/prototype --from <path>`.

Run `bash .claude/scripts/project-state.sh` and keep its rows. Do not show them yet; they check the user's answer in Phase 2.

| Row | Use | |---|---| | `engine`, `code_root`, `source_files` | Is an engine set, and how much code is there. `source_files` of `unknown` means the code root could not be found: say that, never "no code" | | `concept` | `design/gdd/game-concept.md` or `design/game-brief.md` exists | | `gdd_files`, `adr` | Design documents and architecture decisions on disk (they set the stage in Phase 4) | | `prototype`, `sprint`, `milestone`, `story` | Other existing work | | `origin_url` | Contains `donchitos/claude-code-game-studios`, matched case-insensitively: the clone still points at the template repo, so a push or pull request would go there. A fork under another owner is the user's own | | `stage` | The stage already recorded, if any |

Ignore `phase_inferred`: it guesses from file counts, and a project with code but no design documents is not in Production. If the helper fails, say so and read the same facts by hand (engine in `project.yaml`, the two concept files, the code root's files, `design/gdd/`).

The helper does not report rigor, automation or the goal. Read `project.yaml`, if it exists, and note whether `modes.rigor`, `modes.automation` and `project.goal` are set: a set value is kept, and it is neither guessed nor asked again (Phases 4 and 5).

**Returning user** (an engine is set and `concept` is present): ask nothing. Say the engine, the concept or brief found, and the review mode: `modes.review_mode` if set, otherwise the one `modes.rigor` implies (`minimal` → `solo`, `standard` → `lean`, `full` → `full`). Suggest `/next-step` for the next step, add the template-remote note if it applies, and stop.

Phase 2: Ask where the user is

Ask with the question tool: "Welcome! Where are you starting from with your game?" Options:

• `A) Make me a game (playable in your browser)`: a browser game built from a few quick answers, any

of which can be "you pick".

• `B) An idea, or none yet`: nothing yet, or a theme, feeling or genre ("something with space",

"a cozy farming game").

• `C) Clear concept`: the core idea and genre are known, nothing is written down yet.
• `D) Existing work`: design documents, prototypes, code or plans already exist.

With `engine.name` set to an engine other than `web`, A reads `A) Make me a game`: a throwaway prototype of one mechanic in that engine, with a browser sketch as one option.

Wait for the answer. If it contradicts Phase 1, say what you found once and ask again: D on an empty project ("this looks like a fresh template; would A or B fit better?"), or B with code on disk ("I found code in `[code_root]`; did you mean D?"). D on an empty project with no game found (Phase 3) asks first, in plain t