Documentation
¶
Overview ¶
Package multiagent implements specialist sub-agent task execution. Each task is processed through three sequential passes:
- Architect — designs the approach
- Coder — implements the design
- Reviewer — critiques the implementation
Index ¶
Constants ¶
const ArchitectSystemPrompt = `` /* 767-byte string literal not displayed */
ArchitectSystemPrompt is the system prompt for the architect sub-agent. The architect designs the technical approach without writing implementation code.
const CoderSystemPrompt = `` /* 594-byte string literal not displayed */
CoderSystemPrompt is the system prompt for the coder sub-agent. The coder receives the architect's design and produces the full implementation.
const ReviewerSystemPrompt = `` /* 890-byte string literal not displayed */
ReviewerSystemPrompt is the system prompt for the reviewer sub-agent. The reviewer critiques the implementation and confirms or overrides the signal.
Variables ¶
This section is empty.
Functions ¶
Types ¶
type Brief ¶ added in v0.0.5
type Brief struct {
Task *pm.Task
Goal string
Instructions string
ProjectContext string
// Notice is a prompt section every pass carries — the review gate's,
// while the project's gate is on (Task 20365), so a sub-agent that pushes
// knows the push is held and must not be routed around.
Notice string
}
Brief is what every pass is told about the task.
type Result ¶
type Result struct {
ArchitectOutput string
CoderOutput string
ReviewerOutput string
// Signal is the final task signal extracted from the reviewer's output,
// falling back to the coder's signal. One of TASK_DONE, TASK_FAILED, TASK_SKIPPED.
Signal pm.TaskStatus
ArtifactDir string // relative path of the per-task artifact directory
// InputTokens, OutputTokens and ThinkingTokens are summed over the passes.
InputTokens int
OutputTokens int
ThinkingTokens int
// Background is the background work the passes left behind (Task 20205):
// the first pass whose work did not drain, else the last that left any.
// The orchestrator judges the task by it exactly as it judges a single
// agent's — otherwise a coder that started a job and walked away would
// have its "waiting" record cleared and its result accepted.
Background *provider.BackgroundActivity
// SessionID is the coder's conversation, where a provider reports one.
// The coder made the changes, so a review gate that sends the task back
// with findings resumes that conversation.
SessionID string
}
Result holds the outputs of all three sub-agent passes plus the final signal.
func RunTask ¶
func RunTask(ctx context.Context, prov provider.Provider, opts provider.Options, brief Brief) (*Result, error)
RunTask executes a single PM task through the three-pass multi-agent pipeline (architect → coder → reviewer) and returns the combined result.
Each pass uses its own system prompt from roles.go. The coder receives the architect's output as context, and the reviewer receives both prior outputs. Sub-agent responses are stored as artifact files under .cloop/tasks/<id>-<slug>-multiagent/{architect,coder,reviewer}.txt.
opts are the options a single-agent run of the task would get — model, effort, thinking settings, working directory, the environment that holds pushes for the review gate, the background-wait notice — and every pass runs with them, setting only its own system prompt (Task 20365). Before that, the pipeline built options of its own from a model and a timeout, so a gated project's sub-agents pushed straight past the gate, ran in the process's working directory rather than the task's, and were cut off at ten minutes when no step timeout was set, against Task 20148's rule that a task has no time limit unless one is configured. A zero opts.Timeout still means none.
Two stability bounds protect the pipeline:
- ctx.Err() is checked between passes so a cancelled parent (Ctrl+C translated to cancel, or the orchestrator's per-task watchdog firing) bails before the next pass instead of running the full architect→coder →reviewer chain — each pass can run for many minutes, so an unbounded pipeline ignores cancellation for tens of minutes after the user asked it to stop.
- Each prov.Complete call is wrapped in panic recovery so a panic inside a provider implementation (e.g. nil-pointer in a third-party SDK, malformed JSON deref) becomes a returned error instead of taking down the orchestrator and losing every other queued task.
Source Files