feat: add native support for Antigravity CLI (agy)

README.md

@@ -62,6 +62,20 @@ Copy any `SKILL.md` into `.cursor/rules/`, or reference the full `skills/` direc
 
 </details>
 
+<details>
+<summary><b>Antigravity CLI (Recommended)</b></summary>
+
+Install as a native plugin for skills, subagents, and slash commands. See [docs/antigravity-setup.md](docs/antigravity-setup.md).
+
+**Install from a local clone:**
+
+```bash
+git clone https://github.com/addyosmani/agent-skills.git
+agy plugin install ./agent-skills
+```
+
+</details>
+
 <details>
 <summary><b>Gemini CLI</b></summary>
 
@@ -273,6 +287,8 @@ agent-skills/
 ├── hooks/                             # Session lifecycle hooks
 ├── .claude/commands/                  # 7 slash commands (Claude Code)
 ├── .gemini/commands/                  # 7 slash commands (Gemini CLI)
+├── commands/                          # 7 slash commands (Antigravity CLI)
+├── plugin.json                        # Antigravity plugin manifest
 └── docs/                              # Setup guides per tool
 ```
 

commands/build.toml

@@ -0,0 +1,43 @@
+description = "Implement tasks incrementally — build, test, verify, commit. Add \"auto\" to run the whole plan in one approved pass."
+
+prompt = """
+Invoke the incremental-implementation skill alongside test-driven-development.
+
+## Modes
+
+- `/build` — implement the next pending task, then stop (careful, one slice at a time).
+- `/build auto` — generate the plan if needed, get a single approval, then implement every task without stopping between them.
+
+The arguments select the mode. Treat `auto` (canonical) or `all` as autonomous mode; anything else (or empty) is the default single-task mode. Note: autonomous mode is not faster per task — it runs the same test-driven loop — it only removes the human stepping between tasks.
+
+## Default: one task
+
+Pick the next pending task from the plan. Then:
+
+1. Read the task's acceptance criteria
+2. Load relevant context (existing code, patterns, types)
+3. Write a failing test for the expected behavior (RED)
+4. Implement the minimum code to pass the test (GREEN)
+5. Run the full test suite to check for regressions
+6. Run the build to verify compilation
+7. Commit with a descriptive message
+8. Mark the task complete and stop
+
+## Autonomous: the whole plan (`/build auto`)
+
+Use this once a spec exists and you want to collapse plan + build into one run. It removes the manual stepping between tasks — not the verification. Every task still earns a passing test and its own commit.
+
+1. Require a spec. Look only for a spec at a known path: SPEC.md at the repo root, docs/SPEC.md, or a file under spec/. A README or arbitrary doc does NOT count. If none exists, stop and tell the user to run /spec first — do not invent requirements.
+2. Establish a clean baseline. Run `git status --porcelain`. If there are uncommitted changes outside the expected planning artifacts (SPEC.md, docs/SPEC.md, spec/*, tasks/plan.md, tasks/todo.md), stop and ask the user to commit, stash, or confirm how to handle them. Autonomous per-task commits must not absorb unrelated local work, or the clean-rollback guarantee breaks.
+3. Plan if needed. If there is no tasks/plan.md, invoke the planning-and-task-breakdown skill to generate one.
+4. Single checkpoint. Present the full plan and wait for an unambiguous affirmative (e.g. "approve", "go", "yes"). Treat hedged responses ("looks reasonable", "I guess") as NOT approved. This is the only human gate — after approval, run autonomously. If you generated tasks/plan.md, commit it as a single preparatory commit now so it doesn't bleed into the first task's commit.
+5. Execute every task in dependency order. Use each task's declared dependencies; if they aren't explicit, execute in the order the plan lists them. For each task, run the full default loop above (RED → GREEN → regression → build → commit → mark complete). Stage only the files that task touched plus its task-status update — never `git add -A` blindly — and make one commit per task so any point is a clean rollback.
+6. Stop and ask the user (do not push through) when:
+   - a test can't be made to pass or the build breaks without an obvious fix → follow the debugging-and-error-recovery skill
+   - the spec is ambiguous, or a task needs a decision the spec doesn't cover
+   - a task is high-risk or irreversible — auth/permission changes, destructive data migrations, payments, deletions, deploys, anything touching secrets, or anything you can't undo with `git revert` → follow the doubt-driven-development skill and get explicit sign-off before continuing
+   After the user resolves a blocker, they re-invoke /build auto — it resumes from the next pending task.
+7. Summarize at the end: tasks completed, tests added, commits made, and anything skipped, flagged, or left for the user.
+
+If any step fails, follow the debugging-and-error-recovery skill.
+"""

commands/code-simplify.toml

@@ -0,0 +1,22 @@
+description = "Simplify code for clarity and maintainability — reduce complexity without changing behavior"
+
+prompt = """
+Invoke the code-simplification skill.
+
+Simplify recently changed code (or the specified scope) while preserving exact behavior:
+
+1. Read GEMINI.md and study project conventions
+2. Identify the target code — recent changes unless a broader scope is specified
+3. Understand the code's purpose, callers, edge cases, and test coverage before touching it
+4. Scan for simplification opportunities:
+   - Deep nesting → guard clauses or extracted helpers
+   - Long functions → split by responsibility
+   - Nested ternaries → if/else or switch
+   - Generic names → descriptive names
+   - Duplicated logic → shared functions
+   - Dead code → remove after confirming
+5. Apply each simplification incrementally — run tests after each change
+6. Verify all tests pass, the build succeeds, and the diff is clean
+
+If tests fail after a simplification, revert that change and reconsider. Use `code-review-and-quality` to review the result.
+"""

commands/planning.toml

@@ -0,0 +1,16 @@
+description = "Break work into small verifiable tasks with acceptance criteria and dependency ordering"
+
+prompt = """
+Invoke the planning-and-task-breakdown skill.
+
+Read the existing spec (SPEC.md or equivalent) and the relevant codebase sections. Then:
+
+1. Enter plan mode — read only, no code changes
+2. Identify the dependency graph between components
+3. Slice work vertically (one complete path per task, not horizontal layers)
+4. Write tasks with acceptance criteria and verification steps
+5. Add checkpoints between phases
+6. Present the plan for human review
+
+Save the plan to tasks/plan.md and task list to tasks/todo.md.
+"""

commands/review.toml

@@ -0,0 +1,16 @@
+description = "Conduct a five-axis code review — correctness, readability, architecture, security, performance"
+
+prompt = """
+Invoke the code-review-and-quality skill.
+
+Review the current changes (staged or recent commits) across all five axes:
+
+1. **Correctness** — Does it match the spec? Edge cases handled? Tests adequate?
+2. **Readability** — Clear names? Straightforward logic? Well-organized?
+3. **Architecture** — Follows existing patterns? Clean boundaries? Right abstraction level?
+4. **Security** — Input validated? Secrets safe? Auth checked? (Use security-and-hardening skill)
+5. **Performance** — No N+1 queries? No unbounded ops? (Use performance-optimization skill)
+
+Categorize findings as Critical, Important, or Suggestion.
+Output a structured review with specific file:line references and fix recommendations.
+"""

commands/ship.toml

@@ -0,0 +1,72 @@
+description = "Run the pre-launch checklist via parallel fan-out to specialist personas, then synthesize a go/no-go decision"
+
+prompt = """
+Invoke the shipping-and-launch skill.
+
+`/ship` is a **fan-out orchestrator**. It runs three specialist personas in parallel against the current change, then merges their reports into a single go/no-go decision with a rollback plan. The personas operate independently — no shared state, no ordering — which is what makes parallel execution safe and useful here.
+
+## Phase A — Parallel fan-out
+
+Spawn three subagents concurrently. Gemini CLI exposes each custom subagent in `.gemini/agents/` as a tool with the same name — so `code-reviewer.md` becomes a `code-reviewer` tool the main agent can call, and `@code-reviewer` works as an explicit invocation in the prompt. **Issue all three subagent tool calls in a single assistant turn so they execute in parallel** — sequential calls defeat the purpose of this command.
+
+Dispatch each persona by tool name:
+
+1. **`code-reviewer`** — Run a five-axis review (correctness, readability, architecture, security, performance) on the staged changes or recent commits. Output the standard review template.
+2. **`security-auditor`** — Run a vulnerability and threat-model pass. Check OWASP Top 10, secrets handling, auth/authz, dependency CVEs. Output the standard audit report.
+3. **`test-engineer`** — Analyze test coverage for the change. Identify gaps in happy path, edge cases, error paths, and concurrency scenarios. Output the standard coverage analysis.
+
+If subagents are unavailable in the current Gemini CLI version, invoke each persona's system prompt sequentially in the main context and treat their outputs as if returned in parallel — the merge phase still works.
+
+Constraints (from Gemini CLI's subagent model):
+- Subagents run in isolated context loops and return only their report to this main session.
+- Do not let one persona delegate to another — keep the fan-out flat.
+- For richer multi-agent collaboration where teammates talk to each other instead of just reporting back, see `references/orchestration-patterns.md`.
+
+**Persona resolution.** If you've defined your own `code-reviewer`, `security-auditor`, or `test-engineer` in `.gemini/agents/` or `~/.gemini/agents/`, those take precedence over this plugin's versions — `/ship` picks up your customizations automatically. This is intentional: plugin subagents sit at the bottom of Gemini CLI's scope priority table, so user-level definitions win by design.
+
+## Phase B — Merge in main context
+
+Once all three reports are back, the main agent (not a sub-persona) synthesizes them:
+
+1. **Code Quality** — Aggregate Critical/Important findings from `code-reviewer` and any failing tests, lint, or build output. Resolve duplicates between reviewers.
+2. **Security** — Promote any Critical/High `security-auditor` findings to launch blockers. Cross-reference with `code-reviewer`'s security axis.
+3. **Performance** — Pull from `code-reviewer`'s performance axis; cross-check Core Web Vitals if applicable.
+4. **Accessibility** — Verify keyboard nav, screen reader support, contrast (not covered by the three personas — handle directly here, or invoke the accessibility checklist).
+5. **Infrastructure** — Env vars, migrations, monitoring, feature flags. Verify directly.
+6. **Documentation** — README, ADRs, changelog. Verify directly.
+
+## Phase C — Decision and rollback
+
+Produce a single output:
+
+```markdown
+## Ship Decision: GO | NO-GO
+
+### Blockers (must fix before ship)
+- [Source persona: Critical finding + file:line]
+
+### Recommended fixes (should fix before ship)
+- [Source persona: Important finding + file:line]
+
+### Acknowledged risks (shipping anyway)
+- [Risk + mitigation]
+
+### Rollback plan
+- Trigger conditions: [what signals would prompt rollback]
+- Rollback procedure: [exact steps]
+- Recovery time objective: [target]
+
+### Specialist reports (full)
+- [code-reviewer report]
+- [security-auditor report]
+- [test-engineer report]
+```
+
+## Rules
+
+1. The three Phase A personas run in parallel — never sequentially.
+2. Personas do not call each other. The main agent merges in Phase B.
+3. The rollback plan is mandatory before any GO decision.
+4. If any persona returns a Critical finding, the default verdict is NO-GO unless the user explicitly accepts the risk.
+5. **Skip the fan-out only if all of the following are true:** the change touches 2 files or fewer, the diff is under 50 lines, and it does not touch auth, payments, data access, or config/env. Otherwise, default to fan-out. `/ship` is designed for production-bound changes — when the blast radius is non-trivial, run the parallel review even if the diff looks small.
+"""

commands/spec.toml

@@ -0,0 +1,15 @@
+description = "Start spec-driven development — write a structured specification before writing code"
+
+prompt = """
+Invoke the spec-driven-development skill.
+
+Begin by understanding what the user wants to build. Ask clarifying questions about:
+1. The objective and target users
+2. Core features and acceptance criteria
+3. Tech stack preferences and constraints
+4. Known boundaries (what to always do, ask first about, and never do)
+
+Then generate a structured spec covering all six core areas: objective, commands, project structure, code style, testing strategy, and boundaries.
+
+Save the spec as SPEC.md in the project root and confirm with the user before proceeding.
+"""

commands/test.toml

@@ -0,0 +1,19 @@
+description = "Run TDD workflow — write failing tests, implement, verify. For bugs, use the Prove-It pattern."
+
+prompt = """
+Invoke the test-driven-development skill.
+
+For new features:
+1. Write tests that describe the expected behavior (they should FAIL)
+2. Implement the code to make them pass
+3. Refactor while keeping tests green
+
+For bug fixes (Prove-It pattern):
+1. Write a test that reproduces the bug (must FAIL)
+2. Confirm the test fails
+3. Implement the fix
+4. Confirm the test passes
+5. Run the full test suite for regressions
+
+For browser-related issues, also invoke browser-testing-with-devtools to verify with Chrome DevTools MCP.
+"""

docs/antigravity-setup.md

@@ -0,0 +1,71 @@
+# Using agent-skills with Antigravity CLI (agy)
+
+The `agent-skills` package can be installed as a native plugin in the Antigravity CLI (`agy`), giving the agent access to structured workflows, personas, and custom slash commands.
+
+## Setup
+
+### Option 1: Native Plugin Installation (Recommended)
+
+Antigravity CLI has a first-class plugin system that registers skills, agents, and custom commands.
+
+**Install from a local clone:**
+
+1. Clone the repository:
+   ```bash
+   git clone https://github.com/addyosmani/agent-skills.git
+   ```
+2. Install the plugin using `agy`:
+   ```bash
+   agy plugin install /path/to/agent-skills
+   ```
+
+This will validate the plugin and install it into your global Antigravity configuration directory (`~/.gemini/antigravity-cli/plugins/agent-skills/`).
+
+### Option 2: Import from Gemini CLI
+
+If you have already installed `agent-skills` under your legacy Gemini CLI installation, you can import it directly:
+```bash
+agy plugin import gemini
+```
+
+Once installed, verify the active plugin:
+```bash
+agy plugin list
+```
+
+---
+
+## Slash Commands
+
+The plugin registers 7 custom slash commands that map to the development lifecycle:
+
+| Command | What it does | Activated Skill |
+|---------|--------------|-----------------|
+| `/spec` | Write a structured spec before writing code | `spec-driven-development` |
+| `/planning` | Break work into small, verifiable tasks | `planning-and-task-breakdown` |
+| `/build` | Implement the next task incrementally | `incremental-implementation` |
+| `/test` | Run TDD workflow — red, green, refactor | `test-driven-development` |
+| `/review` | Five-axis code review | `code-review-and-quality` |
+| `/code-simplify` | Reduce complexity without changing behavior | `code-simplification` |
+| `/ship` | Pre-launch checklist via parallel persona fan-out | `shipping-and-launch` |
+
+Each command automatically invokes the corresponding skill and guides the agent step-by-step.
+
+> **Note:** Use `/planning` instead of `/plan` to avoid conflicts with Antigravity's internal plan-generation command.
+
+---
+
+## Skills & Discovery
+
+Antigravity automatically discovers skills inside the plugin's `skills/` directory. 
+* Antigravity matches user tasks and intents to relevant skills on-demand.
+* If a task matches a skill, the agent will load the skill and prompt you for permission before executing.
+
+---
+
+## Verification & Validation
+
+To validate that your local plugin is correctly structured and contains all skills, run:
+```bash
+agy plugin validate /path/to/agent-skills
+```

plugin.json

@@ -0,0 +1,5 @@
+{
+  "name": "agent-skills",
+  "version": "1.0.0",
+  "description": "Production-grade engineering skills for AI coding agents."
+}