5dive CLI

Agents

An agent is a long-running tmux session running one of the supported coding CLIs (Claude Code, Codex, Antigravity, Grok, openclaw, hermes, opencode). It owns its own Linux user, its own home directory, and — when paired — its own bot/app token. Two agents of the same type can coexist on one host.

Accounts (named auth profiles)

By default every agent of a given type shares one set of credentials, stored under /etc/5dive/connectors/<type>.env. To run two agents of the same type against different accounts, create a named account once and bind agents to it: 5dive account add personal, 5dive account login personal --type=claude, then --auth-profile=personal on agent create (or 5dive agent set-account <agent> personal after the fact). See Accounts for the full surface. The lower-level auth set --auth-profile=<name> and auth login --auth-profile=<name>verbs still work and back the dashboard's device-code flow.

Channels

A channel is the inbound message surface the agent listens on. Today: telegram, discord, dashboard, or none (comma-listable). Every agent type supports Telegram — natively where the CLI ships an MCP plugin contract (claude, openclaw, hermes), and via a bundled 5dive bridge for the rest (codex, grok, antigravity, opencode). Discord is currently claude / openclaw / hermes only. dashboard is a claude-only, token-free web-dashboard chat surface that is folded into every claude create by default — --channels=none opts out.

Workdir

The tmux session starts in the agent's workdir. Default is /home/claude/projects. Override at create time with --workdir=..., or change later with 5dive agent config <name> set workdir=....

Interactive login (TTY)

sudo 5dive agent auth login claude

Hands this process off to the upstream CLI's interactive flow. Don't use this from a dashboard; use the device-code variant below instead.

API key

# Direct
sudo 5dive agent auth set claude --api-key=sk-ant-...

# From stdin (recommended — keeps the key out of shell history)
echo "$KEY" | sudo 5dive agent auth set claude --api-key=-

Anthropic sk-ant-oat01-* tokens are routed to CLAUDE_CODE_OAUTH_TOKEN; everything else becomes ANTHROPIC_API_KEY.

Non-TTY device-code flow

The dashboard uses this flow because it runs without a PTY. Each call is async — start, poll until you get a URL, show the URL to the user, then submit the callback code the upstream login redirects to.

# 1. Start a session — returns a session id
sudo 5dive agent auth start claude --json
# -> {"ok":true,"data":{"session":"01HXX..","state":"awaiting_url"}}

# 2. Poll until state=awaiting_code; data.url is what the user opens
sudo 5dive agent auth poll 01HXX.. --json

# 3. User pastes the callback code from the redirect URL back to you
sudo 5dive agent auth submit 01HXX.. --code=anthropic#abc123

# 4. (optional) cancel a pending session
sudo 5dive agent auth cancel 01HXX..

Status

# Sentinel-only (fast)
sudo 5dive agent auth status

# Live probe — actually calls the API
sudo 5dive agent auth status --probe

# One type only
sudo 5dive agent auth status --type=claude --probe

Identity (whoami)

5dive whoami [--json]

Prints who is acting, under whose authority, and at what tier — with the source of each. Identity resolution is uid-first: $EUID (or sudo's $SUDO_UID at real root) resolved against /etc/passwd, never argv/--from, $USER, $SUDO_USER, or id/getent(both PATH-resolved and therefore spoofable). An actor that can't be measured this way exits 6 (auth_required) rather than printing unknown with a success status.

Actor-routed gh

5dive gh <gh args...>                  # writes -> machine account; admin + reads -> your own credential
5dive gh --as=bot|caller <gh args...>  # force one identity
5dive gh --explain <gh args...>        # print the routing decision, run nothing
5dive gh whoami                        # resolve BOTH identities

Routes every ghcall by operation instead of by caller: writes go out under a shared machine account so a compromised agent can't act as a specific human, while admin calls and reads stay on your own credential — a plain read leaves no actor field to attribute, and the machine account sees fewer repos than a signed-in human does. The PAT backing the machine account never leaves /etc/5dive/connectors/github-bot.env (root only); an agent gh write authenticates as that shared account, not as the human operating the box, so the audit trail can tell a bot write from a human one.

Create and sign in

# 1. Create an empty account
sudo 5dive account add personal

# 2. Sign in interactively (TTY hand-off)
sudo 5dive account login personal --type=claude

# Or, set an API key non-interactively
echo "$KEY" | sudo 5dive agent auth set claude \
  --api-key=- --auth-profile=personal

Names: lowercase letters, digits, _, and -; must start with a letter; max 32 characters. The literal name defaultis reserved (it's the magic value agent set-account <agent> default uses to clear a binding).

Inspect

sudo 5dive account list           # name, types signed in, # agents bound
sudo 5dive account show personal  # detail incl. env keys present
sudo 5dive account usage          # per-account 5h/7d rate-limit usage

{
  "ok": true,
  "data": [
    { "name": "personal", "types": ["claude"], "agents": ["scout","builder"] },
    { "name": "work",     "types": ["claude","codex"], "agents": ["work-bot"] }
  ]
}

Bind agents

# At create time
sudo 5dive agent create scout --type=claude --auth-profile=personal

# After the fact (rebinds + restarts the agent to pick up the new env)
sudo 5dive agent set-account scout work

# Clear the binding (agent falls back to the shared default credentials)
sudo 5dive agent set-account scout default

Rename and remove

# Rename — repoints every bound agent's symlink and restarts the units
sudo 5dive account rename personal primary

# Remove — refuses if any agents still bind to it
sudo 5dive account remove primary

account remove is a safety net: if any agent has its authProfile set to the account, the command fails with class conflict (exit 5) and prints the agent names. Rebind or delete those agents first.

Account vs `agent auth` (lower-level)

The legacy agent auth set/login/start/poll/submit/cancel verbs still work — they take an --auth-profile=<name>flag and back the dashboard's device-code flow. Prefer account for human-driven flows; reach for agent auth start|poll|submit when you need the non-TTY device-code lifecycle from a programmatic caller.

Create

5dive hire <name> is ergonomic sugar over agent create: it defaults --type=claude, forwards every other create flag verbatim, and peels off --role / --title to record the agent in the org chart once it exists (sudo 5dive hire cto --role="CTO"). agent create stays the canonical form and is what the rest of this section documents.

sudo 5dive agent create <name> --type=<type> \
  [--channels=none|telegram|discord|dashboard[,ch...]] \
  [--telegram-token=<bot-token>] [--discord-token=<token>] \
  [--workdir=<absolute-path>] \
  [--auth-profile=<name>] \
  [--isolation=standard|admin|sandboxed] \
  [--provider=<id> --api-key=<key|->] [--model=<slug>] \
  [--telegram-home-channel=<chat-id>] [--telegram-allowed-users=<csv>] \
  [--with-skills=<spec>[,<spec>...]] [--inherit-memory=<scope>] \
  [--yolo | --autonomy=standard|yolo] \
  [--no-skills] [--no-team-bot] [--defer-auth] [--can-push]

Names: lowercase letters / digits / hyphens, must start with a letter, max 16 characters. The CLI installs the type binary on demand if it's missing, then refuses to create the agent unless the type is authenticated.

--with-skills preinstalls one or more skills on the new agent. Spec is either a bare id (defaults to 5dive-ai/skills) or <owner/repo>:<id>. Multiple specs are comma-separated. When the create call is made by another agent on a claude-typed agent, the flag defaults to --with-skills=5dive-cli so spawned children inherit inter-agent comms knowledge automatically. Use --no-skills to opt out. A failed skill install warns but does not roll back the agent — rerun 5dive agent skill <name> add ... to retry.

--defer-authskips the auth gate so the agent can be created before credentials exist (useful when the agent's own first-run UI handles sign-in). --provider=<id> --api-key=<key|-> is for hermes/openclaw only — BYO key for one of openrouter, google, minimax, moonshot, huggingface, anthropic, deepseek, qwen, nous, openai, zai (mutually exclusive with --defer-auth). When the host has a shared team bot configured, new no-bot agents auto-attach to it (own forum topic, send-only on the shared token) — --no-team-bot opts out.

--model=<slug> sets the runtime model at create time instead of a follow-up agent config set model=.... For a BYO-provider claude agent it accepts any slug the provider serves, overriding the CLI's safe per-tier defaults. --telegram-home-channel=<chat-id> (hermes only) and --telegram-allowed-users=<csv> seed the channel config at create time instead of a separate agent config call afterward. --inherit-memory=<scope>seeds the new hire's recall store from shared knowledge so it boots knowing the company — scope is a comma-list of wiki, a sibling <agent-name> (its shareable facts only), or all/team.

--can-push grants the agent delegated 5dive push (a scoped sudoers entry for the push helper) — refused on --isolation=sandboxed, a no-op with a warning on --isolation=admin (already covered by its broader sudo).

--yolo (alias --autonomy=yolo) sets the agent's autonomy mode. claude-only: it appends a standing “act on your own recommendations, still honor hard gates” directive to the system prompt (via --append-system-prompt, so it survives a /clear) — the agent stops asking for permission on reversible work but still parks secrets/approvals on a human. Default is standard; change it later with agent config <name> set autonomy=....

List & inspect

sudo 5dive agent list                # text or --json (carries model + effort per agent)
sudo 5dive agent info <name>         # type, CLI version, model, channel + state
sudo 5dive agent stats <name>        # state, restart count, last exit
sudo 5dive agent logs <name> --lines=200 [--follow] [--tmux]

--tmux dumps the tmux scrollback (what the user sees in the TUI). Without it, logs come from systemd / journalctl. agent list and agent info are no-sudo surfaces — any agent can run them regardless of isolation tier.

Install a type binary

sudo 5dive agent install <type>              # install if missing (no-op if present)
sudo 5dive agent install <type> --upgrade    # reinstall @latest (aliases: --force, -u)

agent create already installs a missing type binary on demand — reach for agent install directly to pre-warm a type before the first create, or to force a stale binary back to latest without touching the agent itself.

Start, stop, restart, remove

sudo 5dive agent start   <name>
sudo 5dive agent stop    <name>
sudo 5dive agent restart <name> [--defer]   # --defer = internal deferred self-restart
sudo 5dive agent rm      <name>   # removes user, unit, tmux session, env

Reconfigure

sudo 5dive agent config <name> set channels=<none|telegram|discord>
sudo 5dive agent config <name> set workdir=<path>           # "default" clears
sudo 5dive agent config <name> set auth-profile=<name>      # "default" clears
sudo 5dive agent config <name> set telegram.token=<token>
sudo 5dive agent config <name> set discord.token=<token>
sudo 5dive agent config <name> set telegram.allowed-users=<id1,id2,...>
                                                            # seed access.json allowlist (no pair-code gate)
sudo 5dive agent config <name> set telegram.home-channel=<chat-id>
                                                            # hermes only — chat the gateway posts to unsolicited
sudo 5dive agent config <name> set model=<id>               # claude/codex/grok/antigravity;
                                                            # claude: opus|sonnet|haiku|fable
sudo 5dive agent config <name> set effort=<low|medium|high|xhigh|max>
                                                            # claude only — reasoning effort;
                                                            # xhigh/max are Opus-tier
sudo 5dive agent config <name> set autonomy=<standard|yolo>
                                                            # claude only — yolo appends the "act on
                                                            # your recs, still honor hard gates" directive

# Shorter alias for the auth-profile case
sudo 5dive agent set-account <agent> <account|default>

Send input / attach

# Inject a message into the running tmux session (sends keys + Enter)
sudo 5dive agent send <name> "implement the dashboard skeleton"

# Hand off a chat request: tells the receiver to answer in that
# Telegram/Discord chat via its OWN bot instead of relaying back
sudo 5dive agent send <name> "user asks ..." --reply-to-chat=<id> [--reply-to-msg=<id>]

# Attach your terminal to the session — Ctrl-b d to detach
sudo 5dive agent <name> tui

When called from another agent, send auto-wraps the payload with a [5dive-msg from=<sender> id=<id>] envelope so the receiver knows who pinged it. Use --from=<label> to override and --raw to skip wrapping. See Inter-agent comms for the full protocol and the synchronous agent ask wrapper.

Clone

sudo 5dive agent clone <src> <dst> [--channels=...] \
  [--telegram-token=...] [--discord-token=...] [--workdir=...]

Clones type, workdir, and auth profile from <src>. Channel + tokens must be passed fresh — two agents cannot share a Telegram bot.

Deploy (INST-5)

5dive deploy <id|DIVE-N> [--target=<project@ref>] \
  [--env=production|preview] [--dry-run]

Same delegated-credential shape as 5dive push — it deploys ONLY the project@refthe task declares, ONLY once that task's gate is cleared. --target can also come from a Target: <project@ref> line in the task body, mirroring how push reads Branch:.

Team templates

Bundled multi-agent company structures — provision a whole team in one call. team import wraps up, so it is idempotent too.

sudo 5dive team ls                                  # list bundled templates
sudo 5dive team import <slug|path> [--auth-profile=<name>]

Export

# Config-only pack (default — safe to share)
sudo 5dive agent export <name> --out=./mybot.tar.gz

# With persona memory — a two-phase, deny-by-default review gate
sudo 5dive agent export <name> --with-memory          # 1. writes a redacted DRAFT to review/edit
sudo 5dive agent export <name> --approve-memory=<dir> # 2. seals the reviewed memory into the pack

--with-memory never ships memory blind: phase one distills only reference/project knowledge facts (private user/feedback facts are excluded) into a draft directory for you to read and edit; nothing is packed until you re-run with --approve-memory=<draft dir>.

Marketplace & import

The character-pack registry (<org>/character-packs on GitHub) is a public catalogue of ready-made agent personas. Browse it, then import any entry by its bare slug into a fresh agent name:

# Browse the registry
sudo 5dive agent marketplace ls

# Import a published persona under a new name + your own bot
sudo 5dive agent import lilbro --as=scout \
  --channels=telegram --telegram-token=123456:ABC...

# Import from a local .tar.gz you were handed
sudo 5dive agent import ./mybot.tar.gz --as=scout

# Provision a live agent from an OpenAgent persona.yaml
sudo 5dive agent import --from-persona=./dario.persona.yaml --as=scout \
  --type=claude --channels=telegram --telegram-token=123456:ABC...

--from-persona turns the OpenAgent self-author flow into self-provision: the persona supplies identity (name, role, look, voice, behavior) and the CLI synthesizes a character pack from it — a generated identity doc, the portrait from face.ref as the avatar, and a manifest seeding find-skills / 5dive-cli / compile-knowledge / openagent — then runs the normal import. Runtime config (--type, --isolation, --model, --effort, --channels) comes from flags.

import takes either a registry slug or a local pack file and recreates the agent under --as=<name>. Because packs carry no secrets, you supply the new agent's own token / auth-profile / workdir at import time. Skills are re-added from their recorded refs (any skill not in a published repo is skipped and reported). The dashboard's Marketplace modal drives this same path.

Pairing

# Option A — give the user a 6-character code, they DM the bot, paste it back
sudo 5dive agent pair <name>                    # prints/returns code

# Option B — paste the bot's reply directly (dashboard flow)
sudo 5dive agent pair <name> --code=AB12CD

# Option C — seed access.json directly with a known Telegram user id
# (pairs with agent telegram-discover, which long-polls getUpdates and
# returns {userId, chatId, username} on the first inbound DM)
sudo 5dive agent pair <name> --user-id=<id> [--chat-id=<id>]

Allow-list

The plugin's allow-list lives at ~/.claude/channels/<channel>/access.json inside the agent's home. Pairing appends to allowFrom; rotate the bot token via 5dive agent config <name> set telegram.token=....

Auto-attributed sends

When the caller is an agent-* Linux user (i.e. one agent shelling out to talk to another), the CLI auto-detects the sender from $SUDO_USER and wraps the payload as:

[5dive-msg from=<you> id=<8-hex>] <your text>

Humans calling sudo 5dive agent send directly are unaffected — only sends from agent users get the envelope. Override with --from=<label> or skip wrapping entirely with --raw.

Replying

A receiver that sees a wrapped message replies the same way it would talk to anything else — by name. The [re=<id>] prefix is convention, not enforced; it lets the sender match replies when juggling several outstanding asks.

# Inside the receiver's session, after seeing
# [5dive-msg from=scout id=ab12cd34] please summarise the audit

sudo 5dive agent send scout "[re=ab12cd34] auth middleware looks clean except ..."

Synchronous request/response: agent ask

sudo 5dive agent ask <name> "<prompt>" \
  [--from=<sender>] \
  [--timeout=120] \
  [--idle-secs=5] \
  [--poll-secs=2] \
  [--json]

Sends the wrapped envelope, then watches tmux capture-pane after the marker line until the slice has been quiet for --idle-secs (default 5s) — at which point it returns the reply body. Times out with class timeout (exit 11) if the receiver never goes idle within --timeout.

{
  "ok": true,
  "data": {
    "name": "scout",
    "from": "coordinator",
    "msg_id": "ab12cd34",
    "reply": "auth middleware looks clean except for ..."
  }
}

Caveats

Idle-by-stability is heuristic. A receiver that streams progress continuously will keep ask awake until --timeout fires. For long agentic work, prompt the receiver for a terse final summary, or use plain send + logs and poll on your own schedule.

The reply is whatever was on screen. It includes any chrome the receiver CLI prints (cursor lines, status hints) — don't expect a clean JSON body unless the prompt explicitly asks for one.

No retries, no delivery confirmation. If the receiver crashed mid-reply you'll get a partial slice or a timeout, nothing in between.

When to use what

Fire-and-forget delegation: agent send, then poll agent logs --tmux at your own convenience. Need an answer before continuing: agent ask. Fan-out across N workers: loop agent send, or run several agent ask calls in parallel via & + wait.

Verify loops (maker → verifier)

A task can carry a declarative acceptance loop so “done” is proven, not just claimed. Attach acceptance criteria, a verify command, and (optionally) a separate verifier agent at create time:

5dive task add "ship the export endpoint" \
  --accept="returns 200 + a .tar.gz" \
  --verify="curl -fsS localhost:3000/export -o /tmp/o && file /tmp/o | grep gzip" \
  --verifier=reviewer --max-iters=3

5dive task verify <id|PREFIX-N> [--cmd="<command>"] [--no-done]
                                     # run the check; exit 0 => proven-done (flips to done)
5dive task reject <id|PREFIX-N> [--feedback="<what to fix>"]
                                     # verifier's FAIL verdict — bounce back to the maker
5dive task loops [--stuck] [--all] [--escalate-stuck]
                                     # board of active loops: iteration/cap + ⚠ stuck flag

With a --verifier(which must differ from the assignee), the maker's task done does not close the task — it hands off to the verifier, who grades against the criteria / runs task verify, then closes it on PASS or task reject --feedback= on FAIL (bounce back to the maker, or escalate to a human at --max-iters). The writer never grades itself. task loops is the observability view — --escalate-stuck pings the owning agent + the human on loops that have stalled.

Verification is on by default: a non-trivial task add auto-derives acceptance criteria and assigns a grader distinct from the assignee, so a plain task done hands off to grade instead of closing. Trivial bodyless chores, low-priority tasks, and recurring templates auto-skip it; --no-verify is the explicit opt-out, and FIVE_VERIFY_DEFAULT=0 is a fleet-wide kill switch. A task filed without the rail can still get one later: 5dive task verifier <id> <agent> [--accept=<criteria>] [--max-iters=<n>] attaches it after the fact (grader must differ from the assignee), or re-points an already-in-review handoff to a different grader.

A delivered loop is durable against its own maker. Once a task is handed to its verifier, task done from anyone but that verifier is refused outright — even a second task done from the maker itself. Send a correction to the verifier and let them fold it in rather than re-running done; real exits mid-review are task reject (bounce back), task verify --cmd= (evidence-backed close), or task cancel.

Delivery & the merge-gate

If work ships as a pull request, use task deliver <id> --pr=<url> [--result=<text>] instead of task done— it hands off to the verifier without closing, the maker's own act of declaring “this is what I shipped.”

donemeans merged-to-main, not “PR opened.” Once a task carries a declared delivery binding — a task deliver --pr= reference, or a Branch: <name> body line from task set-branch / task add --branch= — task done refuses to close until gh confirms that PR is merged and its checks are not red. Even with no declared binding, a second, mandatory auto-detect gate still runs on every close: it scans open PRs across the known repos for a title/branch naming the task's ident, and separately checks the close's own result text for a shipping claim (“merged as #6”, a Delivered: line — a PR merely cited in passing is deliberately not checked). --force-merge-gateis the audited override for false positives (a flaky post-merge CI run); the leftover unmerged PR still surfaces in the weekly branch-hygiene digest. When the gate can't reach a verdict at all (no gh token, a broken scan), the close still proceeds but the result is stamped [merge-gate: UNVERIFIED — …] rather than looking silently clean.

task set-branch <id> <branch> binds a task to a git branch for delegated push, writing or updating that Branch: body line. task merge-audit is the read-only retrospective version of the merge-gate check, run over already-done tasks — it only reports, never reopens. done/cancel also reclaim disk on close: node_modulesis deleted from the task's worktree (gitignored, npm ci-regenerable) unless you pass --keep-worktree; the worktree directory itself is never deleted since it may hold unpushed commits. task reclaim <id>|--all [--dry-run] runs that same sweep manually.

Human task inbox

When an agent needs a decision, approval, secret, or a manual step only a person can do, it parks the task on a human instead of guessing:

5dive task need <id> --type=decision|secret|approval|manual|access \
  --ask="<one crisp question>" [--options=A|B] [--recommend="A"] [--tier=0|1|2] \
  [--probe=<cmd>]                    # type=access only
5dive task need <id> --withdraw      # cancel a still-pending gate that's now moot
5dive task inbox                     # list ONLY human-gated tasks
5dive task inbox --send [--channel-proof=<chat>]
                                     # root-only: DM the owner ONE tap-button digest
                                     # of up to 10 pending gates (fresh per-gate nonce,
                                     # never exposed via --json)
5dive task answer <id> --value="..."   # record answer, unblock, ping the agent
5dive task clear-recs --channel-proof=<chat_id> [--only=<id>]
                                     # bulk-clear every eligible low-risk gate (tier<2,
                                     # has a --recommend, not lead-routed) as the paired human

The gate pings the owner (Telegram inline buttons when paired); answer clears it and wakes the owning agent to resume.

--type=accessis for “I'm blocked on a permission/grant I don't have.” Pair it with --probe=<cmd> — a self-check that must currently fail; if it succeeds the gate is refused (“you already have this access”) instead of pinging a human for nothing. Omitting --probe still files the gate, just with a warning to confirm you actually tested the block. 5dive task coordinator [--json]prints the resolved org coordinator — the one agent a surface should pin a needs-you banner to; empty output means an ambiguous or missing org, which callers should treat as “nobody pins.”

--withdrawcancels a gate that's still pending — the antidote to filing an access/secret/approval gate that turned out to be moot. It is nota grant: it never records an answer, so no secret or approval is ever recorded as provided — which is why it's safe to allow without a human tap. Authorized callers are the gate's filer, the filer's routed lead/coordinator, or a genuine human; a real grant-clear still goes exclusively through task answer.

--tier=0|1|2 sets how hard the gate blocks. Tier 0 auto-clears — the --recommendvalue applies immediately with no ping (the daily digest's “auto-cleared gates” section is the record). Tier 1 pings normally, but if unanswered for 48h the recommendation is auto-applied and the owner notified (the default for decision). Tier 2 is a hard human gate that never auto-applies (the default for approval / secret / manual). Money, public comms, secrets, destructive, and brand asks are floored to tier 2 by the CLI regardless of the flag — reserve tier 0/1 for low-stakes reversible calls.

approval and secret gates are human-only: an agent-* caller is refused, and once gate-proof enforcement is on, clearing one requires human evidence: either a per-gate nonce that only a real Telegram approve tap carries, or a non-agent SUDO_UID(an operating-system user that isn't an agent). A sudo-capable agent has neither, so it can't silently clear its own approval gate. Trusted UI paths clear it for you: the dashboard and drop links run as a real (non-agent) user, and the Telegram approve button carries the gate's nonce.

Parking & escalation

Not every wait is a human gate. task park puts a task to sleep without parking it in the human inbox — for revisit-later work or a task waiting on an external date — and auto-wakes it back to todo at --wake. task escalate raises urgency without filing a gate: it bumps priority one tier (capped at urgent) and pings the owning agent plus the paired human.

5dive task park <id|PREFIX-N> --reason="revisit after launch" --wake=+3d
                                     # --wake=<YYYY-MM-DD[ HH:MM]|+Nd|+Nh> — REQUIRED,
                                     # --reason is REQUIRED too (fail-closed)
5dive task unpark <id|PREFIX-N>      # wake it early, back to todo
5dive task escalate <id|PREFIX-N>    # +1 priority tier + ping owner & human

Both --reason and --wake are required — no more block-graveyard with no revisit date. park also refuses to run over a task that already has a live, unanswered task need gate — answer the gate first, or parking would silently destroy it with no audit trail.

Gate-proof (tamper-evident approvals)

Because tasks.db is group-writable, gate closures are made tamper-evident: task answer stamps the real pre-sudo invoker and an HMAC (signed with a root-only key) over the closure facts, so a raw-sqlite3 bypass or an after-the-fact edit is detectable. When enforcement is on fleet-wide, an agent-path answer to an approval/secret gate with no human evidence (a per-gate nonce or a non-agent SUDO_UID) is rejected.

# Verify a stored closure signature: signed=? valid=?
sudo 5dive gate-proof verify <id|PREFIX-N>

# Toggle enforcement for this box (reject vs audit-only)
sudo 5dive gate-proof enforce on|off|status

Self-steer it: objective replan

objective replan <name> drives one cycle: a planner proposes a diff (new / reprioritized / cancelled tasks) toward the target, validated the same way a goal add plan is.

5dive objective replan <name> --dry-run --json     # see the proposed diff, create nothing

5dive objective replan <name> --json \
  [--max-new-per-cycle=3] [--no-progress-limit=3] [--yes] [--force] [--from-gate=<id>]

--yes waives only the count-over-checkpoint gate — a Tier-2 task in the diff still hard-gates, and nothing under a shadow/propose-only run is waivable. --no-progress-limit=<n> auto-pauses the objective after N flat/adverse cycles. Always --dry-run a replan first, same discipline as goal add.

Loop packs (marketplace)

A loop pack is a published recurring agentic workflow — a persona + skills + cadence — you install onto an existing agent. It sets the agent up to run that workflow on a schedule.

sudo 5dive loop show <slug>                       # peek at a marketplace loop pack
sudo 5dive loop install <slug> --onto=<agent> \
  [--cron="<5-field>"] [--ceiling=<tokens>] [--dry-run]

Relay loops & scorecards

5dive task loop startis the higher-level relay that backs the dashboard loop builder: a chain of steps where each agent's task done hands off to the next, with optional human gate steps. Because it's just the task queue underneath, you can build and edit a running loop conversationally (the dashboard can't safely edit a live one).

5dive task loop start --title="Content pipeline" --steps='[
  {"agent":"olivia","label":"Pick topic + brief","handoff":"briefs"},
  {"agent":"theo","label":"Draft the post"},
  {"gate":"approval","label":"You approve before publish"},
  {"agent":"theo","label":"Publish and close"}
]'
5dive task loop ls                   # board of relay runs: per-step progress + status

Each row on task loop ls carries the latest grade scorecard for the run — a score column (e.g. 84/100) on the text board and the full scorecard_json (banded criteria) in --json, empty until a verifier grades it. The maker→verifier control window lives under task loops:

5dive task loops --runs              # loop_runs control window: topology / stage /
                                     # iteration / token-ceiling / status
5dive task loops --runs --watch      # live repaint
5dive task loops --kill <loopId>     # request a deferred-safe stop

Org chart

A lightweight reporting structure over the agents on a host — who manages whom, and what each agent's role is. Dashboards and coordinator agents read it to route work.

5dive org set <agent> --manager=<agent> [--role=<text>] [--title=<text>]
5dive org tree                       # render the hierarchy
5dive org show <agent> | ls | rm <agent>

Heartbeat (wake-on-work)

Enrolled agents are woken only when they have queued tasks — one task per tick — instead of idling in a hot loop. The root cron driver is heartbeat tick.

sudo 5dive heartbeat on <name> [--every=<dur>] [--no-fresh]   # default 30m;
                                                              # /clear before each task unless --no-fresh
sudo 5dive heartbeat off <name>
sudo 5dive heartbeat ls              # enrolled agents + next wake + queued count
sudo 5dive heartbeat tick            # cron driver (root); wakes due agents with work

Setup & roster

sudo 5dive council init --seats=<a:chair,b,c,...> --threshold=<majority|all|N|a/b> --veto=<principal>
                                             # human-seed the primary Council ONCE
                                             # (fail-closed if already init'd; --force re-seeds,
                                             # logged in lineage)

5dive council roster                    # live seats, threshold/quorum, veto holder, lineage head
5dive council log [--limit=N]           # sealed verdict history (genesis + every motion + veto)
5dive council record [--json]           # per-seat track record: votes scored vs REAL task outcomes
5dive council lineage [verify|ls]       # verify the sealed hash-chain, or list it
5dive council verify [<receipt-digest>] # whole-lineage integrity + constitution-drift check

Convening a vote

5dive council convene "<question>" --subject="<what this decides>" \
  [--seats=a,b,c] [--mode=quick|deliberate|adversarial] \
  [--bench=<name>] [--class=<decisionClass>] [--threshold=<n>] \
  [--timeout=120] [--idle-secs=5] [--poll-secs=2] [--standalone]

By default convene dispatches to the real seated agents — each votes via its own harness over agent ask, blind on the first round — and seals an auditable, tamper-evident verdict. --standalone uses a single-key modelCall seam instead (needs COUNCIL_API_KEY/COUNCIL_BASE_URL; COUNCIL_MOCK=1 runs a deterministic offline council for tests/smoke). A PASS from the primary Council offers the founder a one-time, non-blocking veto tap.

Membership motions & veto

sudo 5dive council {promote|demote|expel} --subject=<seat> [--lens="..."] [--mode=...] [--dry-run]

5dive council sign-vote --seat=<id> --vote=approve|reject|escalate|abstain --convene=<id> \
  (--qdigest=<hex>|--question=<text>) --key-file=<PEM|-> [--rationale=...] [--emit=line|json]
5dive council verify-votes --votes=<json|@file> --roster=<json|@file> --convene=<id> \
  (--qdigest=<hex>|--question=<text>)

5dive council veto exercise --receipt=<digest> --nonce=<tap nonce> [--tier=hold|posthoc] [--reason=...]

A membership motion recuses the subject and auto-derives its decision class (promote = majority, demote/expel = 2/3). sign-vote lets a seat sign its own vote at source, emitting the COUNCIL-SIG: line pasted after COUNCIL-VOTE; verify-votes re-checks every co-signed vote against the roster's public keys and revocation list. A veto can never be asserted from a bare CLI string — convene --veto-by=... is a detected forge-attempt, refused with exit 9; veto exercise is the only authenticated path, gated on the receipt digest plus a real tap nonce.

Benches & gate routing

5dive council bench ls | show <name>
sudo 5dive council bench add <name> --seats=a:lens|b:lens [--mode=] [--threshold=] [--desc=]
sudo 5dive council bench rm <name>

5dive council gate-clear <task|DIVE-N> [--mode=deliberate] [--seats=a,b,c] [--dry-run]
5dive council rot-triage [<task|DIVE-N>|--all] [--older-than-hours=48] [--dry-run]

sudo 5dive council amend --file=<new 5dive.md> [--dry-run]

Built-in benches: council, ship, brand, security (the council bench itself is refused — its seats change only via promote/demote). gate-clear routes an open tier-1 gate to the council instead of a human — a tier-2 or human-only-type gate is never self-cleared, always bumped up. rot-triage re-briefs a stale unanswered tier-2 gate sharper for the human but never clears it (tier-2 stays human-only). amend is the constitutional-class motion — 2/3 + full quorum + veto — and only swaps 5dive.md on a PASS.

Scheduled convenes

sudo 5dive council schedule add <name> --question="<template>" --cron="<m h dom mon dow>" \
  [--bench=<name>] [--mode=quick|deliberate|adversarial] [--class=<c>] \
  [--max-actions=N] [--ballot-deadline=<secs>] [--context-cmd="<sh>"] [--no-cron]
5dive council schedule ls | show <name>
sudo 5dive council schedule rm <name>
5dive council schedule run <name> [--dry]     # what cron actually invokes

schedule add productizes a recurring convene: it binds a named question template to a cron expression and installs a managed crontab line keyed by a # 5dive-council-schedule:<name> marker, so re-running add updates it in place and rm only ever touches that one line — never a duplicate, never a clobber of an unrelated entry. The template may embed {{date}}/{{context}}; --context-cmd is a shell snippet run at each fire whose bounded stdout fills {{context}}. add/rm write the root-owned schedule config, so they run under sudo; ls/show/run don't.

run <name> gathers context, convenes on the default ballot rail, then files up to --max-actions ACTION:-prefixed board tasks from seat rationales, each stamped with the sealed receipt digest. An inquorate or failed run is logged but never fatal (exit 0) — only a quorate PASS files tasks. --dry prints the would-be task add calls instead of running them.