Menú
First-time onboarding — asks where you are, then guides you to the right workflow or to pre-workflow exploration. No assumptions.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Configure the project's game engine and version. Pins the engine in AGENTS.md, detects knowledge gaps, and populates engine reference docs via webfetch when the version is beyond the LLM's training data.
Run an automated smoke test using the godot-mcp server. Launches the project, captures debug output, and checks for errors or crashes.
Configure the project's game engine and version. Pins the engine in AGENTS.md, detects knowledge gaps, and populates engine reference docs via webfetch when the version is beyond the LLM's training data.
Validate readiness to advance between development phases. Produces a PASS/CONCERNS/FAIL verdict with specific blockers and required artifacts. Use when user says 'are we ready to move to X', 'can we advance to production', 'check if we can start the next phase', 'pass the gate'.
Reviews a game design document for completeness, internal consistency, implementability, and adherence to project design standards. Run this before handing a design document to programmers.
Estimates task effort by analyzing complexity, dependencies, historical velocity, and risk factors. Produces a structured estimate with confidence levels.
| name | start |
| description | First-time onboarding — asks where you are, then guides you to the right workflow or to pre-workflow exploration. No assumptions. |
| argument-hint | [no arguments] |
| user-invocable | true |
| allowed-tools | Read, Glob, Grep, Write, question |
This skill writes up to two files:
production/stage.txt — set to exploration when user picks Path E (pre-workflow exploration).production/review-mode.txt — review mode config (set in Phase 3b, skipped for Path E).This skill is the entry point for new users. It does NOT assume you have a game idea, an engine preference, or any prior experience. It asks first, then routes you to the right workflow.
Before asking anything, silently gather context so you can tailor your guidance. Do NOT show these results unprompted — they inform your recommendations, not the conversation opener.
Check:
docs/framework/technical-preferences.md. If the Engine field contains [TO BE CONFIGURED], the engine is not set.design/gdd/game-concept.md.src/ (*.gd, *.cs, *.cpp, *.h, *.rs, *.py, *.js, *.ts).prototypes/.design/gdd/.production/sprints/ or production/milestones/.Store these findings internally to validate the user's self-assessment and tailor recommendations.
This is the first thing the user sees. Use question with these exact options so the user can click rather than type:
A) No idea yet — I don't have a game concept at all. I want to explore and figure out what to make.B) Vague idea — I have a rough theme, feeling, or genre in mind (e.g., "something with space" or "a cozy farming game") but nothing concrete.C) Clear concept — I know the core idea — genre, basic mechanics, maybe a pitch sentence — but haven't formalized it into documents yet.D) Existing work — I already have design docs, prototypes, code, or significant planning done. I want to organize or continue the work.E) Multiple ideas — I have 2-4 rough game ideas and want to prototype them quickly before committing to a specific workflow.Wait for the user's selection. Do not proceed until they respond.
The user needs creative exploration before anything else.
/concept-brainstorm does (guided ideation using professional frameworks — MDA, player psychology, verb-first design). Mention that it has two modes: /concept-brainstorm open for fully open exploration, or /concept-brainstorm [hint] if they have even a vague theme (e.g., "space", "cozy", "horror")./concept-brainstorm open as the next step, but invite them to use a hint if something comes to mind/concept-brainstorm open — discover your game concept/setup-engine — configure the engine (brainstorm will recommend one)/art-bible — define visual identity (uses the Visual Identity Anchor brainstorm produces)/map-systems — decompose the concept into systems/design-system — author a GDD for each MVP system/review-all-gdds — cross-system consistency check/gate-check — validate readiness before architecture work
Architecture phase:/create-architecture — produce the master architecture blueprint and Required ADR list/architecture-decision (×N) — record key technical decisions, following the Required ADR list/create-control-manifest — compile decisions into an actionable rules sheet/architecture-review — validate architecture coverage
Pre-Production phase:/ux-design — author UX specs for key screens (main menu, HUD, core interactions)/prototype — build a throwaway prototype to validate the core mechanic/playtest-report (×1+) — document each vertical slice playtest session/create-epics — map systems to epics/create-stories — break epics into implementable stories/sprint-plan — plan the first sprint
Production phase: → pick up stories with /dev-story/concept-brainstorm [their hint] to develop it/concept-brainstorm [hint] — develop the idea into a full concept/setup-engine — configure the engine/art-bible — define visual identity (uses the Visual Identity Anchor brainstorm produces)/map-systems — decompose the concept into systems/design-system — author a GDD for each MVP system/review-all-gdds — cross-system consistency check/gate-check — validate readiness before architecture work
Architecture phase:/create-architecture — produce the master architecture blueprint and Required ADR list/architecture-decision (×N) — record key technical decisions, following the Required ADR list/create-control-manifest — compile decisions into an actionable rules sheet/architecture-review — validate architecture coverage
Pre-Production phase:/ux-design — author UX specs for key screens (main menu, HUD, core interactions)/prototype — build a throwaway prototype to validate the core mechanic/playtest-report (×1+) — document each vertical slice playtest session/create-epics — map systems to epics/create-stories — break epics into implementable stories/sprint-plan — plan the first sprint
Production phase: → pick up stories with /dev-storyquestion to offer two paths:
Formalize it first — Run /concept-brainstorm [concept] to structure it into a proper game concept documentJump straight in — Go to /setup-engine now and write the GDD manually afterward/concept-brainstorm or /setup-engine — (their pick from step 2)/art-bible — define visual identity (after brainstorm if run, or after concept doc exists)/design-review — validate the concept doc/map-systems — decompose the concept into individual systems/design-system — author a GDD for each MVP system/review-all-gdds — cross-system consistency check/gate-check — validate readiness before architecture work
Architecture phase:/create-architecture — produce the master architecture blueprint and Required ADR list/architecture-decision (×N) — record key technical decisions, following the Required ADR list/create-control-manifest — compile decisions into an actionable rules sheet/architecture-review — validate architecture coverage
Pre-Production phase:/ux-design — author UX specs for key screens (main menu, HUD, core interactions)/prototype — build a throwaway prototype to validate the core mechanic/playtest-report (×1+) — document each vertical slice playtest session/create-epics — map systems to epics/create-stories — break epics into implementable stories/sprint-plan — plan the first sprint
Production phase: → pick up stories with /dev-storyShare what you found in Phase 1:
Sub-case D1 — Early stage (engine not configured or only a game concept exists):
/setup-engine first if engine not configured/project-stage-detect for a gap inventorySub-case D2 — GDDs, ADRs, or stories already exist:
/adopt checks this specifically."/project-stage-detect — understand what phase and what's missing entirely/adopt — audit whether existing artifacts are in the right internal formatShow the recommended path for D2:
/project-stage-detect — phase detection + existence gaps/adopt — format compliance audit + migration plan/setup-engine — if engine not configured/design-system retrofit [path] — fill missing GDD sections/architecture-decision retrofit [path] — add missing ADR sections/architecture-review — bootstrap the TR requirement registry/gate-check — validate readiness for next phaseThe user wants to explore several rough ideas before committing to a workflow.
Acknowledge that prototyping before committing is a good approach
Briefly explain what /explore does (pre-workflow rapid prototyping — build throwaway prototypes in prototypes/explore/, produces lightweight REPORT.md per idea, no workflow commitment, 1-2 days per idea)
Recommend running /explore [idea-name] for their first idea, then more for subsequent ideas
Show the recommended path:
Pre-workflow exploration:
/explore idea-a — build a prototype for the first idea (1-2 days)/explore idea-b — build a prototype for the second idea (1-2 days)/explore idea-c — (optional) build a prototype for the third ideaprototypes/explore/*/REPORT.md/gate-check workflow-selection — compare results and choose Hybrid or Full OCGSDo NOT ask about engine preferences, review modes, or any workflow-specific setup. The user is in pre-workflow exploration.
Write production/stage.txt with value exploration so that /help and other skills know the project is in the exploration phase. Create the production/ directory if it does not exist.
This is the only file Path E writes. No production/review-mode.txt is created.
If the user chose Path E (exploration): Skip this phase entirely. No review mode is needed for pre-workflow exploration. Proceed directly to Phase 4.
For all other paths: Check if production/review-mode.txt already exists.
If it exists: Read it and show the current mode — "Review mode is set to [current]." — then proceed to Phase 4. Do not ask again.
If it does not exist: Use question:
Full — Director specialists review at each key workflow step. Best for teams, learning the workflow, or when you want thorough feedback on every decision.Lean (recommended) — Directors only at phase gate transitions (/gate-check). Skips per-skill reviews. Balanced approach for solo devs and small teams.Solo — No director reviews at all. Maximum speed. Best for game jams, prototypes, or if the reviews feel like overhead.Write the choice to production/review-mode.txt immediately after the user
selects — no separate "May I write?" needed, as the write is a direct
consequence of the selection:
Full → write fullLean (recommended) → write leanSolo → write soloCreate the production/ directory if it does not exist.
After presenting the recommended path, use question to ask the user which step they'd like to take first. Never auto-run the next skill.
Yes, let's start with [recommended first step]I'd like to do something else firstWhen the user confirms their next step, respond with a single short line: "Type [skill command] to begin." Nothing else. Do not re-explain the skill or add encouragement. The /start skill's job is done.
Verdict: COMPLETE — user oriented and handed off to next step.
src/. Did you mean to pick D (existing work)?"design/gdd/game-concept.md. Review mode: [read from production/review-mode.txt, or 'lean (default)' if missing]. Want to pick up where you left off? Try /sprint-plan or just tell me what you'd like to work on."production/stage.txt reads exploration): Skip full onboarding — "It looks like you're exploring game ideas! You have [N] explore prototypes in prototypes/explore/. Want to run /explore [another-idea], or are you ready to run /gate-check workflow-selection to choose a workflow?"production/stage.txt already has a non-exploration value. If so, warn: "It looks like you already have a project in the [phase] phase. Did you mean to continue that work (Path D) instead?"