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.

Status keys identify workflow states; categories describe lifecycle only. Custom statuses do not inherit built-in automation behavior. For status side effects and API field meanings, read references/issues.md.

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. One exception, and it is narrower than it looks: when the per-turn message hands you a --since delta read, that read is the bounded scan — the server already computed which comments are new, so running it returns exactly those and nothing else.

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.