status

A read-only command that shows the current state of an orchestrated run, including its latest phase, next approval point, blockers, and active team.

In plain words
What is it for?
Use it to check progress, find the next required gate, identify blockers, and see which team is assigned to the current phase.
Why use it?
It lets you see where a multi-step run stands without changing files or advancing the process.

Command

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add commands/lookatitude/guild/status
Clone the repo
git clone --depth 1 https://github.com/lookatitude/guild
Per session 26 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,101 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00026 $0.01101
Opus 5 $0.00013 $0.00550
Sonnet 5 $0.00005 $0.00220
Haiku 4.5 $0.00003 $0.00110

Measured 2d ago against content hash 5841bc2754be, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

status scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

commands/status.md · 103 lines

How it starts

The opening of the file, as written. The whole thing — 103 lines — stays where its author put it; the contents beside it link to each section on GitHub.

/guild:status — lifecycle helper (read-only)

Reads the active run state: current run, furthest phase, next gate, and blockers. No phase — acts on the active run. Read-only R, writes no file.

Also surfaces the per-phase active team (resolved via resolveTeamFile(root, slug, null) — consults .current then legacy; reports "none for this phase" if absent).

Args & local flags

  • Args: — (no positional)
  • --no-index — per-invocation bypass of the optional read-through cache, forcing a one-shot filesystem scan (Invariant FS-CANONICAL: the filesystem stays canonical; the index is never authoritative and never required).

Gates

None — R (read-only).

Output

Prints state (no file written).

Run-start preflight (settings-control-and-tmux U3/U6)

At the very top — before any filesystem scan and before the lightweight run-trace — the run-trace CLI runs this preflight for you; you do not call runStartPreflight yourself.

Since wave 2 the run-trace CLI is the sole caller of runStartPreflight (scripts/lib/runstart-preflight.ts; canonical contract in guild.md §Run-start preflight): it resolves the 7-source inheritance chain, validates closed keys, probes tmux, and detects providers. status uses the lightweight run-trace path (start-and-close at once), so the resolved snapshot is not persisted for lightweight runs — but the tmux/provider resolution stays consistent with other commands. Read any resolved config for an existing run with readResolvedSettingsSnapshot(runId, { cwd }).

Run recording

At the very top of the command body — before any filesystem scan — record a lightweight status run (SC-B OQ6, §435):

node ${GUILD_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-$HOME/.local/share/guild/dist/claude-code}}/hooks/dist/run-trace.js status \
  --cwd "$(pwd)"

This uses the dedicated status sub-command of run-trace.js, which calls recordStatusLightweight. Gate: if settings.json record_status_runs: false, the call is a no-op (pure-read path restored). On the recorded path, writes only run.yaml + provenance.json to .guild/runs/ — never touches wiki/decisions/indexes/initiatives. The "status is read-only" contract is preserved; only a lightweight replay trace is added. No --initiative flag; no --run-class flag (the status sub-command forces lightweight internally via B3).

Read the full file on GitHub · 103 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 103 lines · 26 tokens per session scan A 5841bc2754be

Subscribe to this mod's changes

status is a command published in the GitHub repository lookatitude/guild (7 stars, last pushed 2d ago), licensed MIT. It adds 26 tokens to every session and 1,101 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.