Codex and Antigravity Workflow

The aim of this setup is simple: use the strongest agent for repo-wide work, keep the editor fast for interactive changes, and maintain each durable rule in only one place.

Which Tool Does What

Tool	Best use
Codex	Repository-wide implementation, tests, review, refactors, and tasks where correctness matters more than latency
Antigravity CLI	A second agent surface for terminal-based work
Antigravity IDE	Editing, navigation, completions, browser interaction, and visual artifacts close to the code

Codex currently defaults to gpt-5.6-sol with high reasoning effort. That is an intentional correctness-first default; use a faster mode only for work whose cost of error is genuinely low.

Daily Commands

cx                         # start Codex in the current repository
agy                        # keep the original Antigravity CLI
agy-ide                    # open Antigravity IDE in the current directory
agy-ide /path/to/repo      # open an explicit repository
agent-init                 # preview shared agent scaffolding
agent-init --apply         # apply it after reviewing the plan
ws                         # jump to the workspace helper

agy is deliberately left untouched. The separate agy-ide helper avoids an ambiguous alias and makes the target directory explicit.

One Source for Shared Rules

Personal defaults live at:

$HOME/.config/agent-guidance/AGENTS.md

Codex's global AGENTS.md and Antigravity's global GEMINI.md are symbolic links to that file. Editing the canonical file updates both tools immediately. The same pattern is used for the reusable project initializer:

$HOME/Projects/agent-toolkit
├── linked from $HOME/.codex/skills/agent-toolkit
└── linked from $HOME/.gemini/config/skills/agent-toolkit

Do not copy shared instructions into two configuration trees. Tool-specific behavior stays in its own configuration; genuinely shared behavior belongs in the canonical file.

One Contract per Repository

Run agent-init from a Git repository and inspect the dry-run plan before applying it. The toolkit can add:

• AGENTS.md as the canonical project contract;
• .agents/rules/project-guidance.md as Antigravity's bridge to AGENTS.md;
• arch.md, .editorconfig, and .gitattributes;
• safe ignore rules for agent state, secrets, caches, and generated output;
• optional VS Code-on-WSL zsh settings.

Project-specific commands, architecture boundaries, and completion checks belong in that repository's AGENTS.md. Global guidance should remain short and portable.

Convenience and Safety Boundary

This WSL instance is private, single-user, and intentionally used as root. Routine reversible work inside the requested repository—editing, testing, building, and local Git inspection—can proceed without ceremony.

Explicit confirmation is still required before destructive recursive changes, force pushes, external publication, touching unrelated repositories, exposing secrets or ignored private data, modifying Windows mounts, or changing broad system directories. Convenience is the default inside the active workspace; scope remains the boundary.

Parallel Agent Work

Do not let two agents edit the same checkout at the same time. Give independent tasks separate worktrees and branches:

git worktree add ../project-codex -b agent/codex-task
git worktree add ../project-agy -b agent/agy-task

Review and integrate each branch normally. Worktrees make ownership visible and avoid agents silently overwriting each other's files.

Publishing a Follow-up to This Website

The request “put this on my personal website” invokes one shared website skill, whose canonical source remains inside the website repository. From any working directory, Codex and Antigravity discover that same source through links:

$HOME/my-website/.agents/skills/docusaurus-site-management
├── linked from $HOME/.codex/skills/docusaurus-site-management
└── linked from $HOME/.gemini/config/skills/docusaurus-site-management

The agent should then:

1. open $HOME/my-website and inspect its status and architecture rules;
2. search for an existing note before creating a new one;
3. choose between updating a note, adding a Build Log entry, or creating a focused guide;
4. remove private or machine-specific details and prefer $HOME paths;
5. publish matching Chinese, English, and French bodies;
6. check locale freshness, then scale validation to the change: simple Markdown can stop there, while UI or structural changes receive build and browser checks.

This request authorizes local website edits and validation. Pushing or deploying the site remains a separate explicit action.

Recovery

Configuration snapshots include the canonical shared guidance and a Git bundle of the agent toolkit. They deliberately exclude private keys, shell secret files, and project contents. Restore the canonical source first; recreate links afterward instead of backing up duplicate copies.

For the surrounding environment history, see the Build Log.