workflows-status

name	workflows-status
description	Check the status of running or recent SDLC delegated workflows.
disable-model-invocation	false
argument-hint	[--running | --recent N | <run-id>]

SDLC Workflow Status

Query Archon workflow runs — live + historical — without depending on archon being on PATH.

Arguments

• --running — show currently running workflows only
• --recent N — show the latest N runs (default 20)
• <run-id> — show full detail for a specific run, including every node event in order

Steps

1. Query the Archon state

The archon CLI only exposes archon workflow status (active runs, no run-id filter) and archon workflow list (available workflows, not runs). Neither covers the ask. Use the query helper instead — it prefers the REST API on archon serve (if running) and falls back to reading the SQLite state DB at ~/.archon/archon.db:

python3 ${CLAUDE_PLUGIN_ROOT}/scripts/workflows_status_query.py \
    [--running | --recent <N> | --run-id <id>]

Additional flags:

• --url <base> — override the REST URL (default http://localhost:3090)
• --no-rest — skip the REST probe entirely, go straight to SQLite
• --json — machine-readable output (one JSON object per response)
• --timeout <sec> — REST probe timeout before falling back (default 1.0)

Behaviour matrix:

archon serve running?	Output source
Yes	REST API — live + historical, richest
No	SQLite read — historical + most-recent, read-only

If neither is available (fresh machine, no Archon state yet), the script returns (no workflow runs found) cleanly — this is not an error.

Important — Archon UI clickthrough is degraded for CLI-launched runs. archon serve only renders the rich UI (DAG graph, conversation thread, live events) for workflows launched through the server. Workflows started by /sdlc-workflows:workflows-run use the CLI path — they write to the same SQLite DB and show up in archon workflow status and in this skill, but the web UI's per-run detail pages will render empty for them. This is how Archon 1.x scopes the server — not a bug on our side. For CLI-launched runs use this skill (REST or SQLite), the CLI's own stderr stream, or docker logs -f.

Prefix matching on --run-id: the --recent table only prints the first 8 characters of each id. The helper accepts any unique prefix — no need to look up the full 32-char UUID. If two runs share a prefix you will get an "ambiguous" error; paste more characters.

2. Present results

Default output is a table:

Source: rest  (archon serve)
RUN ID     WORKFLOW                       STATUS       STARTED              STEP
---------------------------------------------------------------------------------
bbdfce69   feature-pipeline               completed    2026-04-19 20:26:10
a1b2c3d4   parallel-review-pipeline       running      2026-04-19 20:30:02  2

Report to the user:

• The source row (REST vs SQLite) — if SQLite, hint that starting archon serve in another terminal gives live event data and opens the Archon web UI at http://localhost:3090, which visualises every run, every node, every event.
• The table as-is, or summarise the top 5 with bullet points if the user asked for a narrative.
• For --run-id, the detail block shows per-node node_started / node_completed / node_failed events in order — highlight any failures.
• If any listed run is failed, remind the user that archon workflow run <name> --resume picks up the most recent failed run from where it stopped.

3. Companion skills

• /sdlc-workflows:workflows-run <name> — launch a new workflow.
• Live per-node output during a run: the CLI streams every node's stderr to your terminal as [node-name] <line>. No extra helper needed.
• docker ps --filter name=sdlc-worker and docker logs -f <container> — the currently-running node containers behind any preprocessed workflow.