FAQ

Whichever you already use. The tables under Install show what each one gets: hooks only in Claude Code and Codex, helpers everywhere except Pi without pi-subagents, and manual-only skills kept out of the model’s list everywhere except Amp and Hermes. Every pipeline is written to run in all eight tools, and Tested in each tool shows where the smoke test confirmed it. The support note under docs/hosts/ for yours says what is different there and how it did in the smoke test.

Yes. Hooks exist only for Claude Code (hooks/claude-code.json, 10 handlers) and Codex (hooks/codex.json, 5; Codex runs them after you trust them in /hooks). The other six tools lose only what the hooks add: the session-start pointer to docs/context/STATUS.md, the injection scanners on reads and writes, the context monitor, the commit-message check, the fetch cache, the ship-pipeline Stop guard and the Agent Teams gates. No pipeline depends on any of them, and the ship runner drives an unattended run through state.json in every tool.

Yes. The blueprint installs in your tool and adds no engine files to your project. Install it, then run the ab-project-start skill in the project (how to call it in each tool): it adds AGENTS.md and docs/ by merging into what exists, and never overwrites your code or instructions. In a folder with files that is not a git repository, it shows what it would write and asks first. Inside a repository it runs no second git init, names the repository’s top folder and commits nothing, so you review the changes before you commit them.

It creates AGENTS.md, a one-line CLAUDE.md that imports it, docs/context/ with CONVENTIONS.md, GOALS.md, STATUS.md and DECISIONS.md, a BACKLOG.md, and .gitignore lines for its working files. It merges into what is there and never overwrites it, then fills in the commands, goals and status from your code and a few questions. Run it first thing in a new project, or when you bring the blueprint into one that exists. Call it with /ab-project-start in Claude Code, Antigravity, Grok Build, Cursor CLI and Hermes, $ab-project-start in Codex and /skill:ab-project-start in Pi, or ask Amp to “use the ab-project-start skill”. Codex offers it right after you install the plugin.

No. A skill runs when a request matches its description or when you name it. If you never do test-driven development, ab-test-driven-development never runs. You can also delete any skill folder you don’t want, as long as no pipeline or other skill you keep runs it.

Skills are instructions for the main session: they guide the work during your conversation. Helper prompts are files a skill hands to a helper for focused analysis (a security audit, a plan check, a deep code review) that works better in a fresh context. Where the tool has subagents the helper runs in its own context; where it does not, the session follows the prompt itself. Both return the prompt’s Output section.

AGENTS.md adds a small amount of context. Skills load when they run, not up front, and each SKILL.md stays under 8,000 bytes with its detail in references/, read at the point of use. A full pipeline does take longer than a single prompt, because it plans, reviews and verifies: see the evaluation under Tested in each tool.

Yes. The plugin works the same in the Claude Code CLI and in its VS Code and JetBrains extensions.

Each tool updates through its own route, and Update gives the command for each. In any tool, the ab-plugin-update skill finds the route you used, runs it and checks the version. Your project files (AGENTS.md, docs/, BACKLOG.md) are never touched.

Run the installer once more, without --only: git pull and bash install.sh in the clone you have, or clone it again with the command under Set up every tool at once. It installs each tool by its own route, then removes the copies 4.0 recorded in ~/.agents/skills, ~/.grok/skills and ~/.pi/agent/skills, touching only the skills it recorded. If one tool’s install fails, the others still install, the installer names the one that failed, and the copies that install would replace stay until a later run succeeds. A run with --only retires an old copy only for the tools in that run, and keeps the shared copy, with a warning, while a tool outside the run still reads it. If you install with a tool’s own command instead and keep the old copy, that tool lists every skill twice.

Follow Upgrade from v3: install v4, run ab-migrate in each project, remove the v3 plugin, refresh the project files with ab-project-start. The name map and the folder changes are in docs/upgrade/v4.md.

The scaffold includes example files in docs/decisions/, docs/plans/, docs/specs/ and docs/research/ that show the expected format for each kind of document. They are marked as examples. Delete them when you start your own project.

No. ab-quick-fix covers small, well-understood changes (under three files, obvious approach): write a failing test, fix it, verify, commit. The scaffolded AGENTS.md states the boundary.

A swarm runs several helpers in parallel on the same input. ab-review-swarm reviews a change from several angles and merges the findings; ab-deep-research runs five researchers before planning. Use swarms for significant changes: they cost more tokens and catch what a single reviewer misses. For a small change, a single ab-requesting-code-review is usually enough.

Swarms are read-only helpers that analyze the same input and report to a synthesizer. Team work (ab-orchestrate) implements a plan: the lead keeps a task ledger, runs tasks in dependency-ordered waves with each helper owning its files, and commits each finished task itself. It runs in every tool, one task after another where the tool has no helpers, and uses Claude Code Agent Teams or Codex multi_agent_v2 when you have switched them on.

The runner uses the least-privileged headless posture each tool offers, scans every outgoing commit and the pull request body for secrets before it pushes, pushes only to the remote and branch it recorded at preflight, and stops as needs-human if the git configuration or the push target changed during the run or the commits to publish touch CI configuration. Pi, Amp and Antigravity can only run unguarded, so they need --allow-unguarded, and there the agent holds your git and gh credentials. Amp’s headless threads are visible to your workspace by default, according to its docs.

Edit blueprint.local.md (gitignored, so each developer can choose). It lists which review and research helpers ab-review-swarm and ab-deep-research start. Comment out the ones that don’t apply to your stack; a frontend reviewer has nothing to do on a CLI tool.