orchestrate-engineering
Skill15 starsChanged 3 months agoMITView on GitHub
Coordinate complex engineering work across bounded subagents while protecting the main context, preventing edit conflicts, and measuring whether delegation was worthwhile. Use when the user asks to delegate, parallelize, orchestrate, use subagents, fan out a review, or handle a large task with independent workstreams; do not use for small, tightly coupled, or inherently sequential tasks.
In this repository10 other files it gives its agents.
- AGENTS.mdAGENTS.md
- examples/AGENTS.mdAGENTS.md
- build-backendSkill
- build-frontendSkill
- engineering-loopSkill
- maintain-codex-wikiSkill
- operate-devopsSkill
- review-codeSkill
- review-securitySkill
- test-softwareSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
19 rules. About 0 are common, 19 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈19
Distinctive · estimate
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 10
Read applicable AGENTS.md files and the task’s acceptance criteria.
- Distinctive: line 12
Use one agent when the task is small, tightly coupled, or dominated by shared-file edits.
- Distinctive: line 20
Use fan-out/fan-in for independent read-only research, review, triage, or log analysis.
- Distinctive: line 21
Use a pipeline when exploration, planning, implementation, testing, and review depend on prior outputs.
- Distinctive: line 22
Use partitioned implementation only after shared interfaces are stable and each worker owns exclusive files or subsystems.
- Distinctive: line 24
Read references/context-budget.md when selecting a topology, preparing worker context, defining summaries, or evaluating efficiency.
- Distinctive: line 44
Start with the smallest useful number of workers.
- Distinctive: line 45
Keep research, review, and test-analysis workers read-only when possible.
- Distinctive: line 47
Keep cross-cutting decisions, requirements, and interface changes in the main thread.
- Distinctive: line 49
Stop or steer workers that expand scope, duplicate another worker, or lose their evidence path.
- Distinctive: line 50
Wait at explicit dependency or integration gates.
- Distinctive: line 57
Run focused checks, cross-module checks, and a final combined-diff review.
- Distinctive: line 63
Do not claim token savings without measurement.
- Distinctive: line 64
Do not delegate merely because subagents are available.
- Distinctive: line 65
Do not let parallel workers edit the same file.
- Distinctive: line 66
Do not allow a worker’s unverified assumption to become another worker’s requirement.
- Distinctive: line 67
Do not broaden sandbox, network, or external-system permissions for convenience.
- Distinctive: line 68
Do not continue spawning workers recursively without a new independent need.
- Distinctive: line 74
Every worker has bounded scope and a stop condition.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Orchestrate Engineering
Start with the delegation decision
- Read applicable
AGENTS.mdfiles and the task’s acceptance criteria. - Map dependencies before creating workers.
- Use one agent when the task is small, tightly coupled, or dominated by shared-file edits.
- Delegate only when at least two workstreams are genuinely independent, noisy investigation should be isolated, or specialized review materially improves coverage.
- Explain the chosen topology briefly before starting workers.
Subagents normally consume more total tokens than a comparable single-agent run. Optimize for fewer failed loops, cleaner context, better coverage, or lower elapsed time—not the highest agent count.
Choose a topology
- Use fan-out/fan-in for independent read-only research, review, triage, or log analysis.
- Use a pipeline when exploration, planning, implementation, testing, and review depend on prior outputs.
- Use partitioned implementation only after shared interfaces are stable and each worker owns exclusive files or subsystems.
Read references/context-budget.md when selecting a topology, preparing worker context, defining summaries, or evaluating efficiency.
Prepare every worker
Give each worker:
Objective:
Bounded scope:
Required context:
Allowed actions and permissions:
Required evidence:
Output format:
Stop condition:Provide the minimum task-local context. Do not copy the entire main-thread history into every worker.
Coordinate
- Start with the smallest useful number of workers.
- Keep research, review, and test-analysis workers read-only when possible.
- Assign exclusive ownership before parallel writes.
- Keep cross-cutting decisions, requirements, and interface changes in the main thread.
- Require concise evidence summaries instead of raw logs.
- Stop or steer workers that expand scope, duplicate another worker, or lose their evidence path.
- Wait at explicit dependency or integration gates.
Integrate and verify
- Validate worker claims against source files, commands, or authoritative documentation.
- Deduplicate findings and resolve contradictions.
- Integrate write results in dependency order.
- Run focused checks, cross-module checks, and a final combined-diff review.
- Report verified outcomes, unverified areas, residual risks, and worker failures.
- Compare the orchestration against the single-agent alternative using available evidence.
Guardrails
- Do not claim token savings without measurement.
- Do not delegate merely because subagents are available.
- Do not let parallel workers edit the same file.
- Do not allow a worker’s unverified assumption to become another worker’s requirement.
- Do not broaden sandbox, network, or external-system permissions for convenience.
- Do not continue spawning workers recursively without a new independent need.
- Preserve user authority for destructive, production, credential, and external write actions.
Acceptance criteria
- The topology matches the dependency graph.
- Every worker has bounded scope and a stop condition.
- Parallel write ownership is exclusive.
- Worker summaries are smaller and cleaner than their working context.
- The main agent validates and integrates rather than forwarding claims blindly.
- System-level verification covers cross-worker behavior.
- The final report states whether delegation improved quality, elapsed time, or context clarity enough to justify its cost.
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.

