菜单
First-time onboarding — asks where you are, then guides you to the right workflow. No assumptions.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Creates an Architecture Decision Record (ADR) documenting a significant technical decision, its context, alternatives considered, and consequences. Every major technical choice should have an ADR.
Audits game assets for compliance with naming conventions, file size budgets, format standards, and pipeline requirements. Identifies orphaned assets, missing references, and standard violations.
Analyzes game balance data files, formulas, and configuration to identify outliers, broken progressions, degenerate strategies, and economy imbalances. Use after modifying any balance-related data or design.
Guided game concept ideation — from zero idea to a structured game concept document. Uses professional studio ideation techniques, player psychology frameworks, and structured creative exploration.
Creates a structured bug report from a description, or analyzes code to identify potential bugs. Ensures every bug report has full reproduction steps, severity assessment, and context.
Auto-generates a changelog from git commits, sprint data, and design documents. Produces both internal and player-facing versions.
| name | start |
| description | First-time onboarding — asks where you are, then guides you to the right workflow. No assumptions. |
| argument-hint | [no arguments] |
| user-invocable | true |
| allowed-tools | Read, Glob, Grep, AskUserQuestion |
Local / OpenAI-compatible clients: read STUDIO.md and skill start-local
for the same routing without Claude Code /slash UI; skill names (setup-web, etc.) are stable command ids.
This skill is the entry point for new users. It does NOT assume you have a game idea, a web framework 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:
.claude/docs/technical-preferences.md. If the
web stack still reads [TO BE CONFIGURED], run setup-web first.design/gdd/game-concept.md.src/web/, src/platforms/, packages/shared/ (*.ts, *.js, etc.).prototypes/.design/gdd/.production/sprints/ or
production/milestones/.Store these findings internally. You will use them to validate the user's self-assessment and to tailor follow-up recommendations.
This is the first thing the user sees. Present these 4 options clearly:
Welcome to the studio (H5 + Mini Games fork)!
Before I suggest anything, I'd like to understand where you're starting from. Where are you at with your game idea right now?
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.
Wait for the user's answer. Do not proceed until they respond.
The user needs creative exploration before anything else. Engine choice, technical setup — all of that comes later.
/brainstorm does (guided ideation using professional
frameworks — MDA, player psychology, verb-first design)/brainstorm open as the next step/brainstorm — discover your game concept/setup-web — pin the TypeScript web stack (and mini game skills when needed)/map-systems — decompose the concept into systems and plan GDD writing order/prototype — test the core mechanic/sprint-plan — plan the first sprintThe user has a seed but needs help growing it into a concept.
/brainstorm [their hint] to develop it/brainstorm [hint] — develop the idea into a full concept/setup-web — configure the web stack/map-systems — decompose the concept into systems and plan GDD writing order/prototype — test the core mechanic/sprint-plan — plan the first sprintThe user knows what they want to make but hasn't documented it.
/brainstorm to structure the concept into a
proper game concept document with pillars, MDA analysis, and scope tiers/setup-web and write the GDD manually afterward/brainstorm or /setup-web (their pick)/design-review — validate the concept doc/map-systems — decompose the concept into individual systems with dependencies and priorities/design-system — author per-system GDDs (guided, section-by-section)/architecture-decision — make first technical decisions/sprint-plan — plan the first sprintThe user has artifacts already. Figure out what exists and what's missing.
/project-stage-detect for a full analysis/setup-web should come first/project-stage-detect — full gap analysis/setup-web — if not configured/design-system — if systems index exists but GDDs are incomplete/gate-check — validate readiness for next phase/sprint-plan — organize the workAfter presenting the recommended path, ask the user which step they'd like to take first. Never auto-run the next skill.
"Would you like to start with [recommended first step], or would you prefer to do something else first?"
When the user chooses their next step, let them invoke the skill themselves
or offer to run it for them. Either way, the /start skill's job is done
once the user has a clear next action.
src/. Did you mean to pick D (existing work)? Or
would you like to start fresh with a new concept?"design/gdd/game-concept.md. Want to pick up where
you left off? Try /sprint-plan or just tell me what you'd like to work on."This skill follows the collaborative design principle: