ramarahmanda

captain-delegate

Use when implementation work is approved and ready to be executed — the captain briefs subagents, supervises them, unblocks or escalates when they stall, and validates results against the knowledge graph before accepting. The captain never writes feature code itself.

captain-inject

Use when the user STATES A FACT about the system or tells the captain to remember/learn something — "update your knowledge", "remember this", "we dropped X for Y", "the outage was caused by Z", environment URLs, team contacts, deployment flows, tribal knowledge, corrections to what the Captain believes. Validates intent, connects to existing entities, persists to the tsubasa graph.

captain-onboard

Use when the user wants to CREATE a captain here — "set up tsubasa", "be my captain", "init a captain for this repo/workspace", "I want a captain-<name>" — or to UPDATE an existing one after updating the CLI ("I upgraded tsubasa, now what"). Scaffolds .tsubasa/, auto-detects knowledge sources, runs the first ingest, and reports what the captain learned; runs `tsubasa upgrade` instead when a captain already exists here.

captain-recall

Use when the user asks WHY or WHAT-HAPPENED questions about this system — historical decisions, past incidents, why code/config is shaped a certain way, where something is deployed, who decided what, or the state of work in flight. Queries the tsubasa knowledge graph for cited answers.

captain-capture

Use at DECISION MOMENTS — the user accepts a proposed design/approach after discussion, approves a plan, or concludes "let's do X". Persists the decision as an ADR + event in the tsubasa knowledge graph so it is never lost.