Playbooks — standard operations, copy-paste ready

Verified against multica CLI v0.4.2. Every listing below survives the two CLI traps: pages are capped at 100 (--offset + has_more) and descriptions may contain raw control characters that break json.loads — sanitize with re.sub(r'[\x00-\x1f]',' ', out) first (see BOOTSTRAP §8).

You are the console — map the user's phrases to actions

The user talks to you instead of dashboards; translate and execute, then report in their language. Bulk helpers live in scripts/.

• "what's the status?" — bash scripts/status.sh + daemon status --output json; summarize: working/waiting/limit-stuck (+ reset time from scripts/health.sh)
• "resume / continue everyone" — multica daemon start (requeues interrupted) + bash scripts/resume.sh
• "everything stalled, fix it" — triage below → usually limit: report reset time; after reset bash scripts/resume.sh --revive-cancelled
• "start feature X" — find the issue, issue assign … --to "<Conductor>", confirm the spend
• "pause everything" — multica daemon stop
• "add a <role>" — ./roles template + invariants (guide, find-skills)
• "what did agent N do?" — issue runs → issue run-messages <task-id>, summarize

Start a feature (the human's one move)

multica issue assign <feature-id> --to "<Conductor>"   # conductor decomposes & drives
# or, single-discipline feature straight to its squad:
multica issue assign <feature-id> --to "<Squad>"

Assignment = a run that spends budget. Everything after this is the conveyor's job.

See what's going on

multica daemon status --output json     # status + active_task_count (running ≠ working!)
multica issue get <id> --output json    # status, assignee
multica issue children <feature-id>     # sub-issues grouped by stage
multica issue runs <id> --output json   # execution history; latest run's status/error
multica issue run-messages <task-id>    # transcript of one run
multica issue usage <id>                # token spend per issue

Health triage: daemon running + active_task_count 0 + issues in_progress = stalled — check the latest run's error for agent_error / "session limit".

Recover after a session limit

multica issue rerun <id>                # per issue — same as the UI "Retry task"

Bulk: rerun every assigned in_progress/in_review issue (never todo/backlog — they wait on the stage barrier). Retrying before the reset time fails again; the reset is in the failed run's error ("resets HH:MM").

Talk to an agent on a task

multica issue comment add <id> --content "…[@Name](mention://agent/<uuid>)…"

The @-mention triggers that agent with the issue as context. Plain comments (no mention) wake the squad leader instead.

Add an agent mid-project

multica agent create --name "<Role>" --model <model-id> --runtime-id <rt> \
  --visibility workspace --instructions "<role prompt>" --output json
multica agent skills add <agent-id> --skill-ids <guide-id>,<find-skills-id>   # invariants!
multica squad member add <squad-id> --member-id <agent-id> --type agent        # if squad exists
multica squad update <squad-id> --instructions "<updated routing map>"

New discipline entirely? ≥2 members → create a squad with a routing leader; solo → lone agent, assign work directly.

Give an agent a capability (skill)

multica skill import --url github.com/<owner>/<repo>/tree/main/<skill-folder> --on-conflict skip
multica agent skills add <agent-id> --skill-ids <skill-id>

URL must point at the folder containing ./the-skill — the repo root 502s (the CLI mislabels it "service temporarily unavailable"; --debug shows the truth).

Pause / resume the whole team

multica daemon stop     # agents stop picking up tasks (global, per machine)
multica daemon start    # interrupted issue-tasks are requeued automatically

There is no per-project pause — the daemon is machine-wide.

Retire or reshape

multica issue status <id> cancelled     # ALWAYS add a "Cancel reason: …" comment first
multica issue update <id> --project <other-pid>          # move between projects
multica issue update <sub-id> --stage 2 --assignee "<X>" # restage / reassign
multica agent update <agent-id> --model <model-id>       # retier a model (UUID, not name)
multica squad update <squad-id> --leader "<Agent>"       # change the router

Scale capacity when limits keep firing

In order of leverage: retier models (top model for the core only) → spread agents across runtimes (multica runtime list; a second account = a second runtime) → larger plan → API runtime (pay-per-token, no session cap) → lower concurrency (--max-concurrent-tasks, MULTICA_DAEMON_MAX_CONCURRENT_TASKS).

Connect an external service to agents

# MCP (e.g. Figma): json {"mcpServers":{...}} in a 0600 file
multica agent update <agent-id> --mcp-config-file /path/figma-mcp.json
# plain API key (e.g. image-gen)
multica agent update <agent-id> --custom-env-file /path/env.json

Exists → connect; missing → create it first (BOOTSTRAP §12). Destructive/outward actions still require the user's yes.

Kick off discovery from one sentence

User drops an idea → clarify minimally → create a discovery issue → assign to the conductor with the discovery checklist (AS IS → TO BE → audience → competitors → risks → metrics → testing). The conductor researches, brainstorms with the team, and returns a proposal for approval — only then specs and stages.

Switch operating mode

Presets manual ⇄ auto (or per-dial: flow, hiring). Update the mode section in the guide skill + the conductor's and Mops-in-Multica's instructions — no daemon restart, nothing running is killed. Flow switches take effect at the next feature boundary (auto→manual parks the conveyor after the in-flight feature archives); hiring switches apply to future hires at once, and Mops in Multica reports hires made while in auto.