mirror of
https://gh-proxy.org/https://github.com/klinsmaya/multica.git
synced 2026-11-09 09:56:47 +08:00
d276991c60
* refactor(issues): remove the assignment handoff note (MUL-6743) Usage data puts the handoff note at 0.2% of assignments, so the box occupied the confirm dialog's centre for the other 99.8% and bought them nothing. Removing it takes the whole feature with it: the note input and its runtime version gate, the `handoff_note` write field on PATCH/batch issue updates, the task column write, and the daemon's opening-prompt + issue_context.md handoff sections. The confirm dialog itself stays — it still names who is about to run and still offers "Don't start yet" (suppress_run). The `*WithHandoff` enqueue methods only ever varied by that note, so they become `EnqueueTaskForIssueByActor` / `EnqueueTaskForSquadLeaderByActor` — the actor-carrying variants autopilot already called with an empty note. `preview-trigger` drops `handoff_supported`, which nothing read after the gate moved client-side. `agent_task_queue.handoff_note` is deliberately left in place: it holds historical rows and this is the expand half of an expand-contract pair. Nothing reads or writes it now, so a follow-up migration can drop it once no deployed binary selects it. Co-authored-by: multica-agent <[email protected]> * docs(issues): reshoot the assignment confirm dialog (MUL-6743) The asset still showed the handoff note box the surrounding prose no longer describes. Recaptured from the app at the same 600x450 frame; the confirm button now carries the send-chord keycaps it has shipped with since MUL-5694. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Lambda <[email protected]> Co-authored-by: multica-agent <[email protected]>
89 lines
5.6 KiB
Plaintext
89 lines
5.6 KiB
Plaintext
---
|
|
title: Assign issues to agents
|
|
description: Put an agent in charge of an issue and decide whether it starts working right away.
|
|
---
|
|
|
|
import { Callout } from "fumadocs-ui/components/callout";
|
|
|
|
When a piece of work needs an agent to own it over time, assign the issue to it. The agent reads the issue's description and discussion, does the work with its own configuration and skills, and writes progress and results back to the same issue.
|
|
|
|
When you only need the agent to handle one specific request without changing ownership, use an [@-mention in a comment](/mentioning-agents) instead.
|
|
|
|
## Assign and start a run
|
|
|
|
1. Open an issue and click **Assignee**.
|
|
2. Pick an agent or a squad.
|
|
3. Review the agent about to start in the confirmation dialog, then choose **Start**.
|
|
|
|
|
|
|
|
Everything the agent should know about this work belongs in the issue itself — its description, its discussion, or the project description and agent instructions.
|
|
|
|
When you assign to a squad, the squad becomes the issue's assignee and the squad leader starts first. It decides whether to hand work to other members, following how the squad operates.
|
|
|
|
## Execution after assignment
|
|
|
|
Multica creates a [task](/tasks) for the agent. Once an online runtime claims the task, it invokes the AI coding tool on that machine; progress, comments, and results then appear in the issue.
|
|
|
|
If the runtime is temporarily offline, the task waits in the queue; a task is bound to its runtime and never moves to another machine.
|
|
|
|
While executing, the agent can:
|
|
|
|
- read the issue's description, fields, and comments;
|
|
- use its bound skills, MCP servers, and project context;
|
|
- read files, run commands, and make changes in its local working directory;
|
|
- post comments and update the issue status.
|
|
|
|
What it can actually do is still limited by the agent's configuration, the runtime environment, and your permission to run it.
|
|
|
|
During the run, the agent manages the issue's status by judging what its work changes: starting on the issue's own ask moves it to `in_progress` right away, delivery moves it to `in_review`, work continuing beyond the turn keeps it `in_progress`, and consultation or discussion leaves the status untouched — these actions appear under the agent's identity in the timeline. Task lifecycle and issue status are separate: a task completing does not by itself change the issue status.
|
|
|
|
When the assignee is a [squad](/squads), the same rule applies: Multica enqueues the leader, and dispatching members is not delivery — a dispatch turn leaves the parent issue `in_progress`, and the leader only moves it to `in_review` once the overall goal is met.
|
|
|
|
## Assign without starting
|
|
|
|
**Don't start yet** in the confirmation dialog saves the assignee without creating a task for this run. Use it to settle ownership first and start once the background or dependencies are ready.
|
|
|
|
`backlog` doesn't start a run on assignment either. Execution only follows after you move the issue out of `backlog`, or ask the assignee for something in a follow-up comment.
|
|
|
|
When the issue already has an agent or squad owner, moving it out of `backlog` opens the same dialog: that status change is what starts the run, so it offers the same **Don't start yet**, which moves the issue without waking the agent. The dialog appears for every target outside the `backlog`, `done`, and `cancelled` categories.
|
|
|
|
Only the `backlog` category works this way, and a [custom status](/issues#custom-statuses) in that category behaves identically. Issues already in `done` or `cancelled` still start a run immediately when assigned or reassigned to an agent.
|
|
|
|
## Assignment permissions
|
|
|
|
Whether you can assign an agent is decided by its Access:
|
|
|
|
- **Only me**: only the agent's owner can run it;
|
|
- **Specific people**: the owner and the listed members can run it;
|
|
- **Entire workspace**: every workspace member can run it.
|
|
|
|
Workspace owners and admins can manage agents, but being able to see one doesn't mean being able to run it. The assignee picker disables agents you can't run. See [Agents](/agents#permissions-and-access) for the full rules.
|
|
|
|
## Change or remove the assignee
|
|
|
|
Switching the assignee to another agent starts a new run for the new assignee; picking a member only changes the assignee and doesn't invoke any AI coding tool. Removing the assignee doesn't create a task either.
|
|
|
|
<Callout type="warning">
|
|
Changing the assignee, unassigning, or changing the issue status doesn't stop a run that has already started. To interrupt it, stop the corresponding task in the execution log.
|
|
</Callout>
|
|
|
|
## Use the CLI
|
|
|
|
```bash
|
|
multica issue assign MUL-42 --to "Agent name"
|
|
multica issue assign MUL-42 --to-id <agent-uuid> --no-start
|
|
multica issue status MUL-42 in_progress --no-start
|
|
multica issue assign MUL-42 --unassign
|
|
```
|
|
|
|
In scripts, use `--to-id <uuid>` to avoid matching the wrong object with the same name. Look up UUIDs with `multica agent list --output json` or `multica workspace member list --output json`.
|
|
|
|
Use `--no-start` when the assignment should record ownership without creating a new task — for example, when the same agent is already handling the issue from another run. The same flag is available on `issue update` and `issue status`. If an ownership-only flow changes both assignment and status, pass it to both commands; suppressing the assignment does not suppress a later status-triggered run.
|
|
|
|
## Next steps
|
|
|
|
- [@-mention agents in comments](/mentioning-agents) — handle a new question without changing the assignee.
|
|
- [Tasks](/tasks) — queueing, retry, and stop rules.
|
|
- [Squads](/squads) — have a leader coordinate multiple agents.
|