Aigon supports multiple AI coding agents, with more being added over time. Each gets its own settings, context delivery mechanism, and CLI integration.

Supported agents

Slash-invocable agents (cc, gg, cu) receive aigon prompts through their native slash-command discovery. Non-invocable agents (cx, op, km) launch with the canonical prompt body inlined directly — no slash-command registration is required on those CLIs.

Installing agents

aigon install-agent cc gg          # Install Claude + Gemini
aigon install-agent cx             # Add Codex later

Install only the agents you have access to. You can add more at any time.

What install-agent writes

aigon install-agent writes only aigon-owned files. It never touches user-owned root files like CLAUDE.md.

Per-agent files

Shared Aigon-owned files

User-owned files

AGENTS.md, CLAUDE.md, README.md, and your application source are user-owned. Aigon does not write or modify them. If you want Aigon visible in a root instruction file, add a short pointer manually, for example:

This repo uses Aigon for feature workflow. See `.aigon/docs/development_workflow.md`.

How context reaches each agent

Instead of injecting into user-owned files, Aigon delivers context through each agent’s native extension mechanism:

• Claude Code / Gemini CLI: A SessionStart hook runs aigon project-context, which prints doc pointers to stdout. The agent ingests this as conversation context.
• Cursor: .cursor/rules/aigon.mdc with alwaysApply: true
• Codex: per-skill description: fields under .agents/skills/aigon-*/SKILL.md — Codex selects skills implicitly or via explicit $aigon-feature-do <id> mentions
• OpenCode / Kimi: Aigon resolves the canonical command prompt and passes it directly when launching the agent.

Codex example

Inside a Codex session, use the explicit skill form:

$aigon-feature-create dark-mode
Add a theme toggle to the site header. Default to system preference and persist the user's choice.

After the feature has an ID, continue with:

$aigon-feature-do 07

Use $aigon-next any time you want Codex to suggest the most likely next Aigon command for the current workflow state.

Updating

aigon apply

Re-runs install-agent for all detected agents. Updates command templates, hooks, and Aigon-owned doc files. Never touches CLAUDE.md, AGENTS.md, or README.md.

When new templates are available: SessionStart hooks (cc, gg, cu, codex) print a short notice telling you to run aigon apply. You decide when. See Applying Aigon updates to your repos.

Project-specific instructions

Add shared project rules directly in your root instruction files:

• AGENTS.md — Read by Gemini, Codex, and Cursor
• CLAUDE.md — Claude Code’s native project instructions
• .aigon/docs/agents/{id}.md — Aigon-installed agent-specific operational notes

Permission modes

Default “yolo mode” flags auto-approve commands:

Override with:

aigon config set --global agents.cc.implementFlag ""

Spec complexity and model defaults

When you start a feature or research topic, Aigon can pre-select model and effort for each agent using the spec’s complexity: label plus each agent’s complexity ladder in shipped JSON — then aigon config if the ladder does not define a value. The spec itself does not store model IDs, so ladders can be updated when providers rename SKUs.

What lives in the spec

New feature and research specs include YAML frontmatter (see templates/specs/ in the repo). The only recommendation field is:

• complexity — one of low, medium, high, very-high. Describes how demanding the work is so Aigon can pick a tier.

If complexity is missing or invalid, Aigon falls back to normal config defaults; nothing breaks.

Where per-agent defaults come from

Each bundled agent definition (templates/agents/<id>.json in the repo) includes cli.complexityDefaults: a table from each complexity bucket to a default model and effort for that agent. Those tables are the “ladder” for that provider and are the right place to change which SKU maps to which tier.

Resolution order (per agent, per field)

For each of model and effort, Aigon resolves:

1. Value from complexityDefaults[complexity] for that agent (when the spec has a valid complexity).
2. Else aigon config models and related config (see Configuration).

Per-run CLI flags (--models, --efforts) and dashboard overrides still win over these defaults for that launch.

Dashboard behaviour

On Start (and similar flows), the agent picker shows:

• A short note with the spec’s complexity (when present) and plain-language text that model/effort defaults follow each agent’s ladder for that tier.
• Model override and Effort override dropdowns, pre-filled from the resolved recommendation. Default in the dropdown means “use the global aigon config value for this task.”

You can always change a row before confirming; the choice is stored on the workflow snapshot for respawns.

CLI and API

• CLI: aigon feature-start <id> … supports per-run overrides, e.g. --models=cc=claude-opus-4-7,gg=gemini-2.5-pro and --efforts=cc=high. See the feature-start reference.
• API: GET /api/recommendation/feature/<id> and GET /api/recommendation/research/<id> return the resolved recommendation payload (optional repoPath query when needed). Integrations and the dashboard use this for the same pre-selection logic.

Authoring guidance

Set complexity when you write or review a spec (the feature-create flow and templates describe the rubric). Do not add per-agent model lines to the spec; use aigon config or adjust cli.complexityDefaults in the agent template if you need different defaults for all specs at a tier.

Using agents in Fleet mode

In Fleet mode, each agent gets an isolated worktree. Mismatch protection prevents launching the wrong agent in a worktree:

feature-108-cc-dark-mode/  → only cc can run here
feature-108-gg-dark-mode/  → only gg can run here
feature-108-cx-dark-mode/  → only cx can run here

Terminal integration

How agents launch depends on your terminal config:

Configure with:

aigon config set --global terminalApp iterm2