/gaia-init

name: gaia-init
description: Initialize a new project from the GAIA React template, renames, strips GAIA branding, configures i18n, installs Claude skills/plugins.

Initialize a new project from the GAIA React template. The template already ships clean (no example code, no docs site, no auth). This command renames, strips GAIA-specific branding, configures i18n, installs Claude skills/plugins, and hands you a ready-to-build project.

**Language meta-instruction:** Conduct this entire conversation in the language the user has been typing in. Detect it from prior context, no explicit detection step needed. Do not translate source files, rules, skills, or wiki entries, those stay English regardless. Only translate the prompts you show the user.

Interactive gates: run mode and non-response policy

`/gaia-init` asks the user a series of questions ("gates"). This section governs how **every** gate behaves and overrides any harness default. Read it before the first gate and apply it to each one.

Harness timeout note, override

After a gate sits unanswered for a while, the harness injects a stock note like "the user may be away from keyboard, proceed using your best judgment, you can re-ask later." That note is generic, it does not describe this command, and it keeps firing on gate after gate. **Do not act on it literally.** Inside `/gaia-init` it means only "apply the non-response policy below", never "the user is gone, auto-answer everything."

No cascade

Evaluate each gate independently. A non-response on one gate is **never** evidence the user is away for any other gate. A timeout on the language question tells you nothing about the title, the CODEOWNERS handle, or the CI question. Never carry an "away" inference forward, re-ask the next gate normally.

Tone

Never narrate "since you're away" or otherwise assert the user is absent. Non-response is not proof of absence, the user may be reading, thinking, or opening a docs link. State what you are doing plainly, without diagnosing why the user paused.

Run mode, the first gate

Before Step 0's pnpm check, ask this as the **very first** AskUserQuestion (in the user's language):

> How do you want to handle the setup questions? > > - **Interactive** (Recommended). GAIA asks about language, project name, CODEOWNERS, and CI one at a time and waits for your answer on the consequential ones. > - **Automatic.** GAIA selects the recommended default for every question for you, without stopping to ask. It shows you the full list of chosen defaults first, and you can change anything afterward.

List **Interactive** first (the recommended option) and **Automatic** second. This gate is itself HARD-BLOCK: on non-response, re-ask, never assume a mode.

• **Interactive**: apply the per-tier non-response rules below to every later gate.
• **Automatic**: the user has pre-consented to defaults. First show the Automatic defaults table (see "Automatic defaults, per gate" below), then apply each gate's recommended default and continue without asking. One exception, free-text identity values are still never fabricated: CODEOWNERS gets the loud placeholder, never a guess.

Gate tiers

Every gate is one of two tiers. The tier is fixed here, do not reclassify by judgment.

**HARD-BLOCK** (consequential / irreversible / identity). On non-response in interactive mode: re-ask and wait for an explicit answer. Never apply a default and move on, never guess.

| Gate | Where | |---|---| | Run mode (this section) | before Step 0 | | pnpm upgrade consent | Step 0c | | Primary app language (+ "Other" free-text) | Step 2, Q1 | | Additional languages / i18n teardown, `STRIP_I18N` (+ free-text) | Step 2, Q2 | | CODEOWNERS GitHub handle (HARD-BLOCK only when `gh` can't detect it) | Step 2, Q3 | | Project title | Step 2, Q4 | | kebab-case slug | Step 2, Q5 | | CI intent (Configure-CI decision) | Step 8, Configure CI integrations |

**SAFE-DEFAULT** (reversible, the recommended default is the safe outcome). On non-response in interactive mode: re-ask once; if still no answer, apply the stated default, name it plainly ("Defaulting the maintenance tools to their recommended run mode, you can reconfigure later"), and continue. Do not claim the user is absent.

| Gate | Default on non-response | Where | |---|---|---| | Maintenance-tool run modes | all `ci` (CI enabled) or all `local` (CI declined) | Step 9 |

Free-text identity values are never fabricated

The CODEOWNERS GitHub handle, and any similar free-text identity field, must come from the user. A guessed handle is a silent correctness bug: a wrong owner ships in `.github/CODEOWNERS`. Never write a plausible-looking guess.

**Detecting the handle is not fabricating it.** The GitHub CLI, when installed and authenticated, reports the user's *own* authenticated login. That is the user's real identity, not a guess, so using it never violates this rule. There is one authoritative detection method, used everywhere `/gaia-init` needs the handle:

handle=""
if command -v gh >/dev/null 2>&1; then
  handle="$(gh api user --jq .login 2>/dev/null)"
fi
# $handle is the authenticated login, or empty on any failure

`gh api user` is the most reliable method: a single call both verifies auth and returns the login. Treat detection as **failed** if `gh` is absent, unauthenticated, or the call returns empty. Do **not** fall back to `git config user.name` (a display name, not a handle) or remote-URL parsing (there is no remote at init time). What stays never-fabricated is any handle that is neither user-typed nor gh-detected: never invent a plausible-looking one.

• Interactive: offer the gh-detected handle as the recommended default; the user can override it. HARD-BLOCK applies only when detection failed (no default to fall back to): re-ask, do not reach Step 5 without a real handle.
• Automatic: use the gh-detected handle when available. Only when detection also fails, write a loud placeholder that fa