Agent Triforge
Install
Docs pages and contents

Getting started

Check each CLI, install Triforge under a Claude Code or Codex lead, add the portable skills to Devin or Pi, then verify and update the install.

Claude Code leads

$ claude plugin marketplace add https://github.com/Ninety2UA/agent-triforge$ claude plugin install agent-triforge@agent-triforge

Add --scope project to the install line to share it with your team.

From nothing to a first sprint in five steps:

  1. Install the core trio (Claude Code, Antigravity agy and Codex) and log in to each. The version floors and READY probes are under Prerequisites.
  2. Install the plugin: claude plugin marketplace add https://github.com/Ninety2UA/agent-triforge, then claude plugin install agent-triforge@agent-triforge (Installation).
  3. Start claude in your project. The first session bootstraps ops/.
  4. Run /at-setup. It checks the core trio, asks which CLI leads the project, lets you keep or change the role assignments in ops/roster.toml, and offers each optional CLI. It also offers to add Triforge's pointer block to the project's root AGENTS.md, and it changes that file or a CLAUDE.md only after you say yes.
  5. Run /at-ship <goal> for an autonomous sprint, or run the phases one at a time (Typical session flow).

To lead from Codex instead, install the plugin with the Codex lines under Installation, add the project trust entry, start codex in the project, and run $agent-triforge:at-setup and then $agent-triforge:at-ship <goal> in a Codex prompt. Setup prints the full-access launch line for a Codex lead, and you type it yourself.

If you are upgrading from 3.x, the slash commands are now at- workflows (/ship is /at-ship); see Upgrading from 3.x.

Typical session flow

In a supervised session you run each phase and check its output before the next:

claude
> /at-plan add user authentication      # Phase 0-1.5: analyze, research, plan, validate
> /at-build                              # Phase 2: wave orchestration
> /at-review                             # Phase 3-4: parallel review + synthesis
> /at-test                               # Phase 5: Codex TDD
> /at-compound JWT session handling      # Document solution for future sprints
> /at-wrap                               # Phase 6: compound knowledge, write STATE.md

In an autonomous run one command runs every phase, in one session:

claude
> /at-ship add user authentication with JWT refresh tokens

To run the sprint from a terminal across fresh sessions, with recovery when a context window fills up, use scripts/coordinate.sh (Unattended runs).

In a Codex prompt the same workflows are $agent-triforge:at-<name>. From a shell, wrap the prompt in single quotes so the shell leaves $agent-triforge:at-ship alone: codex exec '$agent-triforge:at-ship add user authentication'.

Prerequisites

You need the core trio installed and logged in, Python 3, and on macOS GNU coreutils. The commands below are the READY probes at-setup runs for you; run them yourself to check a CLI before you install the plugin. Floors and tested versions are under Compatibility.

Core trio:

# Claude Code ≥ 2.1.277 — the first build that reads a root AGENTS.md (D-037);
# a claude worker, the shipped builder, needs ≥ 2.1.314 (the sandbox isolation fixes);
# 2.1.267 first honored `effort:` frontmatter on pinned-default models and the
# `fable` alias resolves to Fable 5.1 from 2.1.257
claude --version

# Antigravity CLI ≥ 1.1.27 — https://antigravity.google/cli (run `agy` once interactively to log in)
agy --model "Gemini 3.8 Flash (High)" -p "Respond with only: READY"   # pin the model — agy's own default is a (Medium) variant

# Codex CLI ≥ 0.153.0 (gpt-6-astra's minimal client version) — https://github.com/openai/codex
codex exec "Respond with only: READY"

# Python 3 (used by hook handlers for JSON parsing)
python3 --version

# GNU timeout (on macOS: brew install coreutils, which provides gtimeout); without one
# the helper refuses to call an external CLI (rc 96) and session start warns
command -v timeout || command -v gtimeout

Optional tier. You can add these later through at-setup to use them as builders or reviewers; an absent one is skipped cleanly in every roster fallback chain:

# OpenCode ≥ 1.18.20, the V1 line (`npm i -g opencode-ai@1`): the lane refuses V2 (`@opencode/cli`, Homebrew Core), D-049.
# It needs the OpenRouter provider connected (OPENROUTER_API_KEY or `opencode auth login`)
opencode run --format json -m openrouter/z-ai/glm-5.3 "Respond with only: READY"

# Kimi Code ≥ 0.33.0 — OAuth device-code or API key (`kimi login`)
kimi -p "Respond with only: READY"

# Cursor (date-versioned) — pin the suffixed Grok id, never the Auto router (`cursor-agent login`);
# the binary is `cursor-agent` (legacy symlink) or `agent` (primary since 2026.09.10)
cursor-agent -p --trust --model grok-4.7-xhigh "Respond with only: READY"

# Devin CLI ≥ 3000.10.31 (`devin auth login`) — a reviewer and analyst; at-setup asks for your
# consent before enrolling it, and it builds only after a separate opt-in
devin --model swe-1-6-slow --respect-workspace-trust false -p "Respond with only: READY"

# Grok Build ≥ 1.0.34 (builder, reviewer or analyst) — `grok login` (`grok login --device-code` without a browser) or XAI_API_KEY
grok --model grok-4.7 --output-format json -p "Respond with only: READY"

Installation

  1. Check the prerequisites above.

  2. Install the plugin into the CLI that leads.

    Claude Code leads:

    Copy them from the Claude Code leads tab at the top of this page.

    Codex leads. Codex reads the same .claude-plugin/ manifests:

    Copy them from the Codex leads tab at the top of this page.

    Claude Code registers the hooks, the env vars in settings.json and the skills (the 10 portable skills and the 17 lead workflows) on its own. Codex registers the skills and the hooks, and runs the hooks only after you trust them in Codex; at-setup checks that and names the step. Nothing else needs configuring by hand.

  3. Codex leads: trust the project. Since Codex 0.147.0, codex exec reads a project's own .codex/ files (config.toml, hooks.json, .rules) only in a trusted project. Add this entry to ~/.codex/config.toml yourself, with the project's absolute path:

    [projects."/absolute/path/to/your-project"]
    trust_level = "trusted"
    

    at-setup checks for the entry and prints it, with the path filled in, when it is missing. Triforge never writes your user-level config. Codex can: codex exec -s workspace-write, which a Codex builder runs, writes this entry for the repo itself, so after the first Codex builder the project reads as trusted and its .codex/ files apply. Without the entry the root AGENTS.md still loads, but Codex skips the project's .codex/ files; a project you mark untrusted loses the root AGENTS.md as well. templates/.codex/config.toml is the project file that entry unlocks.

  4. Start the lead (claude or codex) in your project. The first session bootstraps the project's ops/ directory (Automatic project bootstrapping).

  5. Run /at-setup ($agent-triforge:at-setup in a Codex prompt). After checking that the core trio is live (it names the fix for any CLI that isn't), it asks which CLI leads the project, Claude Code or Codex. For Codex it shows the project trust entry, the hook trust and the full-access launch line, which you type yourself. Role assignment comes next: keep the shipped defaults (recommended) or change any role's CLI, model and effort. You then enroll each optional CLI with a model you choose, or decline it. Setup lists the instruction files in the project and the directories above it. It offers to add the pointer block from templates/AGENTS.md to the project's root AGENTS.md (Triforge ships no CLAUDE.md), and when a CLAUDE.md would hide AGENTS.md from Claude Code (under the default instructionFiles mode, claude-md-or-agents-md; a user-tier setting changes this), it also offers the @AGENTS.md import line. It changes a file only after you say yes. Before it writes the lead, it lists which providers receive your code. It is idempotent, so you can rerun it any time.

Portable skills in Devin and Pi

Devin CLI and Pi can install the 10 portable skills straight from this repository. They get the skills only: no lead workflow (at-*), hook or agent. One of them, wave-orchestration, calls Triforge's lease helpers, which come only with the Triforge plugin. Without the plugin its wave rules still work as a manual method, but no lease, pinned review or integrity check runs. Installing the skills does not enroll the CLI, because ops/roster.toml assigns roles only to the CLIs in the builder pool.

Harness Install Manifest Invoke
Devin CLI devin plugins install Ninety2UA/agent-triforge#skills (from a clone: devin plugins install --local ./agent-triforge/skills) skills/.devin-plugin/plugin.json, plugin root skills/ /agent-triforge:<name>
Pi pi install git:github.com/Ninety2UA/agent-triforge (-l writes the project's .pi/settings.json instead of ~/.pi/agent/settings.json) package.json, the pi.skills list /skill:<name>

Run devin auth login before any devin plugins command. Install the Devin plugin from #skills, not from the repository root: at the root, Devin falls back to .claude-plugin/plugin.json and also loads the 17 lead workflows, this repository's AGENTS.md as an always-on rule, and the Claude Code hooks.

Verify installation

Start Claude Code in a project. The session-start banner lists the lead workflows, and /at-status prints the sprint report:

claude

# You should see:
# "Multi-agent framework ready."
# "Lead workflows (/at-<name> here, $agent-triforge:at-<name> in a Codex prompt): at-setup at-ship at-plan ..."

/at-status

Under a Codex lead the banner appears once you have trusted the plugin's hooks. $agent-triforge:at-status prints the same report either way, because every at- workflow runs the project bootstrap itself.

Update

Install route How to update
Claude Code plugin claude plugin marketplace update agent-triforge, then claude plugin update agent-triforge. Start a new Claude Code session to load the new version.
Codex plugin codex plugin marketplace upgrade agent-triforge, then codex plugin add agent-triforge@agent-triforge, which installs the version the refreshed marketplace carries. Any change to the plugin's contents, this update included, asks for approval again, and until then a Codex lead runs without the plugin's hooks: review them when Codex asks, or open /hooks. After a fresh install from a Git marketplace Codex asks once more at the next launch, because its first launch reinstalls the plugin, and that changes the contents the approval covers.
# Claude Code leads
claude plugin marketplace update agent-triforge
claude plugin update agent-triforge

# Codex leads
codex plugin marketplace upgrade agent-triforge
codex plugin add agent-triforge@agent-triforge

Each project picks up the new version at its next session: session start refreshes the portable skills in .agents/skills/ when the plugin version changes, and keeps any copy you edited (Portable skills across the eight CLIs). Before you move to a new major version, read its notes in Release history; from 3.x, read Upgrading from 3.x.