Skip to main content

CLI Reference

The agentxchain CLI is the primary interface for governed multi-agent runs. Every command operates on the repo-local .agentxchain/ directory and respects the constitutional invariants defined by the protocol.

The two commands people confuse

resume vs step

These are not interchangeable. They serve different purposes in the turn lifecycle.

resumestep
PurposeRe-assign a turn that already existsCreate a new turn and execute the full lifecycle
Creates a turn?NoYes
Dispatches?Yes (re-dispatch)Yes (fresh dispatch)
Runs adapter?No — assignment onlyYes — dispatch, wait, collect
When to useA turn was interrupted or you need to re-dispatch without losing historyNormal flow — advance the run by one turn

resume is an assignment-only operation. It re-dispatches the current pending turn to the same or a different adapter. step is the full lifecycle: it creates the turn, dispatches to the adapter, waits for a result, collects and validates the staged output, and records it in history.

Command map

CommandPhaseDescription
initSetupScaffold a governed project with config, state, prompts, and planning docs
statusInspectionPrint current run state: phase, pending turn, blocked status, recent history
resumeTurn lifecycleRe-dispatch an existing pending turn without creating a new one
stepTurn lifecycleCreate a new turn, dispatch to adapter, wait for result, collect and validate
accept-turnTurn lifecycleAccept the staged turn result and commit it to history
reject-turnTurn lifecycleReject the staged turn result with a reason; turn goes back to pending
approve-transitionApprovalApprove a phase transition gate (e.g., planning to implementation)
approve-completionApprovalApprove run completion — the final human gate before a run closes
validateValidationValidate config, state, or full run integrity
verify protocolConformanceRun the shipped protocol conformance fixture suite against a target implementation
migrateMigrationMigrate state and config from an older protocol version
pluginPlugin managementInstall, list, upgrade, or remove hook plugins
dashboardVisualizationLaunch a local read-only web dashboard

Turn lifecycle commands

init

agentxchain init [options]
FlagDefaultDescription
--governedfalseEnable governed mode with gates and constitutional checks
--template <name>pm-dev-qaRole template to scaffold (pm-dev-qa, dev-qa, solo-dev)
-y, --yesfalseAccept all defaults without prompting
--dir <path>.Target directory for scaffold

Creates agentxchain.json, .agentxchain/state.json, role prompts, and planning document stubs. If --governed is set, the scaffold includes the decision ledger, dispatch directories, and gate configuration.

status

agentxchain status [options]
FlagDefaultDescription
--jsonfalseOutput structured JSON instead of human-readable text
--verbosefalseInclude full turn history and decision log

Prints the current run state: active phase, pending turn (if any), blocked status, last accepted turn summary, and recent decision entries. Does not modify state.

resume

agentxchain resume [options]
FlagDefaultDescription
--adapter <name>(from config)Override the adapter for this re-dispatch
--turn-id <id>(current pending)Target a specific pending turn

Re-dispatches an existing pending turn. Use this when a turn was interrupted (adapter crash, timeout) and you want to re-assign it without losing the turn ID or history context. Does not create a new turn.

step

agentxchain step --role <role> [options]
FlagDefaultDescription
--role <role>(required)The role to assign: pm, dev, qa, eng_director
--adapter <name>(from config)Override the adapter for this turn
--timeout <ms>(from config)Override the adapter timeout
--dry-runfalseCreate the dispatch bundle but do not execute the adapter

The primary command for advancing a run. Creates a turn, writes the dispatch bundle, invokes the adapter, waits for a staged result, validates the result schema, and records it. If validation fails, the turn is marked failed with a retained disposition.

accept-turn

agentxchain accept-turn [options]
FlagDefaultDescription
--turn-id <id>(current staged)Accept a specific turn by ID
--comment <text>""Optional human comment recorded in the decision ledger

Accepts the most recent staged turn result. The result is committed to .agentxchain/history.jsonl and the decision ledger is updated. If the turn included a phase_transition_request, the run enters a blocked:gate state pending approve-transition.

reject-turn

agentxchain reject-turn --reason <text> [options]
FlagDefaultDescription
--reason <text>(required)Human-readable reason for rejection
--turn-id <id>(current staged)Reject a specific turn by ID

Rejects the staged turn result. The turn returns to pending status and can be re-dispatched via resume or replaced by a new step. The rejection reason is recorded in the decision ledger.

Approval commands

approve-transition

agentxchain approve-transition [options]
FlagDefaultDescription
--comment <text>""Optional human comment for the ledger
--jsonfalseOutput structured JSON

Approves a pending phase transition gate. The run must be in blocked:gate state with a pending phase_transition_request. On approval, the phase advances (e.g., planning to implementation, implementation to verification).

Blocked state model:

Blocked stateTriggerResolution
blocked:gateA turn's phase_transition_request was acceptedapprove-transition
blocked:completionA turn's run_completion_request was acceptedapprove-completion
blocked:conflictState file conflict detectedManual resolution, then resume

approve-completion

agentxchain approve-completion [options]
FlagDefaultDescription
--comment <text>""Optional human comment for the ledger
--jsonfalseOutput structured JSON

Approves run completion. This is the final human gate. The run transitions to completed status and no further turns can be created. The ship verdict (.planning/ship-verdict.md) should be reviewed before approval.

Validation

validate

agentxchain validate [options]
FlagDefaultDescription
--mode <mode>fullValidation mode: kickoff, turn, or full
--jsonfalseOutput structured JSON
--fixfalseAttempt automatic fixes for recoverable issues

Validation modes:

ModeWhat it checks
kickoffConfig schema, role definitions, adapter configuration, prompt files exist
turnCurrent staged turn result schema, required fields, objection presence, decision ID uniqueness
fullEverything in kickoff + turn, plus history integrity, decision ledger consistency, phase sequence validity, and state file coherence

Returns exit code 0 on success, 1 on validation failure with details.

Protocol conformance

verify protocol

agentxchain verify protocol [options]
FlagDefaultDescription
--tier <tier>1Maximum conformance tier to verify: 1, 2, or 3
--surface <surface>all surfaces in tierRestrict the run to one surface such as state_machine, dispatch_manifest, or coordinator
--target <path>.Root containing .agentxchain-conformance/capabilities.json
--format <format>textOutput format: text or json

The repo ships a first-party conformance corpus under .agentxchain-conformance/. verify protocol runs those fixtures against any implementation that exposes a stdio-fixture-v1 adapter and declares supported tiers and surfaces in .agentxchain-conformance/capabilities.json.

Typical use:

# self-validate the reference CLI
agentxchain verify protocol --tier 3 --target .

# isolate one surface and emit CI-friendly JSON
agentxchain verify protocol --tier 2 --surface dispatch_manifest --target . --format json

Exit codes:

Exit codeMeaning
0All selected fixtures passed
1One or more fixtures failed
2Verifier or adapter error (malformed response, invocation problem, unsupported target)

Use this command in CI if you fork the runner or build an alternative implementation. "Open protocol" without continuous conformance proof is marketing, not governance.

Migration

migrate

agentxchain migrate [options]
FlagDefaultDescription
--yesfalseSkip confirmation prompt
--jsonfalseOutput structured JSON
--dry-runfalseShow what would change without modifying files
--backuptrueCreate a backup of current state before migrating

Migrates state and config from an older protocol version to the current version (v6). Handles schema changes in agentxchain.json, state.json, and history entries. Creates a .agentxchain/backup/ directory with the pre-migration state unless --no-backup is passed.

Dashboard

dashboard

agentxchain dashboard [options]
FlagDefaultDescription
--port <number>7420Port for the local web server
--no-openfalseDo not auto-open the browser
--host <addr>127.0.0.1Bind address

Launches a local read-only web dashboard with live updates via WebSocket. The dashboard provides seven views:

ViewDescription
Run overviewCurrent phase, status, blocked state, and run metadata
Turn timelineChronological list of all turns with status indicators
Turn detailFull turn result, decisions, objections, and verification evidence
Decision ledgerFilterable table of all decisions across all turns
Objection trackerAll objections with status (raised, resolved, withdrawn)
Phase graphVisual representation of phase transitions and gates
File diffFiles changed across turns with inline diff rendering

The dashboard is strictly read-only. It watches .agentxchain/ for filesystem changes and pushes updates over WebSocket in real time.

Plugin management

plugin

agentxchain plugin <subcommand> [options]
SubcommandDescription
install <source>Install a plugin from a local directory, archive, or npm package
listList all installed plugins with version and hook count
upgrade <name>Upgrade an installed plugin to the latest version
remove <name>Remove an installed plugin and its hooks

See Plugins for full details on authoring and managing plugins.

Common sequences

Manual planning turn

# 1. Start the PM turn
agentxchain step --role pm

# 2. Human writes PM_SIGNOFF.md, ROADMAP.md, stages turn result
# (work happens outside the CLI)

# 3. Accept and gate
agentxchain accept-turn
agentxchain approve-transition

Recover a conflicted turn

# 1. Check what went wrong
agentxchain status --verbose

# 2. The status shows blocked:conflict — resolve manually
# Fix the conflicting state in .agentxchain/staging/

# 3. Re-dispatch
agentxchain resume

# 4. After result is staged, accept
agentxchain accept-turn

Continue after a retained failed turn

# 1. A step failed validation — turn is retained with status: failed
agentxchain status
# Output: Turn turn_abc123 — status: failed (retained), reason: missing objections

# 2. Fix the staged result
# Edit .agentxchain/staging/<turn_id>/turn-result.json to add objections

# 3. Re-validate
agentxchain validate --mode turn

# 4. Accept the fixed turn
agentxchain accept-turn