Control-Plane Commands

Client-side commands for operating a company through the API. Every command here accepts the shared client options (--api-base, --api-key, --context, --profile, --json; see CLI Overview). Full flag lists are on the CLI Reference.

Issues

vagaris issue list [--status todo,in_progress] [--assignee-agent-id <id>] [--project-id <id>] [--match text]
vagaris issue get <issue-id-or-identifier>
vagaris issue create --title "..." [--description "..."] [--status todo] [--priority high] [--assignee-agent-id <id>] [--project-id <id>] [--goal-id <id>] [--parent-id <id>]
vagaris issue update <issue-id> [--status in_progress] [--comment "..."] [--assignee-agent-id <id>]
vagaris issue comment <issue-id> --body "..." [--reopen] [--resume]
vagaris issue checkout <issue-id> --agent-id <agent-id> [--expected-statuses todo,backlog]
vagaris issue release <issue-id>
vagaris issue feedback:list <issue-id> [--vote up] [--status open]
vagaris issue feedback:export <issue-id> --out ./feedback [--format json]

Companies

vagaris company list
vagaris company get <company-id>
vagaris company export <company-id> --out ./exports/acme --include company,agents
vagaris company import <owner>/<repo>/<path> --target existing --company-id <company-id> --ref main --collision rename --dry-run
vagaris company import ./exports/acme --target new --new-company-name "Acme Imported" --include company,agents
vagaris company delete <company-id-or-shortname> --by id --yes
vagaris company feedback:list --company-id <company-id>
vagaris company feedback:export --company-id <company-id> --out ./feedback

company delete is destructive and asks for confirmation unless --yes/--confirm are given. Import and export are covered in Importing & Exporting.

Agents

vagaris agent list
vagaris agent get <agent-id>
vagaris agent local-cli <agent-id-or-shortname> --company-id <company-id> [--key-name ci] [--install-skills --yes]

Skills

vagaris skills browse [--kind bundled|optional] [--category software-development] [--query github]
vagaris skills search "pull request"
vagaris skills inspect github-pr-workflow
vagaris skills install github-pr-workflow --company-id <company-id> [--as pr-flow] [--force]
vagaris skills import ./skills/my-skill --company-id <company-id>
vagaris skills list --company-id <company-id>
vagaris skills show <skill> --company-id <company-id>
vagaris skills file <skill> --path SKILL.md --company-id <company-id>
vagaris skills create --name "Release notes" --slug release-notes --body-file ./SKILL.md --company-id <company-id>
vagaris skills check <skill> --company-id <company-id>
vagaris skills update <skill> --company-id <company-id>
vagaris skills update --all --company-id <company-id>
vagaris skills audit <skill> --company-id <company-id>
vagaris skills reset <skill> --yes --company-id <company-id>
vagaris skills remove <skill> --yes --company-id <company-id>
vagaris skills scan-projects --company-id <company-id> [--project-id <id>]
vagaris skills agent list <agent> --company-id <company-id>
vagaris skills agent sync <agent> --skill github-pr-workflow --company-id <company-id>
vagaris skills agent clear <agent> --yes --company-id <company-id>

install puts a catalog skill in the company library without attaching it to any agent; skills agent sync attaches. audit inspects installed skill bytes without executing them.

Approvals

vagaris approval list [--status pending]
vagaris approval get <approval-id>
vagaris approval create --type hire_agent --payload '{"name":"..."}' [--issue-ids <id1>,<id2>]
vagaris approval approve <approval-id> [--decision-note "..."]
vagaris approval reject <approval-id> [--decision-note "..."]
vagaris approval request-revision <approval-id> [--decision-note "..."]
vagaris approval resubmit <approval-id> [--payload '{"..."}']
vagaris approval comment <approval-id> --body "..."

See Approvals.

Activity and dashboard

vagaris activity list [--agent-id <id>] [--entity-type issue] [--entity-id <id>]
vagaris dashboard get

Heartbeat and run control

vagaris heartbeat run --agent-id <agent-id> [--source on_demand] [--trigger manual] [--timeout-ms 0] [--debug]
vagaris runctl status --run-id <run-id>
vagaris runctl attach --run-id <run-id> [--poll-interval 1000] [--timeout 1800000]
vagaris runctl pause --run-id <run-id> [--reason "..."]
vagaris runctl resume --run-id <run-id>
vagaris runctl cancel --run-id <run-id> [--reason "..."] [--no-wait] [--kill-switch-timeout 10000]
vagaris runctl history [--agent-id <id>]

See Developer Mode for vagaris dev, runctl scope-request and runctl privileged.

Features

Feature convergence operations track a feature's end-state across its dimensions:

vagaris feature list [--product <slug>] [--capability <slug>] [--q text]
vagaris feature show <feature> [--target production]
vagaris feature gaps <feature> [--target production]
vagaris feature endstate <feature> [--target production] [--seeded]
vagaris feature claims <feature>
vagaris feature evidence <feature>
vagaris feature commission <feature> --target production --gaps <ids> --thesis "..." [--disposition build]
vagaris feature verify <feature>
vagaris feature recompute <feature> --target production

What feature show prints, and why it refuses to print a status

vagaris feature show renders truth dimensions, not a single status word. Ten axes are derived independently — target, implementation, runtime, surface, support, commercial, gtm, adoption, observability, convergence — and the states worth acting on are the ones where they disagree: code that exists and does not run, a service that runs and nothing can reach, a reachable feature nobody can buy.

exists > runs > reachable > purchasable > marketable > activated

  blocked at runs - runtime is unreachable, not running
  links after runs were not evaluated; they depend on it

  + implementation  implemented
  x runtime         unreachable            high confidence - runtime_system
      disagrees: deployment declares serving; probe returns connection refused
  x surface         not_surfaced
      needs: no route/UI/SDK edge observed
      from: ingest reachability layer
  ? gtm             unknown

Read it as three things:

The chain is how far the feature got and where it stopped. Links after the stopping point are not evaluated — they depend on it, so reporting them would be a finding about something nobody measured.

The stopping reason distinguishes blocked at from not established at. Blocked means an axis was measured and is negative: somebody has something to fix. Not established means the axis was never measured — nothing is known to be wrong, and an ingest is missing. They call for opposite work.

Each axis carries how it is known. + reached, x measured-negative, ? never measured. Under an axis you may see needs: (the signal whose absence caps it), from: (the ingest that would supply it), and disagrees: (sources that contradicted each other — retained deliberately, because difference is convergence work).

note

deployed is not running. An artifact being placed is a real intermediate state, and it does not clear the runs link — runtime rises to running only from service health, never from a deployment declaration or a surface probe. A resource that is deployed but unreachable therefore reads differently from one that is running, which is the distinction this view exists to preserve.

Use --json for the raw derivation, including each axis's full basis (supporting_evidence, missing_evidence, contradictions, upgrade_path).

Feedback traces

vagaris feedback report --company-id <company-id> [--vote down] [--payloads]
vagaris feedback export --company-id <company-id> --out ./feedback

Secrets, plugins, cloud

Documented on Enterprise Deployment (secrets, plugin) and Hybrid Execution (cloud, worktree, env-lab).