/setup-gaia-ci

/setup-gaia-ci connects your GAIA project to GitHub Actions. Run it once after your first git push origin main. The command is idempotent: re-running on a configured repo prints GAIA CI is already configured and exits. Pass --reconfigure to rotate the bot token or re-select which tools run on cron.

What GAIA CI does

GAIA CI installs four maintenance workflows that run on a cron schedule, open labeled PRs, and auto-merge them when CI passes:

Workflow file	Default schedule	What it does
gaia-ci-wiki.yml	Daily	Runs the /gaia wiki chain: sync, consolidate, and lint
gaia-ci-update-deps.yml	Weekly	Runs /update-deps and opens a PR for any updates
gaia-ci-pnpm-audit.yml	Weekly	Runs pnpm audit and opens a security PR for high and critical findings
gaia-ci-stale-branches.yml	Monthly	Deletes branches merged more than 30 days ago

Each workflow is generated from .gaia/automation.json. You can change the mode for any tool (ci / local / off) by running /setup-gaia-ci --reconfigure.

Prerequisites

• /gaia-init has been run.
• Your repo has a remote named origin pointing to GitHub.
• You have pushed at least once: git push origin main.

The flow

1. Remote detection

The command reads origin and confirms it points to github.com. Non-GitHub remotes are not supported in this release.

2. Duplicate tool detection

If Dependabot or Renovate is detected, the command warns that GAIA’s update-deps workflow covers the same package ecosystems (npm, pnpm) and will open duplicate PRs if both run in parallel. You can disable the overlap before continuing or cancel and re-run later. The command does not disable either tool automatically.

3. Enable / defer / opt out

Three options:

• Enable GAIA CI now: continues the flow.
• Not now: records a personal dismissal. Re-run /setup-gaia-ci anytime.
• Don’t ask the team again: repo-admin only. Records a team opt-out in .gaia/automation.json. The command does not auto-commit this change. Review the diff and commit yourself.

4. Branch cleanup option

If delete_branch_on_merge is disabled on the repo and you have admin access, the command offers to enable it. Enabling it makes the stale-branches workflow redundant. The command marks stale_branches.mode = "off" in .gaia/automation.json automatically.

5. Bot token

GAIA CI needs an Anthropic token or key to authenticate the workflow steps that call Claude. The command asks which token type to use:

• CLAUDE_CODE_OAUTH_TOKEN: for Claude Code subscribers.
• ANTHROPIC_API_KEY: for direct Anthropic API customers.

Paste the token when prompted. It is piped directly to gh secret set and never written to any file, never echoed in chat, and never appears in the terminal scrollback. You can add it manually on GitHub instead, if you prefer.

6. Workflow generation

The command generates .github/workflows/gaia-ci-*.yml from .gaia/automation.json, then triggers one workflow_dispatch run on the first generated workflow to confirm it boots correctly.

If the verification run fails, you can retry, abandon (deletes the generated files, leaves setup_complete: false), or commit anyway if you have confirmed the failure is a transient infrastructure issue.

7. Commit and push

On a successful verification run, the command stages the generated workflow files and .gaia/automation.json, commits with a standard message, and pushes.

Reconfiguring

/setup-gaia-ci --reconfigure

--reconfigure skips the idempotent short-circuit and re-runs the flow from Step 3. It lets you re-select which tools run in CI mode and always asks for a fresh token (the existing secret is silently overwritten). setup_complete stays true.

On failure

The underlying CLI subcommands are idempotent. If the run stops mid-way due to a network error, auth failure, or bad config, fix the cause and re-run /setup-gaia-ci. Steps that already completed short-circuit. A fully configured repo is never re-processed unintentionally.