Skip to main content
GeneralSteveGJones

workflows-status

Check the status of running or recent SDLC delegated workflows.

Stars
38
Source
SteveGJones/ai-first-sdlc-practices
Updated
2026-05-11
Slug
SteveGJones--ai-first-sdlc-practices--workflows-status
View on GitHubRaw SKILL.md

// install — copy + paste into any project

mkdir -p .claude/skills && curl -fsSL https://raw.githubusercontent.com/SteveGJones/ai-first-sdlc-practices/HEAD/plugins/sdlc-workflows/skills/workflows-status/SKILL.md -o .claude/skills/workflows-status.md

Drops the SKILL.md into .claude/skills/workflows-status.md. Works with Claude Code, Cursor, and any agent that loads SKILL.md files from .claude/skills/.

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.