### Start
Works with
description: "First-time onboarding — asks where you are, then guides you to the right workflow. No assumptions."
argument-hint: "[no arguments]"
allowed-tools: Read, Glob, Grep, Write, AskUserQuestion
AI-first code editor with Composer
Before installing skills in Cursor, ensure your development environment meets these requirements:
node --versionstartExecute the skills CLI command in your project's root directory to begin installation:
Fetches start from Donchitos/Claude-Code-Game-Studios and configures it for Cursor.
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
Confirm successful installation by checking the skill directory location:
Restart Cursor to activate start. Access via /start in your agent's command palette.
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Submit your Claude Code skill and start earning
Automate repetitive workflows and reduce manual effort
Example
Generate reports, summarize documents, draft communications
Save 3-5 hours per week on routine tasks
Learn new skills, understand complex topics, get expert guidance
Example
Explain concepts, provide examples, suggest learning resources
Accelerate learning and skill development by 2x
Enhance output quality through reviews, suggestions, and refinements
Example
Review drafts, suggest improvements, catch errors
Improve work quality by 30-40% with less effort
0
total installs
0
this week
10.7K
GitHub stars
0
upvotes
Run in your terminal
0
installs
0
this week
10.7K
stars
| 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, Write, AskUserQuestion |
This skill writes one file: production/review-mode.txt (review mode config set in Phase 3b).
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:
.claude/docs/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 AskUserQuestion 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.Wait for the user's selection. Do not proceed until they respond.
The user needs creative exploration before anything else.
/brainstorm does (guided ideation using professional frameworks — MDA, player psychology, verb-first design). Mention that it has two modes: /brainstorm open for fully open exploration, or /brainstorm [hint] if they have even a vague theme (e.g., "space", "cozy", "horror")./brainstorm open as the next step, but invite them to use a hint if something comes to mind/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/brainstorm [their hint] to develop it/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-storyAskUserQuestion to offer two paths:
Formalize it first — Run /brainstorm [concept] to structure it into a proper game concept documentJump straight in — Go to /setup-engine now and write the GDD manually afterward/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 phaseCheck 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 AskUserQuestion:
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 AskUserQuestion 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."Prerequisites
Time Estimate
15-45 minutes depending on use case complexity
Steps
Common Pitfalls
✓ Do
✗ Don't
💡 Pro Tips
✓ Use when
Use when skill capabilities match your task, clear ROI on time saved, and you can validate outputs. Best for repetitive tasks, learning, and quality improvement.
✗ Avoid when
Avoid when task requires deep expertise you can't validate, involves sensitive decisions, or when learning process is more valuable than speed of completion.
JuliusBrussee/caveman
JuliusBrussee/caveman
whyashthakker/agent-skills-marketing
JuliusBrussee/caveman
whyashthakker/agent-skills-marketing
vercel-labs/skills
start fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
Useful defaults in start — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
start has been reliable in day-to-day use. Documentation quality is above average for community skills.
start has been reliable in day-to-day use. Documentation quality is above average for community skills.
start is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
start fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
Solid pick for teams standardizing on skills: start is focused, and the summary matches what you get after install.
Keeps context tight: start is the kind of skill you can hand to a new teammate without a long onboarding doc.
We added start from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
I recommend start for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
showing 1-10 of 65