agentleFS
Phelan164Phelan164/codex-howto/skills/orchestrate-engineering/SKILL.md

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.

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
  1. Distinctive:

    Read applicable AGENTS.md files and the task’s acceptance criteria.

    line 10
  2. Distinctive:

    Use one agent when the task is small, tightly coupled, or dominated by shared-file edits.

    line 12
  3. Distinctive:

    Use fan-out/fan-in for independent read-only research, review, triage, or log analysis.

    line 20
  4. Distinctive:

    Use a pipeline when exploration, planning, implementation, testing, and review depend on prior outputs.

    line 21
  5. Distinctive:

    Use partitioned implementation only after shared interfaces are stable and each worker owns exclusive files or subsystems.

    line 22
  6. Distinctive:

    Read references/context-budget.md when selecting a topology, preparing worker context, defining summaries, or evaluating efficiency.

    line 24
  7. Distinctive:

    Start with the smallest useful number of workers.

    line 44
  8. Distinctive:

    Keep research, review, and test-analysis workers read-only when possible.

    line 45
  9. Distinctive:

    Keep cross-cutting decisions, requirements, and interface changes in the main thread.

    line 47
  10. Distinctive:

    Stop or steer workers that expand scope, duplicate another worker, or lose their evidence path.

    line 49
  11. Distinctive:

    Wait at explicit dependency or integration gates.

    line 50
  12. Distinctive:

    Run focused checks, cross-module checks, and a final combined-diff review.

    line 57
  13. Distinctive:

    Do not claim token savings without measurement.

    line 63
  14. Distinctive:

    Do not delegate merely because subagents are available.

    line 64
  15. Distinctive:

    Do not let parallel workers edit the same file.

    line 65
  16. Distinctive:

    Do not allow a worker’s unverified assumption to become another worker’s requirement.

    line 66
  17. Distinctive:

    Do not broaden sandbox, network, or external-system permissions for convenience.

    line 67
  18. Distinctive:

    Do not continue spawning workers recursively without a new independent need.

    line 68
  19. Distinctive:

    Every worker has bounded scope and a stop condition.

    line 74

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Orchestrate Engineering

Start with the delegation decision

  1. Read applicable AGENTS.md files and the task’s acceptance criteria.
  2. Map dependencies before creating workers.
  3. Use one agent when the task is small, tightly coupled, or dominated by shared-file edits.
  4. Delegate only when at least two workstreams are genuinely independent, noisy investigation should be isolated, or specialized review materially improves coverage.
  5. 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

  1. Start with the smallest useful number of workers.
  2. Keep research, review, and test-analysis workers read-only when possible.
  3. Assign exclusive ownership before parallel writes.
  4. Keep cross-cutting decisions, requirements, and interface changes in the main thread.
  5. Require concise evidence summaries instead of raw logs.
  6. Stop or steer workers that expand scope, duplicate another worker, or lose their evidence path.
  7. Wait at explicit dependency or integration gates.

Integrate and verify

  1. Validate worker claims against source files, commands, or authoritative documentation.
  2. Deduplicate findings and resolve contradictions.
  3. Integrate write results in dependency order.
  4. Run focused checks, cross-module checks, and a final combined-diff review.
  5. Report verified outcomes, unverified areas, residual risks, and worker failures.
  6. 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.