Getting Started with Antigravity Cortex
Five minutes from now, you'll run a single command that spins up 10 AI agents—each with a different specialty—to review your pull request in parallel. Security, performance, architecture, accessibility, all happening at once. That's Antigravity Cortex. Let's get you set up.
Installation
Prerequisites
- Antigravity installed and configured
- Git initialized in your project
- Node.js 18+ (for MCP servers)
Step 1: Install Package
Install ag-cortex as a development dependency. This keeps your production build light.
npm install -D ag-cortex
Step 2: Initialize
Run the install command. This creates the .agent directory and installs
agent-browser.
npx ag-cortex install
You're ready. Antigravity will now see these skills and workflows automatically.
Known Issue: MCP Servers
The bundled MCP servers (Playwright for browser automation, Context7 for docs) don't always auto-load. If you need them, there's a manual config step below. Otherwise, ignore this—everything else works fine.
Quick Start
Let's see what this thing can actually do. I'll show you three workflows you'll use constantly:
Run a Code Review
This is the big one. Type /review and watch it spawn 10+ specialized reviewers:
# Review a PR by number
/review 123
# Review the current branch
/review
# Review a specific branch
/review feature/my-feature
Use a Specialized Agent
The kieran-rails-reviewer enforces Rails conventions. You call them directly, for example:
skill: security-sentinel.
# Rails code review with Kieran's conventions
skill: kieran-rails-reviewer "Review the UserController"
# Get a security audit
skill: security-sentinel "Audit authentication flow"
# Research best practices
skill: best-practices-researcher "Find pagination patterns for Rails"
Invoke a Skill
Skills are like loading a reference book into the agent's brain. When you need deep knowledge in a specific domain:
# Generate images with Gemini
skill: gemini-imagegen
# Write Ruby in DHH's style
skill: dhh-ruby-style
# Create a new Agent skill
skill: create-agent-skills
Configuration
MCP Server Configuration
If the MCP servers didn't load automatically, add this to your global config:
{
"mcpServers": {
"playwright": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@playwright/mcp@latest"],
"env": {}
},
"context7": {
"type": "http",
"url": "https://mcp.context7.com/mcp"
}
}
}
Environment Variables
Right now, only one skill needs an API key. If you use Gemini's image generation:
| Variable | Required For | Description |
|---|---|---|
GEMINI_API_KEY |
gemini-imagegen | Google Gemini API key for image generation |
The Antigravity Philosophy
Every unit of engineering work should make subsequent units of work easier—not harder.
Here's how it works in practice—the four-step loop you'll run over and over:
1. Plan
Before you write a single line, figure out what you're building and why. Use research agents to gather examples, patterns, and context. Think of it as Google Search meets expert consultation.
2. Delegate
Now build it—with help. Each agent specializes in something (Rails, security, design). You stay in the driver's seat, but you've got a team of specialists riding shotgun.
3. Assess
Before you ship, run the gauntlet. Security agent checks for vulnerabilities. Performance agent flags N+1 queries. Architecture agent questions your design choices. All at once, all in parallel.
4. Codify
You just solved a problem. Write it down. Next time you (or your teammate) face this, you'll have a runbook. That's the "compounding" part—each solution makes the next one faster.
Using Agents
Think of agents as coworkers with different job titles. You wouldn't ask your security engineer to design your UI, right? Same concept here—each agent has a specialty, and you call the one you need.
Invoking Agents
# Basic syntax
skill: [skill-name]
# Examples
skill: kieran-rails-reviewer
skill: security-sentinel "Audit the payment flow"
skill: git-history-analyzer "Show changes to user model"
Agent Categories
| Category | Count | Purpose |
|---|---|---|
| Review | 10 | Code review, security audits, performance analysis |
| Research | four | Best practices, documentation, git history |
| Design | three | UI iteration, Figma sync, design review |
| Workflow | five | Bug reproduction, PR resolution, linting |
| Docs | one | README generation |
Using Commands
Commands are macros that run entire workflows for you. One command can spin up a dozen agents, coordinate their work, collect results, and hand you a summary. It's automation all the way down.
Running Commands
# Workflow commands
/plan
/review 123
/work
/compound
# Utility commands
/changelog
/triage
/reproduce-bug
The Review Workflow
Let me show you what happens when you run /review. Here's the sequence:
- Detection - Figures out what you want reviewed (PR number, branch name, or current changes)
- Isolation - Spins up a git worktree so the review doesn't mess with your working directory
- Parallel execution - Launches 10+ agents simultaneously (security, performance, architecture, accessibility...)
- Synthesis - Sorts findings by severity (P1 = blocks merge, P2 = should fix, P3 = nice-to-have)
- Persistence - Creates todo files so you don't lose track of issues
- Summary - Hands you a readable report with action items
Using Skills
Here's the difference: agents are who does the work, skills are what they know. When you invoke a skill, you're loading a reference library into the agent's context—patterns, templates, examples, workflows. It's like handing the agent a technical manual.
Invoking Skills
# In your prompt, reference the skill
skill: gemini-imagegen
# Or ask the agent to use it
"Use the dhh-ruby-style skill to refactor this code"
Skill Structure
Peek inside a skill directory and you'll usually find:
- SKILL.md - The main instructions (what the agent reads first)
- references/ - Deep dives on concepts and patterns
- templates/ - Copy-paste code snippets
- workflows/ - Step-by-step "how to" guides
- scripts/ - Actual executable code (when words aren't enough)
Code Review Workflow Guide
You'll spend most of your time here. This workflow is why the plugin exists—to turn code review from a bottleneck into a superpower.
Basic Review
# Review a PR
/review 123
# Review current branch
/review
Understanding Findings
Every finding gets a priority label. Here's what they mean:
- P1 Critical - Don't merge until this is fixed. Think: SQL injection, data loss, crashes in production.
- P2 Important - Fix before shipping. Performance regressions, N+1 queries, shaky architecture.
- P3 Nice-to-Have - Would be better, but ship without it if you need to. Documentation, minor cleanup, style issues.
Working with Todo Files
After a review, you'll have a todos/ directory full of markdown files. Each one is a single
issue to fix:
# List all pending todos
ls todos/*-pending-*.md
# Triage findings
/triage
# Resolve todos in parallel
/resolve_todo_parallel
Creating Skills
In Antigravity Cortex, both "Agents" (personas) and "Tools" (capabilities) are defined as Skills. This unifies discovery and distribution.
Directory Structure
.agent/skills/
my-skill/
SKILL.md # The brain (required)
scripts/ # Executables
templates/ # Copy-paste assets
workflows/ # Internal procedures
SKILL.md Format
This is what the agent reads to understand how to use the skill.
---
name: my-skill
description: Brief description for the agent router
---
# Skill Title
Instructions on how to perform the skill.
## Examples
...
Fast Track
Run /create-agent-skill to generate a new skill interactively. It handles the boilerplate
for you.
Creating Workflows
Workflows are standard operating procedures (SOPs) that you explicitly trigger. They are perfect for repeatable processes like deployment, syncing, or complex migrations.
Workflow File
Create a markdown file in .agent/workflows/my-workflow.md:
---
description: Summary of what this workflow does
---
# Workflow Title
1. Step one
2. Step two
- Sub-step
3. [CHECK] Verification step
Defining Rules
Rules are the "Constitution" of your agent. They are always loaded into context and define behavior, coding standards, and prohibited actions.
Rule File
Create a markdown file in .agent/rules/99-my-rule.md:
# Engineering Standards
1. Always use TypeScript for new files.
2. No direct database access from views.
3. All PRs must include a screenshot.