multi-agent-collaboration
Skill6 starsChanged 18 days agoMITView on GitHub
Coordinate an engineering task across authorized agents with explicit ownership, bounded handoffs and evidence. Use when independent implementation, review or verification adds value; handle ordinary single-agent work directly.
6 other projects use a version of this.
Adopted by
Most recently taken up by
- rubenmarcus/agent-skillstheir own version, first seen Nov 1, 2026
- lzhs1995/multi-agent-collaborationtheir own version, first seen Oct 18, 2026
- mattstruble/skillstheir own version, first seen Jul 22, 2026
- varunk130/ai-workflow-playbookstheir own version, first seen May 22, 2026
- hajekim/agentic-design-patterns-extensiontheir own version, first seen Apr 1, 2026
- hajekim/agentic-design-patterns-skillstheir own version, first seen Apr 1, 2026
Other versions6 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 6
- hajekim/agentic-design-patterns-skills★ 4same name
- mattstruble/skills★ 2same name
- rubenmarcus/agent-skills★ 2same name
- varunk130/ai-workflow-playbooks★ 2same name
- hajekim/agentic-design-patterns-extension★ 1same name
- lzhs1995/multi-agent-collaboration★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository10 other files it gives its agents.
- AGENTS.mdAGENTS.md
- claim-ledgerSkill
- critic-reviewSkill
- distributed-orchestrationSkill
- engineering-governanceSkill
- engineering-planSkill
- execution-integritySkill
- literature-provenanceSkill
- technical-writingSkill
- worker-taskSkill
The file
We split this skill into the rules it gives an agent
1 rule. 0 are common, 1 is distinctive, and 0 are very specific to this project.
0
Common
Most of the 6 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Before delegation, state the outcome, acceptance criteria, dependencies, owned files, expected evidence and integration owner.
“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Choose the smallest team that resolves the task's uncertainty. Do not spawn agents, send cross-session messages or start watchers unless the user or host instructions authorize them. Existing authorization remains valid; this procedure adds no approval requirement.
Before delegation, state the outcome, acceptance criteria, dependencies, owned files, expected evidence and integration owner. Assign one current owner per thread. Give each worker only the context needed for its decision. Concurrent writers use separate clones or worktrees; never update code underneath a running job.
Use responsibilities as needed: H is the human project decision owner; O coordinates; F implements; P researches; C reviews; V independently verifies; W executes bounded commands; A provides assigned support. I remains a compatibility alias for F. Combine roles for simple work, but an author cannot supply independent verification. Under the governed profile only O/F own production code; V may write isolated verification scripts.
At handoff, identify the exact revision, commands, outputs, unresolved questions and next action. Record it in the project's task system; for the supplied templates, update discussion frontmatter owner and append a dated role entry. Acknowledge evidence actually read without repeating the conversation.
Return defects to the file owner with a reproducer and expected behavior. Settle ordinary implementation choices within authorized scope. Escalate only when a missing requirement, conflicting direction or consequential action actually needs the user's decision.
For a material scope/budget deadlock, present options once, set owner: H and status: blocked, and stop the affected branch until a trusted human decision reassigns it. Never simulate H or treat a role heading as approval. H overrides project consensus/procedure within host constraints; record criterion changes prospectively and keep prior evidence unchanged.
For adopted governed workflows, use the engineering-governance skill's relevant reference for milestone review, physical-node capability contracts, two-phase migration and worker fix quotas. Routine tasks need not load the entire profile. A node/role label is routing, not authorization or proof of capability.
The coordinator integrates, checks the final artifact and reports the result, validation and material limits. A successful tool invocation or claimed completion does not establish task success. Finish bounded work and exit; use an authorized external scheduler or file watcher for future work, with no idle model calls.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

