ainb-fleetfleet-needslisted

# ainb fleet:fleet-needs — workflow-backed cockpit The session "face" of the sensor-fusion hybrid. The deterministic brain is the `hangar` workflow (verb=needs); this skill renders its output and handles the irreducibly-interactive last mile (HUD + AskUserQuestion + routing). ## `fleet-needs` vs `needs` — which skill? > **This skill (`fleet-needs`) is the workflow-backed "Jarvis" cockpit.** It > runs the deterministic `hangar` workflow (verb=needs) for the batched > discover→enrich→prioritize chain, and adds **key-route ASK answering** > (presses the target's picker keys via tmux for an already-open > AskUserQuestion). It **requires the workflow gate `CLAUDE_CODE_WORKFLOWS=1`**. > > **[`/ainb-fleet:needs`](../needs/SKILL.md) is the plain control panel** — > prompt-driven, no gate, works everywhere. It is the canonical fallback: if the > gate is off, this skill **stops and hands off to `needs`** (see Step 0). > > Both read the same underlying `ainb fleet needs` data — same panel content, > same materialized `current_state` source (below). The difference is purely the > machinery: workflow-batched cockpit (here) vs plain prompt panel (`needs`). ``` SESSION (this skill) ──Workflow({name:'ainb-fleet:jarvis', args:{verb:'needs'}})──▶ brain render HUD ◀──{banner,cards,asks}──────────────────────────────────────────┘ AskUserQuestion per ask ──answer──▶ tmux send-keys (write leg) ``` ## Read/write split — architectural principle | Direction | Channel | Why | |----------