/gaia-init

name: gaia-init
description: Initializes a new project from the GAIA harness. Renames, strips GAIA branding, configures i18n, installs the React Doctor skill, then continues into /setup-gaia in the same session.
disable-model-invocation: true

Initialize a new project from the GAIA harness. It already ships clean (no example code, no docs site, no auth). This command renames, strips GAIA-specific branding, configures i18n, installs the React Doctor skill first, and then continues straight into /setup-gaia's phases in this same session, which install this machine's other tools and plugins and connect GitHub.

**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.

Contents: Interactive gates: run mode and non-response policy; Step 0: Ensure pnpm is available; Step 1: Install dependencies; Step 2: Gather user input; Step 3: Run the init CLI; Step 4: Locale-specific scaffolding; Step 5: Create CODEOWNERS; Step 6: Verify the build; Step 7: Project settings; Step 8: Refresh the wiki; Step 9: Finalize; Step 10: Continue into /setup-gaia; On failure: resume.

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, no cascade, tone

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."

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 API casing question. Re-ask the next gate normally.

State plainly what you are doing and make no claim about why the user paused or whether they are present: non-response is not absence, and they may be reading, thinking, or opening a docs link.

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 its setup questions and waits for your answer on the consequential ones. > - **Automatic.** GAIA selects the recommended default for every one of its own setup questions, without stopping to ask. It shows you the full list of chosen defaults first, and you can change anything afterward. The GitHub connect question that follows is still asked.

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 0 | | 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 (derived from the title, never asked on its own) | Step 2, Q5 |

**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 API casing to camelCase, you can change it later"), and continue. Do not claim the user is absent.

| Gate | Default on non-response | Where | | -------------- | ----------------------- | ------ | | API casing | `camelCase` | Step 2 | | TanStack Query | `No` | Step 2 |

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)"
f