super-board — autonomous GitHub Project pipeline

Five verbs

Verb	Where	What it does
super-board onboard	interactive	one-time setup wizard; writes .claude/super-board/configs/<slug>.json
super-board lint	interactive	walks active-pipeline issues, flags vague ACs, runs pre-flight readiness
super-board status	interactive (read-only)	snapshot of active config, column counts, in-flight workers
super-board run	in-session (default)	the autonomous loop: waves of the super-board-wave dynamic workflow, run from this session (worker_backend: "claude-p" opts into the legacy headless runner .claude/bin/super-board-run.sh). Also the resume command — state lives on the board, not in process memory. Accepts a model-tier flag: --low (haiku/sonnet/opus ladder), default = medium (sonnet/opus/session), --high (opus for every card). `--codex [--low
super-board stop	interactive	graceful shutdown: posts "stopped mid-flight" comments on every in-flight issue + PR, releases assignee mutexes, kills workers + dispatcher. Next super-board run resumes.

If invoked with no verb, ask which one.

In Codex the skill is not a slash command: it is $super-board <verb>, found in .agents/skills/.

Routing

If user says	Load
super-board onboard ...	references/onboard.md
super-board lint ...	references/lint.md
super-board status ...	references/status.md
super-board run --codex[=<model>] ..., or any run from a host with no Workflow tool (overrides any configured backend)	references/run-workflow.md → "Codex runs"
super-board run ... (default — worker_backend unset or "workflow")	references/run-workflow.md (lane lifecycles still come from references/run.md)
super-board run ... with config worker_backend: "claude-p" (legacy, explicit opt-in)	references/run.md
super-board stop ... / "stop the run" / "pause the loop" / "kill super-board"	references/stop.md
"resume" / "pick up where I left off" / "restart after stop"	references/stop.md (resume = run; no separate verb)
Anything about Blocked exits, 🙋 needs you, or dropping a card	references/block-template.md
Config structure questions	references/config-schema.json
Worker gh-call discipline / rate-limit recovery	references/rate-limit-etiquette.md (+ scripts/super-board-gh-guard.sh)

Orchestrator vs worker — the cardinal rule

super-board is an autonomous trader. The interactive Claude session that invokes any of the five verbs is an orchestrator, not a worker. The orchestrator:

• Validates preconditions, then dispatches per the config's worker_backend: "workflow" (default) → stay in-session and run the wave loop in references/run-workflow.md (launch workflow, reconcile, repeat); "claude-p" (legacy, explicit opt-in only) → nohup .claude/bin/super-board-run.sh, report PID + log path, exit. Explicit --codex overrides either backend with headless Codex waves; so does a host with no Workflow tool, or bash .claude/bin/super-board-host.sh printing codex. The orchestrator never does product work itself.
• Delegates all build / QA / review work to workers — headless claude -p (claude-p backend), workflow lane agents (workflow backend), or headless codex exec (explicit --codex).
• Must NOT do product work itself, must NOT patch the dispatcher mid-run, must NOT wait for workers, must NOT hold context for multi-card progress.

If anything goes wrong during a run, the orchestrator captures the symptom and reports back — it does not silently expand the task into a fix. See references/run.md "Orchestrator delegation contract" for the full rule.