Codex Project Setup
The X-post model / Multi-agent control plane01

Complex projects do not needmore agents first. They need a control plane.

One persistent main Task owns the goal, constraints, key decisions, and final acceptance. Temporary Subagents take only bounded work that can be verified independently.

The point is not to split work into more pieces. It is to give every delegation a clear input, objective evidence, and an explicit return point—then let the main Task integrate the result and write the true state back into the project.

See how the plugin applies itRead the full theory →
  1. 01Main Task defines the goal
  2. 02Subagents execute bounded work
  3. 03Evidence returns
  4. 04Main Task integrates and accepts
  5. 05State is written back
Codex Pluginv0.1.0

Start every new projectwith the right collaboration structure.

Choose Skip, Light, or Orchestrated for a Codex project, then safely create durable context, architecture, acceptance, and handoff rules without overwriting existing files.

Download Marketplace bundleSee how it works

Complete local Marketplace · 37,000 bytes · Plugin source and installation guide included

PROJECT CONTROL PLANE READY
MAIN TASKScope · Decisions · Integration · AcceptanceSingle delivery owner
01ExplorerRead-only exploration
02WorkerBounded implementation
03ReviewerIndependent review
SUBAGENTS ARE TEMPORARYWORKTREES ISOLATE WRITERS
5 / 13 / 18Verified files across three profiles
No overwritesNo force-overwrite mode
dry-run firstPreview non-empty projects first
your approvalUsers approve external actions
Why it exists

Put good habits in the project,
not only in the chat.

When a project gets complicated, the real problem is usually not too few agents. It is missing boundaries for context, responsibility, and acceptance.

A

Non-destructive setup

Preview first and create only missing files. Existing AGENTS, README, and uncommitted changes stay intact.

B

Truthful project state

Only write facts verified from the project. Keep unknowns explicitly marked as 待确认 (To confirm).

C

Bounded multi-agent work

The main Task owns the outcome. Subagents receive only bounded, independently verifiable work.

D

Human control stays visible

Publishing, paid requests, external messages, permissions, and deletion remain explicit user decisions.

One entry point, three choices

Use only the complexity you actually need.

Start with the simplest profile. Upgrade to federated only when cross-repository, cross-deployment, or cross-host boundaries already exist.

00

Skip

creates no files
0FILES

For one-off, small, self-contained work. If the project needs no durable context, staying simple is the right choice.

  • Keep the normal workflow
  • Leave the directory unchanged
  • Enable it later at any time
01

Light

light
5FILES

For a single owner, one repository, and short feedback loops. It records the essential product boundaries and project state.

  • AGENTS.md
  • HANDOFF.md
  • Product definition and decisions
02

Orchestrated

standard / federated
13—18FILES

For multiple modules, milestones, or real cross-repository boundaries, with exploration, implementation, review, and integration clearly separated.

  • Architecture and acceptance
  • Explorer / Reviewer roles
  • Cross-project contracts and integration view
It does not auto-spawn agents

The main Task is the control plane,
not a relay.

The plugin initializes a collaboration structure. It does not automatically create Subagents, Worktrees, separate Tasks, or Automations. Enable parallel work only when the boundaries justify it.

01

Subagents handle read-only exploration, testing, log analysis, and bounded review.

02

Worktrees isolate writers only when several people or agents edit the same repository concurrently.

03

Persistent Tasks are reserved for cross-project, cross-host, or long-lived independent ownership.

standard profile13 files
project/
├── AGENTS.md
├── HANDOFF.md
├── README.md
├── .codex/agents/
│   ├── project-explorer.toml
│   └── project-reviewer.toml
├── docs/
│   ├── PRODUCT.md
│   ├── ARCHITECTURE.md
│   ├── ACCEPTANCE.md
│   ├── ROADMAP.md
│   ├── WORKFLOW.md
│   └── DECISIONS.md
├── work/
└── outputs/
create missing only✓ non-destructive
A durable working loop

Every step leaves evidence
for the next one.

Move from “code was generated” to “observable outcomes were verified.” Update HANDOFF after material state changes, not as a running diary.

  1. 01

    Inspect the project

    Read first, then choose the structure.

  2. 02

    Define acceptance

    Turn done into observable outcomes.

  3. 03

    Build and verify

    Make changes, check them, keep evidence.

  4. 04

    Review independently

    Find issues without silently rewriting.

  5. 05

    Update the handoff

    Write the true state back to HANDOFF.

Start in four steps

Download the Marketplace bundle, then choose a profile in Codex.

  1. 1

    Download and extract the Marketplace bundle

    You will get the codex-project-setup-marketplace directory; it is not a double-click installer.

  2. 2

    Add the local Marketplace

    codex plugin marketplace add /absolute/path/to/codex-project-setup-marketplace

  3. 3

    Install the plugin

    codex plugin add codex-project-setup@codex-project-setup-local

  4. 4

    Start a new Task

    Only a new Task started after installation will load $setup-project-collaboration.

Recommended promptCODEX

Use $setup-project-collaboration to choose and initialize the right Codex collaboration structure for this project.

Inspect the project read-only first. Do not overwrite existing files.

Ready to download

Start the next project
with clear boundaries.

The bundle includes the local Marketplace manifest, plugin source, and INSTALL.md. Installation still requires two Codex commands.

Download Marketplace bundleDownload plugin source ZIP only →
SHA-2560a9e48c5d62f9927ba8766a2e615ac4403afbe7192420b84813798a2a7501aa6
Frequently asked questions

Make the boundaries explicit.

Will Orchestrated automatically start multiple agents?

No. It only creates documentation, directories, and project-level role configurations. Real Subagents, Tasks, Worktrees, or Automations are enabled only when the work calls for them.

Will it overwrite an existing AGENTS.md or README?

No. The initializer creates only missing files and reports same-name content that needs manual integration. There is no force-overwrite mode.

Why not use federated for every project?

More coordination layers increase token use, conflicts, and management cost. Federated is worthwhile only for real cross-repository, cross-deployment, cross-host, or long-lived ownership boundaries.