Skip to content
cccskills
FreePublished on GitHub

orchestrate-engineering

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 English summary is being prepared. Showing the original description.

See how to install

Files included (3)

  • SKILL.md3.9 KB
  • agents/openai.yaml280 B
  • references/context-budget.md2.8 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Build or modify backend APIs, services, jobs, persistence, and integrations while preserving contracts, authorization, data integrity, and failure behavior. Use for server-side features, database changes, background processing, backend defects, and service refactors; do not use for frontend-only or infrastructure-only work.

The English summary is being prepared. Showing the original description.

Phelan164/codex-howto14Updated Oct 17, 2026

Build or modify frontend interfaces using repository-native components while preserving accessibility, responsive behavior, state handling, and visual verification. Use for UI features, design implementation, forms, client-side defects, and frontend refactors; do not use for backend-only or infrastructure-only work.

The English summary is being prepared. Showing the original description.

Phelan164/codex-howto14Updated Oct 17, 2026

Select the smallest useful Codex engineering workflow from this repository's existing skills. Use when a task spans multiple engineering concerns, the user is unsure which skill to invoke, or loading every specialist would waste context; return a recommendation only and do not execute the engineering task.

The English summary is being prepared. Showing the original description.

Phelan164/codex-howto14Updated Oct 17, 2026

Implement a repository code or configuration change through reproduction, focused checks, review, and evidence. Use for end-to-end features and fixes; not for explanation-only, review-only, research, content publishing, or production operations.

The English summary is being prepared. Showing the original description.

Phelan164/codex-howto14Updated Oct 17, 2026

Review a small code or documentation change and return only evidence-backed correctness findings. Use in the Codex How To local plugin lab; do not modify files or post remote comments.

The English summary is being prepared. Showing the original description.

Phelan164/codex-howto14Updated Oct 17, 2026

Maintain a review-first Markdown knowledge base for Codex practices with source provenance, engineering capture, citation-aware queries, explicit archive and promotion, and deterministic linting. Use when asked to capture a durable engineering lesson, ingest Codex research, query or archive what the repository knows, check wiki health, reconcile conflicting guidance, or promote verified knowledge.

The English summary is being prepared. Showing the original description.

Phelan164/codex-howto14Updated Oct 17, 2026

See all skills by Phelan164

Report a problem with this skill