Skip to main content

multi-agent:一任务一工作树

在协调者整合下,把独立任务拆给多个代理,每个任务自有分支、工作树、提示文件与验收检查。

来源信息

仓库
MasihMoafi/skills
最近来源活动
2026年11月3日 08:35
检测到的 SKILL.md 语言
英语
星标
8
Forks
0

用途

要派多个代理或给另一代理写简报时使用;仅对互不依赖的任务并行。

操作说明

协调者维护任务清单 → 每任务建工作树与 WORKER_PROMPT.md(允许文件、禁区、验收) → 工人回报摘要、文件、检查与风险 → 一次合并一个分支并在合并树上重跑验收。

限制

同一接口或仍在变动的共享契约上不要并行写。只读审阅者可共享树,前提是禁止写入。

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
name
multi-agent
description
Split work across agents without losing control, with one worktree and prompt file per task and a coordinator who integrates. Use when dispatching more than one agent or writing a brief for another agent.
# Multi-agent dispatch Run agents in parallel only on independent tasks: two agents editing one interface produce two plausible diffs that cannot both be right. The unit is **one task, one branch, one worktree, one prompt file, one acceptance check**. Read-only reviewers may share a tree if writes are forbidden. ## Roles - **Coordinator:** owns the task list, architecture, order, integration and the verification label. Creates and removes worktrees and picks each task's model. Never lets a worker redefine the product. - **Worker:** does one bounded task in its own worktree and returns changed files, checks run, evidence and risks. Touches nothing outside its scope. - **User:** decides product behavior and accepts the result. ## Setup Use the worktree location and base the project names; do not assume the default branch holds the work the task needs. `git worktree add "$path" -b "$branch" "$base"`. Put the prompt in `WORKER_PROMPT.md` at that worktree's root, marked "Do not commit it". Remove the worktree only after its branch is integrated or abandoned. ## The prompt contract A missing or contradictory field is a reason to challenge the task, not to start. ```text Task ID: Desired user-visible behavior: what a person sees, not an implementation Why it is needed: Allowed files: a real list, plus a rule for the ragged edge Forbidden scope: the specific temptations (adjacent refactors, coordinator files, publishing) Dependencies already verified: Acceptance test: numbered; each item can fail Required checks: build flags, disk limits, commands never to run, what runs on CI Return: summary, changed files, verification, risks, commit hash. ``` Put every binding constraint in the prompt: what cannot be verified here and the ceiling of what CI can prove; disk-heavy build flags; "report, do not patch" for observation tasks. When a null result is legitimate, say so ("if the only lever costs more than it buys, report that and close"), so the worker does not ship churn. ## Before dispatching Serialize two tasks when their allowed files intersect, when they touch a shared runtime, protocol or permission contract still being reshaped, when they would exhaust one disk or CPU, or when they install to the same path or app home. ## Verification and integration Label each result `user-verified` (the only "done"), `agent-verified`, or `unverifiable here` (name what would be needed); the ranking is in the [spec skill](../spec/SKILL.md#4-verify). Integrate one branch at a time and rerun the acceptance test on the merged tree.
在 GitHub 查看