openstation-supervisor

name	openstation-supervisor
description	Supervise active openstation tasks — list in-progress and review tasks, check session health for each, and present actionable recommendations. Use when asked to check on tasks, supervise work, or get a status overview.
user-invocable	false

Open Station Supervisor

Monitor and supervise active tasks across the vault. Diagnose health, identify blockers, and recommend next actions.

Diagnose only. This skill never mutates state — no openstation status, no openstation run, no openstation create, no file edits. It looks; it does not touch.

Procedure

1. Gather active tasks

openstation list --status in-progress
openstation list --status review

Collect all task IDs from both lists.

If either command errors or returns nothing while you have prior evidence of active work, treat that as CLI-down, not "no active tasks" — see step 2's false-quiescence guard.

2. Check each task's liveness

For each task, decide whether an agent is actually running. The primary liveness signal is tmux, not the CLI — the control-plane CLI can itself break (e.g. an ImportError after a refactor) and silently return empty results. A run is alive if and only if its tmux window/session exists.

2a. Primary signal — tmux (CLI-independent)

# All windows across all tmux sessions (window + session modes both covered).
tmux list-windows -a -F "#{window_name}" 2>/dev/null | grep <task-id>

Window names follow {alias}-{task-name} (default alias os, e.g. os-0479-...); verify runs are os-verify-<task>. A match means a live backend window exists for the task.

• Match found → liveness = RUNNING (regardless of what openstation sessions says).
• No match, tmux exit 0 → liveness = NOT RUNNING (proceed to enrichment).
• tmux not installed / server not up / non-zero exit → liveness = UNKNOWN (do not assume done).

2b. Enrichment — openstation sessions

Only after the tmux check, enrich with CLI metadata (run id, turns, cost, started/finished, exit reason):

openstation sessions <task-id>

This adds detail; it never overrides tmux. If tmux says RUNNING but openstation sessions says "complete" or returns nothing, trust tmux and flag the discrepancy.

2c. False-quiescence guard (CLI-down / UNKNOWN)

Explicitly distinguish three CLI outcomes — never conflate them:

CLI outcome	Meaning	Liveness verdict
Lists tasks/runs cleanly	Normal	Use as enrichment
Returns empty / no rows, exit 0	No state recorded	Defer to tmux
Errors (exit ≠ 0), ImportError, traceback, "command not found", missing module	CLI-down	UNKNOWN

If the CLI is broken (ImportError, ModuleNotFoundError, non-zero exit, unexpected traceback), do not conclude "quiescent / done" — record liveness as UNKNOWN / CLI-down, report it as a top-priority recommendation, and rely on tmux alone until the CLI is healthy again. (Background: an ImportError in the CLI once caused a watcher to read empty output as "run finished" and launch a duplicate run on a live task.)

3. Deep-read finished or ambiguous tasks

For tasks where tmux shows NOT RUNNING (or UNKNOWN with no backend evidence), defer the log-reading to /openstation.check <task-id> — do not duplicate its analysis here. Record the diagnosis it returns.

4. Reconcile with task status

Cross-check tmux liveness against task status:

Task status	tmux	Reading
in-progress	RUNNING	On track
in-progress	NOT RUNNING	Needs re-run or check (use openstation.check)
review	RUNNING	Verifier active
review	NOT RUNNING	Needs verification dispatch
any	UNKNOWN / CLI-down	Report as top recommendation; don't classify

4a. Async auto-commit caveat

The *→done auto-commit hook is asynchronous — it spawns a detached claude invocation that commits a beat after the status transition. Do not conclude "no commit / hook broken" from a single git log taken immediately after a transition. Before flagging a missing commit:

• Re-check git log after a short delay, or
• Look for a run_complete / commit event in openstation events list --task <id> / the event log, or
• Defer to /openstation.check which inspects the log.

Only after those still show nothing should you suspect a hook failure — and even then, report it, do not act on it.

4b. Dev↔verifier arbitration

When a developer's chat output claims success but reality disagrees (task is back in in-progress, the written Verification Report says FAIL, or a pytest spot-check is red), trust the artifacts, not the self-report. In order of authority:

1. Task status (openstation show <task>) — what the pipeline currently believes.
2. Verification Report in the task file — the verifier's recorded judgment, with evidence.
3. pytest spot-check — ground truth for code claims.
4. Agent's self-narration in the chat log — lowest authority; agents have falsely reported "all pass" with regressions live.

For the per-task deep read (which already follows this hierarchy), defer to /openstation.check <task-id>.

5. Present summary

Output a single table with all tasks and their status:

| ID   | Task                  | Status      | Agent     | Liveness    | Diagnosis            |
|------|-----------------------|-------------|-----------|-------------|----------------------|
| 0268 | project name/alias    | in-progress | developer | NOT RUNNING | Needs re-run         |
| 0278 | parent task review    | review      | developer | RUNNING     | Verifier in flight   |
| 0301 | …                     | in-progress | developer | UNKNOWN     | CLI-down — see notes |

Liveness values: RUNNING, NOT RUNNING, UNKNOWN.

Diagnosis labels:

• Healthy — on track, no action needed
• Running — agent session active in tmux
• Needs re-run — hit turn limit or failed, needs restart
• Needs verification — in review, no verify session running
• Rework — verification failed, back in progress
• Blocked — waiting on dependency or user input
• Stale — no activity, no sessions, needs triage
• CLI-down — control-plane CLI is broken; investigate before trusting any status

6. Recommend actions

After the table, list concrete next steps ordered by priority:

1. CLI-down / UNKNOWN entries — fix the control plane first; everything else is unreliable until then.
2. Tasks blocking other work.
3. Tasks in review needing verification.
4. Failed / stale tasks needing re-run.
5. New ready tasks to start.

Recommendations are suggestions only — the user decides what to dispatch. To act on these (dispatch, re-run, advance), invoke the separate openstation-orchestrate skill (see [[t0480-create-openstation-orchestrate-skill-active]]); this skill stops at recommendations.

Constraints

• Diagnose only. Do not run tasks, change status, create artifacts, or edit files. No openstation status, no openstation run, no openstation create, no Write/Edit. Present findings and let the user (or the orchestrator skill) decide.
• tmux is the primary liveness signal; openstation sessions is enrichment. Never let CLI-empty override tmux-alive.
• CLI-down ≠ done. Empty/erroring CLI output is reported as UNKNOWN, never as quiescent.
• Use /openstation.check for per-task deep log analysis — do not duplicate its logic here.
• Keep the summary concise — one line per task in the table.