Menu
Use when creating, inspecting, updating, assigning, mentioning, or debugging Multica squads. Explains what squads are, squad/member fields, CLI commands, leader routing, issue assignment, comments, mentions, autopilot behavior, leader briefing, side effects, and product-gap handling.
Use when inspecting or debugging Multica runtimes, daemon task claiming, agent not running, workdir/session reuse, or repository checkout. Covers runtime online/offline state, daemon heartbeat/claim chain, task-scoped repo checkout, project repo context, local_directory caveats, and safe diagnostic commands.
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. Documents the verified mention contract: how a mention link is built from a real UUID, the four mention types and exactly what each one enqueues (agent → a run for that agent, squad → a run for the squad leader, member and issue → a rendered link with NO run), comment create/edit preview and suppression, the @all broadcast and how it suppresses the assignee's auto-trigger, and the silent no-op cases (a name where a UUID belongs, a bad/unknown UUID, an already-pending task, an archived agent, a private agent you cannot access). WHETHER to mention — loop avoidance, staying silent on acknowledgements — lives in the runtime brief's Mentions section, not here. This skill is the backend contract only, traced to server/internal/util/mention.go and server/internal/handler/comment.go.
Use when a user provides a skill URL, slug, or clear intent to import/install a specific skill into the current Multica workspace. Teaches the workspace import API/CLI path (POST /api/skills/import), the supported URL source families, --on-conflict fail|overwrite|rename|skip behavior and structured import results, additive agent binding vs replace-all, and the reserved SKILL.md supporting-file rule. Do not use it to decide which skill the user needs, and never treat an external local installer like npx skills add as the final Multica install.
Use when creating, updating, inspecting, triggering, or debugging Multica autopilots. Covers the full chain: schedule/webhook/manual trigger, create_issue vs run_only execution, agent/squad leader admission, runs, created issues/tasks, webhook URL rotation, and side-effect boundaries.
Use when creating, inspecting, or debugging a Multica agent through the `multica agent` CLI or `POST /api/agents` — what each field is, its persisted shape, whether it is metadata-only or consumed by the daemon at claim time, which inputs are validated/rejected, how custom_env secrets are gated, and how skill binding behaves. Not for assigning issues to existing agents or for runtime task prompts.
Use when creating, inspecting, updating, or debugging Multica projects and project resources. Covers durable project context, github_repo and local_directory resources, how resources affect future agent task context, when to bind repos, and when not to mutate resources.
| name | multica-squads |
| description | Use when creating, inspecting, updating, assigning, mentioning, or debugging Multica squads. Explains what squads are, squad/member fields, CLI commands, leader routing, issue assignment, comments, mentions, autopilot behavior, leader briefing, side effects, and product-gap handling. |
| user-invocable | false |
| allowed-tools | Bash(multica *) |
If debugging why a squad did or did not run, inspect first:
multica issue get <issue-id> --output json
multica squad get <squad-id> --output json
multica squad member list <squad-id> --output json
multica issue comment list <issue-id> --recent 20 --output json
If the command shape is unclear, check help instead of guessing:
multica squad --help
multica squad member --help
multica issue update --help
multica issue comment add --help
Do not assign, comment, mention, update, delete, or record squad activity just to test. These can mutate workspace state or trigger agent runs.
A Multica squad is a workspace routing and coordination object.
A squad is not an agent. It does not run work by itself. Current behavior:
squad-routed work runs through the squad's leader_id agent.
Important consequences:
instructions are leader briefing content, not member prompts.Squad commands:
multica squad list --output json
multica squad get <squad-id> --output json
multica squad create --name <name> --leader <agent-name-or-id> --output json
multica squad update <squad-id> --instructions "<leader coordination policy>" --output json
multica squad delete <squad-id>
Member commands:
multica squad member list <squad-id> --output json
multica squad member add <squad-id> --member-id <id> --type agent|member --role <role> --output json
multica squad member remove <squad-id> --member-id <id> --type agent|member
multica squad member set-role <squad-id> --member-id <id> --member-type agent|member --role <role> --output json
Squad leader evaluation command:
multica squad activity <issue-id> action|no_action|failed --reason "<why>" --output json
activity is a write: it records the leader's evaluation decision on an issue.
Use it only when acting as the squad leader after evaluating a trigger.
Issue/comment commands often needed with squads:
multica issue get <issue-id> --output json
multica issue update <issue-id> --help
multica issue comment list <issue-id> --output json
multica issue comment add <issue-id> --help
Prefer --output json for reads. Use --help before writes.
id — squad UUID.workspace_id — workspace the squad belongs to.name — display name; unique per workspace.description — human-facing metadata/display text. Do not assume runtime
prompt impact unless source proves a consumer.instructions — squad-level instructions added to the squad leader briefing.
They are not directly injected into every squad member.avatar_url — optional squad avatar URL.leader_id — agent ID of the squad leader; the runtime target for
squad-routed work.creator_id — creator of the squad.archived_at / archived_by — archive metadata. Archived squads are rejected
by assignment/autopilot routing paths.member_count — list response count of squad members.member_preview — list response preview of squad members.Use instructions for leader-facing coordination policy: squad responsibility,
delegation expectations, when to ask humans, and review/handoff rules. Do not
write it as if every member automatically receives it.
member_type — agent or member.member_id — ID of the agent or workspace member.role — roster role label. Current behavior: non-empty role appears in the
leader briefing roster. Do not assume it creates scheduling, permissions, or
routing behavior.Creating a squad requires leader_id. The leader must be a workspace agent.
Create/update does not reject an archived leader: the lookup only checks the
agent exists in the workspace. An archived leader fails closed later, at
routing/dispatch — assignment, autopilot admission, and the comment/mention
readiness gate all reject an archived leader before any task is enqueued.
On create, the backend attempts to add the leader as a squad member with role
leader. When updating leader_id, if the new leader is not already a member,
the backend adds the new leader as a squad member with role leader.
For squad leader tasks, Multica appends a squad leader briefing to the leader agent instructions. The briefing includes:
instructions is non-empty.Roster entries include member name, member type, mention markdown, and non-empty role. Archived agent members are skipped from the briefing roster.
Issues can be assigned to squads with:
assignee_type = "squad"
assignee_id = <squad-id>
Current behavior:
squad.leader_id;backlog does not immediately start work;backlog can trigger the leader;Assignment validation rejects a missing type/id pair, non-existent squad, archived squad, archived leader, and private leader when the actor cannot access it.
If an issue is assigned to a squad, a new comment can wake the squad leader. This is leader routing, not member fan-out.
Squad mention format:
[@Squad Name](mention://squad/<squad-id>)
Current behavior: resolve the squad, read leader_id, enqueue a leader task,
and use the current comment as the trigger comment. It does not enqueue every
squad member.
Autopilots can be assigned to squads. For assignee_type = "squad":
squad.leader_id;For create_issue autopilots, the created issue keeps assignee_type = "squad"
and assignee_id = <squad-id>, while the actual executing agent is the resolved
leader. For run_only autopilots, no issue is created; the task is created
directly for the resolved leader agent.
When the user says squad behavior is wrong, confusing, or disappointing, do not immediately assume code is broken and do not defend current behavior just because it exists. Classify first:
Explain the current source-backed behavior. If the behavior is technically correct but product-wise bad, say so and propose a scoped product/code change.
Do not silently change squad routing, member fan-out, leader briefing, autopilot behavior, or comment-trigger behavior without confirmation. These are product contract changes with side effects.
These actions can trigger agent work or mutate durable state:
leader_id;multica squad activity;Do not perform side-effecting actions as tests unless the user explicitly authorizes them.
leader_id, not every member.instructions are leader briefing content, not automatic member prompts.description is not proven runtime prompt content.role is roster context, not automatic scheduling.For source paths, tests, edge cases, and exact routing details, see:
references/squad-source-map.md