parallel-agent-delivery
Splits work across multiple agents or sessions running at once, keeping their surfaces disjoint so results merge cleanly. Use this when facing sever…
它会碰到什么
这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。
技能内容
Parallel agent delivery
Parallelism is a property of the work, not a preference. Establish it before dispatching.
When it is safe
All three must hold:
- Disjoint write surfaces — no two agents touch the same file. Not "unlikely to conflict";
provably disjoint.
- No sequential dependency — none needs another's output to start.
- Independently verifiable — each result can be judged on its own.
Fail any one and run sequentially. Two agents editing one file produces a merge conflict at best and
a silent lost update at worst.
Dispatching
Each agent gets a self-contained brief: the goal, its exclusive surface, the context it cannot see
for itself, and the shape of the answer expected. Agents share no memory — anything you leave out is
gone.
Ask for a structured return, the same shape from each, so results can be compared rather than
re-read.
Read-only fan-out is the easy case
Searching, auditing, and reviewing have no write surface at all, so they parallelize without risk.
Reach for parallelism here first and freely.
Integrating
- Review each result against its brief before merging any of them.
- Where two disagree on a shared fact, neither is authoritative — resolve it yourself.
- One agent returning nothing useful is a normal outcome, not a failure to retry blindly.
Never
- Split work to look faster when the steps are actually sequential.
- Let two agents write to one surface because "they probably won't collide."
- Merge a result you have not read.
想直接用这个技能?
本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。
它属于哪个仓库
plugins/technology/skills/parallel-agent-delivery/SKILL.md