Use when creating, updating, inspecting, triggering, or debugging a Multica autopilot (scheduled, webhook, or manual).
Use when creating, inspecting, or debugging a Multica agent definition via the `multica agent` CLI or POST /api/agents. Not for assigning issues to agents that already exist, and not for runtime task prompts.
Use when an issue comment needs to @mention someone — link to a person, trigger another agent, hand work to a squad, or broadcast with @all. Whether to mention at all is covered by the runtime brief, not here.
Use when creating, inspecting, updating, or debugging Multica projects and their resources (github_repo, local_directory).
Use when a Multica runtime or daemon misbehaves: agent not running, task not claimed, runtime offline, workdir or session reuse, repository checkout.
Use when asked to import or install a specific skill into this Multica workspace from a URL or slug. Not for choosing which skill the user needs; never treat a local installer such as `npx skills add` as the final install.
Use when creating, inspecting, updating, assigning to, or debugging a Multica squad, including how leader routing picks who runs.
Use when acting on a Multica issue beyond what the brief covers: PR linking vs close intent, reading a linked PR's real state, metadata keys, status-change side effects, sub-issue todo vs backlog.
Use when a product-authored kickoff starts or resumes Mika's interactive onboarding for a Multica workspace. The opening greeting has already been sent; carry the member from their first message to one real, confirmed, issue-based execution and a clear handoff.
How this team handles a production incident issue — what to establish before proposing a fix, and what an agent may and may not do on its own.