/game-start

name: "game-start"
description: >
  Invoke when the user wants to start a new game project, set up project scaffolding,
  onboard into an existing codebase, or initialize GameForge session state. Triggers on:
  "start a game", "new game project", "set up project", "project onboarding", "initialize
  project". Do NOT invoke for brainstorming ideas (use game-brainstorm) or prototyping
  mechanics (use game-prototype). Part of the AlterLab GameForge collection.
argument-hint: "[engine: godot|unity|unreal]"
effort: medium
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, AskUserQuestion
version: 1.3.0

AlterLab GameForge -- Project Onboarding Workflow

Every game project has a beginning, but not every beginning looks the same. You might be standing in front of an empty folder with nothing but ambition. You might have a thick design document but zero lines of code. You might be stepping into a codebase someone else started six months ago. This workflow detects where you are and gets you moving without wasting time on steps you have already completed.

The core philosophy: meet the project where it lives. Diagnose the current state, fill in the gaps, point toward the next meaningful action. Hollow Knight started as a game jam sketch. Stardew Valley started as a learning exercise. Undertale started as an EarthBound-inspired demo. None followed a textbook "correct" beginning -- but each had a moment where scattered ambition became structured execution. This workflow is that moment.

Purpose & Triggers

Use this workflow when:

• A developer says "I want to start a new game" or "help me set up my project"
• Someone joins an existing project and needs to get oriented
• A team wants a health check on their current project structure
• A solo dev has scattered files and wants to organize into a production-ready layout
• Anyone asks "where do I even begin?" in a game development context

Problems this solves:

• Analysis paralysis at the start of a new project
• Disorganized file structures that become unmanageable at scale
• Missing documentation that causes confusion later
• Skipped foundational decisions that create technical debt from day one
• New team members spending days figuring out where things live

Critical Rules

1. **Never overwrite existing work.** If the project already has files, structures, or docs, preserve them. Suggest reorganization, never deletion without explicit confirmation.

2. **Detect before prescribing.** Always scan the project state before recommending actions. Do not assume an empty project. Do not assume an existing one is well-organized.

3. **Engine-agnostic until confirmed.** If no engine is detected from project files, ask. Do not guess. The wrong engine assumption wastes enormous time.

4. **Documents are not optional.** Every project needs at minimum: a concept document, a technical architecture note, and a task tracking system. These are not bureaucracy -- they are the memory your future self will desperately need. ConcernedApe kept a running design doc throughout Stardew Valley's development, even as a solo dev. That document prevented drift across four years of work.

5. **Scope honesty from minute one.** If someone describes a 200-hour project and says they have 3 weekends, flag it immediately. Kindly, but immediately. The graveyard of abandoned indie games is filled with projects that were "almost done" for two years.

6. **Reference shared standards.** All structural decisions should align with the conventions documented in `docs/collaboration-protocol.md`. All design terminology should follow `docs/game-design-theory.md`.

Project Detection (Auto-populated)

These values are injected automatically via shell preprocessing before the skill content reaches Claude. They provide real-time project data so state detection starts from facts, not assumptions.

• Engine: !`ls project.godot *.unity *.uproject 2>/dev/null | head -1 || echo "No engine project file detected"`
• Git status: !`git log --oneline -5 2>/dev/null || echo "No git history"`
• Source file count: !`find . -name "*.gd" -o -name "*.cs" -o -name "*.cpp" -o -name "*.h" -o -name "*.rs" -o -name "*.js" 2>/dev/null | wc -l`
• Existing docs: !`ls -1 docs/ 2>/dev/null || echo "No docs directory"`
• Design directory: !`ls -1 design/ 2>/dev/null || echo "No design directory"`
• Test directory: !`ls -1 tests/ 2>/dev/null || echo "No tests directory"`
• Build config: !`ls Makefile CMakeLists.txt SConstruct *.sln package.json Cargo.toml 2>/dev/null | head -3 || echo "No build config detected"`
• Project age: !`git log --reverse --format="%ar" 2>/dev/null | head -1 || echo "Unknown — no git history"`
• Active contributors: !`git shortlog -sn --no-merges 2>/dev/null | head -5 || echo "Unknown — no git history"`
• TODO/FIXME count: !`grep -r "TODO\|FIXME\|HACK\|XXX" src/ 2>/dev/null | wc -l || echo "0"`

Use this auto-populated data to shortcut Step 0 below. If the engine field shows a detected project file, skip the engine detection prompts. If source file count is zero, you are in State 1 (Empty Project). If source file count is nonzero but docs directory is empty, the project likely has documentation gaps. The git history age and contributor count help distinguish solo dev projects from team projects, which affects recommended workflow complexity.

Workflow

**Step 0: Project State Detection**

Before any recommendations, assess the current state by scanning for these signals. Cross-reference against the auto-populated data above — much of this may already be answered.

STATE DETECTION MATRIX
---------------------------------------------------------------
Signal                          | Indicates
---------------------------------------------------------------
No files / empty directory      | State 1: Empty Project
Design docs but no source code  | State 2: Concept Exists
Source code + design docs       | State 3: In-Progress
Mature codebase + CI + tests    | Sta