Operating Multica

Your runtime brief owns the per-turn workflow: which issue you are on, when to
comment, what status to write. This skill owns the platform contracts behind
it — what a command actually does, what the server validates, and which writes
have consequences you cannot take back.

Read the invariants below, then open the reference(s) your task actually needs
— usually one, sometimes a few. Do not read them all.

Routing

Open what the task needs. A single-domain task usually needs one; a task that
crosses domains needs each domain it touches — creating a squad, assigning it an
issue, then writing a mention needs squads.md, issues.md and mentions.md,
and skipping one of those means acting on a contract you have not read.

What is never right is reading all eight because you are not sure. Each
reference states its own contracts in full and none depends on another, so
pick by domain and skip the rest.

Invariants

These hold across every reference and are not repeated there.

Read before you write. Start with the read-only commands the reference you
opened names — most domains have a list and a get that take --output json
and have no side effects. Run those before any mutation. When a command's shape
is unclear, multica <command> --help beats guessing at flags.

A name is not an id. Mention links, assignment, and every --*-id flag take
a real UUID from the matching list --output json. Never type a display name
where an id belongs, and never invent a UUID: an id that is well-formed but
belongs to nothing fails in ways that read like a permission error, which sends
you debugging access when the real problem was the id.

--output json writes to stdout; warnings and confirmations go to stderr.
Do not merge them (2>&1) into anything that parses the output — that makes a
write which SUCCEEDED look like it failed, and invites a duplicate retry.

Writes are real. Creating, updating, deleting, assigning, commenting,
mentioning, triggering and status changes mutate durable workspace state or
start agent runs that cost real budget. Never run one to see what happens. When
the user has not asked for a specific mutation, propose it instead of making it.

--no-start when you are only recording. Assignment and status writes
normally enqueue a run. When the work is already underway and the write merely
records ownership or progress, pass --no-start on EVERY command in that flow —
suppressing the assignment alone does not suppress a later status update.

Status is a category, not a literal. A workspace may define custom statuses
beyond the built-ins; each inherits its category's platform behavior in full,
and the runtime brief lists this workspace's catalog. Read status_category
rather than matching status against built-in names.

Comment reads stay bounded. Scan the threads cheaply
(--roots-only --summary --compact), then expand only what matters
(--thread <thread-id> --tail 30). Never one unbounded pull — a wide read on a
busy issue costs more than the answer is worth and still buries the reply
bodies where triggers and instructions actually live.

When behavior looks wrong

Classify before concluding: expected behavior, a configuration problem, a
product limitation, or an actual bug. Explain what the platform currently does
rather than defending it; when the behavior is technically correct but bad for
the user, say so and propose a scoped change.

Do not silently alter routing, briefing, or trigger behavior to make a complaint
go away. Those are product contracts, and changing one without confirmation
moves the surprise to somebody else.