flc1125/skills

Multi Codex Orchestrator

Orchestrate multiple standalone Codex workers for parallel repository tasks. Use when the user wants task decomposition, isolated worktrees, structured worker outputs, patch collection, and final integration by a single coordinator.

First seen Apr 11, 2026

Installation

$ npx skills add flc1125/skills --skill multi-codex-orchestrator

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from flc1125/skills · top by installs.

npx skills add flc1125/skills

Browse all from flc1125/skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 36
License LICENSE
Default branch main
Open issues 2
Status Active

Skill metadata

Parsed from SKILL.md frontmatter.

More metadata
name
Multi Codex Orchestrator
description
Coordinate parallel Codex workers for isolated repository task execution.
author
Flc
created
2026-04-10T15:40:40Z

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 4,020 B
  • docs SUMMARY.md 264 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 11 installs

SKILL.md

Multi Codex Orchestrator

Use this skill when the user explicitly wants multiple Codex workers running as independent agents, rather than relying on built-in sub-agent behavior.

When To Use

  • The task can be split into mostly independent workstreams.
  • Each worker can own a bounded path set or responsibility.
  • The coordinator can validate and integrate outputs at the end.

When Not To Use

  • The task is small enough for one agent.
  • Several workers would need to edit the same core files.
  • The task is highly sequential and cannot benefit from parallelism.

Default Execution Model

  1. Create a plan file from assets/templates/plan.yaml.
  2. Give each worker a clear id, role, paths, and goal.
  3. Use scripts/spawn_agents.sh to validate the plan and create one git worktree per worker under /tmp/.
  4. Run each worker with codex exec in its own worktree.
  5. Require each worker to write result.json in its run directory.
  6. Use scripts/collect_results.sh to gather artifacts and diffs.
  7. Integrate centrally. Do not let workers merge each other's changes.

Hard Rules

  • One worker owns one write scope.
  • Default to isolated git worktrees, not one shared writable tree.
  • Workers must produce structured outputs, not just free-form prose.
  • The coordinator must re-validate before integrating.
  • If two workers need the same file, redesign the split or serialize the work.

File Layout

  • scripts/plan_tasks.sh: copy a starter plan into a target project folder.
  • scripts/spawn_agents.sh: parse the plan, create worktrees, and launch workers.
  • scripts/collect_results.sh: summarize each worker run.
  • scripts/merge_patches.sh: verify worker status and apply non-conflicting diffs into the integration branch.
  • references/task-schema.md: the supported plan shape.
  • references/output-schema.md: required worker outputs.
  • references/conflict-policy.md: what to do when scopes collide.

Quick Start

PROJECT_DIR=output/2026-04-10/my-parallel-run
mkdir -p "$PROJECT_DIR"

./scripts/plan_tasks.sh "$PROJECT_DIR"
# edit "$PROJECT_DIR/plan.yaml"

./scripts/spawn_agents.sh "$PROJECT_DIR/plan.yaml"
./scripts/collect_results.sh "$(cat "$PROJECT_DIR/.last-run-dir")"

Plan Format

Read references/task-schema.md before editing plan.yaml.

This MVP expects a small, line-oriented YAML shape:

goal: Add RBAC to the app
repo_path: /abs/path/to/repo
base_branch: main
run_root: /tmp/multi-codex-orchestrator
agents:
  - id: analyst
    role: analyze
    paths: src/auth,src/models
    goal: Inspect current auth model and propose changes
  - id: backend
    role: implement
    paths: src/auth,src/api
    goal: Implement middleware and API changes

Worker Prompting

The launcher renders assets/templates/agent-task.md for each worker and appends the worker-specific fields from the plan.

Each worker should:

  • stay inside its owned paths
  • write result.json
  • leave code changes in its worktree
  • avoid rebasing, merging, or force-pushing

Before launch, the coordinator should reject any plan where two workers own overlapping paths.

Validation

  • Use scripts/collect_results.sh first.
  • Review result.json, last-message.txt, and diff.patch for each worker.
  • Only then apply scripts/merge_patches.sh, which will refuse blocked or conflicting worker outputs.

Notes

  • This is an MVP skill. It favors explicit structure over clever automation.
  • If you need more flexible schemas later, replace the shell YAML parsing with a dedicated parser.