ainb-fleet:standup
Show fleet status — every claude session running on the host, merged across ainb + claude-peers broker + background jobs. Use when you need to enumerate sessions before composing an action, see which sessions have a peer registered (broker-routable) vs tmux-only, check the `summary` of each session, or pipe the list into jq for filtering. Default output: text table. Pass --format json for LLM consumption.
Best use case
ainb-fleet:standup is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Show fleet status — every claude session running on the host, merged across ainb + claude-peers broker + background jobs. Use when you need to enumerate sessions before composing an action, see which sessions have a peer registered (broker-routable) vs tmux-only, check the `summary` of each session, or pipe the list into jq for filtering. Default output: text table. Pass --format json for LLM consumption.
Teams using ainb-fleet:standup should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/standup/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How ainb-fleet:standup Compares
| Feature / Agent | ainb-fleet:standup | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Show fleet status — every claude session running on the host, merged across ainb + claude-peers broker + background jobs. Use when you need to enumerate sessions before composing an action, see which sessions have a peer registered (broker-routable) vs tmux-only, check the `summary` of each session, or pipe the list into jq for filtering. Default output: text table. Pass --format json for LLM consumption.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# ainb fleet:standup
List every claude session across the host. Three sources merged + deduped
by cwd.
## Run
```bash
ainb fleet standup # text table (default)
ainb fleet --format json standup # JSON for piping
```
## Output fields (JSON)
| field | meaning |
|---|---|
| `id` | session id (peer id preferred, else ainb session_id, else bg job id) |
| `cwd` | working dir — primary dedupe key |
| `pid` | OS pid (when known — peers + bg jobs publish; ainb does not) |
| `tmux_session` | tmux session name if running in tmux |
| `workspace_name` | ainb workspace name |
| `worktree_path` | ainb worktree path |
| `peer_id` | broker peer id (if registered) |
| `sources` | array — subset of `["ainb","peers","jobs"]` |
| `summary` | peer-published summary (may start with `WAITING:` to flag block) |
| `last_seen_ms` | unix ms of last activity any source observed |
## Composition patterns
**Just names:**
```bash
ainb fleet --format json standup | jq -r '.[].tmux_session // .workspace_name'
```
**Sessions in a specific repo:**
```bash
ainb fleet --format json standup | jq '.[] | select(.cwd | contains("shotclubhouse"))'
```
**Only sessions with peer registration (broker-routable):**
```bash
ainb fleet --format json standup | jq '.[] | select(.peer_id != null)'
```
**Group by source mix:**
```bash
ainb fleet --format json standup \
| jq -r 'group_by(.sources | sort | join(",")) | .[] | "\(.[0].sources | sort | join(",")): \(length)"'
```
## Auto-chain to `/ainb-fleet:needs`
After rendering standup, **scan the result for sessions whose `summary`
contains `AskUserQuestion`** (literal string — the JSONL-synthesised
summary surfaces this when the last assistant turn fired the tool).
If ANY such session exists, the standup MUST NOT stop at the standup
table. Immediately:
1. Tell Stevie explicitly:
```
N session(s) blocked on AskUserQuestion — firing `/ainb-fleet:needs`
to surface the questions + answer them in one batch.
```
2. Invoke the `ainb-fleet:needs` skill (via the Skill tool) OR run
`ainb --format json fleet needs` directly and render the Jarvis HUD
per the `ainb-fleet:needs` SKILL.md. No second Stevie-typed slash
command required — the handover is automatic.
Detection one-liner:
```bash
ainb --format json fleet standup \
| jq -r '[.[] | select(.summary // "" | contains("AskUserQuestion"))] | length'
```
If 0 → skip the chain, standup is the final word.
If >0 → chain immediately.
**Rationale:** standup is a snapshot; the moment it reveals an
answerable question, the fleet's center control panel (`needs`)
already knows how to extract the structured options + route the
answer back. Don't make Stevie type another slash command for a
mechanically inevitable next step.
## Performance
Sub-100ms cold start. Reads broker SQLite directly + shells out to `ainb list`
once. Safe to call frequently.Related Skills
test-ainb
Run tests for the ainb (agents-in-a-box) Rust workspace via a 5-layer strategy — unit, insta snapshot, mock-plugin compositing, real-plugin spawn, vhs recording. Wraps cargo + insta + vhs into one CLI. Use when Stevie says "/test-ainb", "test ainb", "run ainb tests", "snapshot <component>", "regenerate vhs tapes", or any phrasing about validating ainb test layers. The skill autodetects which ainb-tui worktree the cwd sits in and dispatches to scripts/run.sh.
ainb-fleet:sequence
Ordered multi-step prompts to fleet targets, ack-gated between steps via JSONL assistant-turn-end detection. Use for cycles like disconnect→reconnect→verify, or any flow where step N+1 requires step N to have completed first. The skill BLOCKS until each target's transcript shows the next assistant turn finishing OR per-step timeout fires (default 300s).
ainb-fleet:needs
Center control panel — enumerate every claude session that is blocked waiting on something: a user answer (AskUserQuestion fired), an API error retry, an idle assistant turn-end with no follow-up, or an explicit WAITING: marker. Returns rich JSON with signal kind + context per session. Use this when you've stepped away from the fleet and want one place to see everything that wants your attention and answer it.
ainb-fleet:fleet-needs
Workflow-backed Jarvis control panel. Runs the deterministic `hangar` workflow with verb=needs (discover → enrich → prioritize), renders the Jarvis HUD from its render-ready cards, fires AskUserQuestion per blocked session, and routes each answer back via tmux send-keys (broker fallback only). Requires the workflow gate (CLAUDE_CODE_WORKFLOWS=1). If the gate is off, fall back to the prompt-driven `/ainb-fleet:needs` skill.
ainb-fleet:daemon
Long-running watcher that scans every claude session every 5s and auto-sends `continue` to any session whose recent tmux pane buffer matches a known API-error regex (rate_limited, overloaded_error, internal_server_error, request_timeout, socket_hang_up, fetch_failed, ECONNRESET). Use this when you want unattended recovery from transient API failures across the fleet.
ainb-fleet:broadcast
Fan out a single prompt to selected claude sessions across the fleet. Use when you need to apply the same instruction (e.g. `/clear`, `git pull`, `remote-control disconnect`) to many sessions at once. Routing: peers-first (broker HTTP) when peer registered, tmux send-keys fallback otherwise. Refuses to run without an explicit targeting flag (--all, --filter <regex>, or --cwd <substring>) — no implicit fan-out.
ainb-fleet
Fleet orchestration overview — the `ainb fleet ...` Rust subcommand namespace for driving every claude session on the host. Routes to one of five sub-skills (standup / broadcast / sequence / needs / daemon). Invoke this for an at-a-glance map of what fleet can do; reach for the specific sub-skill for the verb you want.
workflow
Guide through structured delivery workflow with plan, implement, validate phases
webapp-testing
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
validate
Verify implementation against specifications
ui-ux-pro-max
UI/UX design intelligence. 67 styles, 96 palettes, 57 font pairings, 25 charts, 13 stacks (React, Next.js, Vue, Svelte, Astro, Nuxt, SwiftUI, React Native, Flutter, Tailwind, shadcn/ui, Jetpack Compose). Actions: plan, build, create, design, implement, review, fix, improve, optimize, enhance, refactor, check UI/UX code. Projects: website, landing page, dashboard, admin panel, e-commerce, SaaS, portfolio, blog, mobile app, .html, .tsx, .vue, .svelte. Elements: button, modal, navbar, sidebar, card, table, form, chart. Styles: glassmorphism, claymorphism, minimalism, brutalism, neumorphism, bento grid, dark mode, responsive, skeuomorphism, flat design. Topics: color palette, accessibility, animation, layout, typography, font pairing, spacing, hover, shadow, gradient.
tui-style-guide
TUI style guide for consistent terminal interface design