Edict Agent

Edict Agent

Use a lightweight Edict pattern to turn complex work into conflict-safe parallel delivery. Preserve one clear owner: the main Codex agent runs the qiushi preflight, cuts the work into file-exclusive slices, delegates implementation workers, reviews, integrates, verifies, and answers.

Operating Bias

Default to finding deliverable worker slices, not serial execution and not parallel exploration for its own sake. Use explorers, reviewers, or verifiers only when they materially improve boundary clarity, safety, or confidence.

Stay single-agent when most of these are true:

• The change is small, local, or easy to verify.
• The work requires one tightly coherent edit across shared state.
• Safe file or directory ownership boundaries cannot be drawn.
• Delegation would create more merge risk than delivery value.
• Tooling for subagents is unavailable; in that case, emulate the pattern with an explicit checklist and self-review.

Use parallel workers when at least two of these are true:

• The task spans multiple modules, services, languages, papers, datasets, or artifacts.
• Independent implementation slices can be assigned with clear file, directory, subsystem, or artifact ownership.
• Several concrete features, fixes, checks, or document sections can progress at the same time.
• The user has requested autonomous multi-agent judgment, Edict mode, delegation, or parallel work.
• Parallel delivery would shorten the critical path without causing shared-file conflicts.

Edict Flow

1. Qiushi preflight. Read and follow the installed workflows skill as the qiushi workflow source when available, typically at ${CODEX_HOME:-$HOME/.codex}/skills/workflows/SKILL.md. If the workflows skill is not available, run the compact preflight below directly. Keep this preflight lightweight unless the task itself demands the full workflow. Produce:

   • current situation
   • key constraints
   • main contradiction or bottleneck
   • acceptance criteria and verification signals
   • candidate parallel delivery slices
   • files, directories, or artifacts that must stay under main-agent ownership

2. Draft the edict. Convert the user's goal and qiushi preflight into concrete acceptance criteria, constraints, likely affected areas, worker slices, and verification commands.

3. Plan file-exclusive ministries. Split along natural ownership boundaries. Each worker must own a non-overlapping file, directory, subsystem, artifact, or document section. Shared files, entrypoints, configuration files, migrations, lockfiles, public API glue, and cross-cutting integration code stay with the main agent unless explicitly assigned to exactly one worker.

4. Choose fanout. Use one agent for simple tasks. Use 2-6 workers for medium tasks. For highly decomposable tasks with clean ownership boundaries, scale beyond 6 and up to the configured agents.max_threads cap, which may be 30. Do not chase the cap when slices are vague or overlapping.

5. Dispatch delivery workers. Give each worker a narrow implementation objective, context, exclusive scope, forbidden scope, edit permissions, and expected output. Workers should advance one concrete functional point or subtask, not merely explore. Use an explorer only when ownership boundaries are not yet knowable.

6. Conflict gate. Before edits begin, check for overlap. If two slices need the same file or artifact, do not let both workers edit it. Re-slice the work, make one worker advisory-only, or keep the shared change for the main agent to do serially.

7. Review gate. Treat worker outputs as proposals until inspected. Require evidence for important claims. Re-read important files yourself before merging or reporting. Use Reviewer or Verifier agents for high-risk, cross-module, user-facing, security-sensitive, financially or legally consequential tasks, or when workers disagree.

8. Integrate and verify. The main agent owns final integration, shared files, diff review, tests/checks/renders when feasible, and the final answer.

9. Final audit. Before answering, check scope, evidence, diffs, tests, unverified areas, residual risks, and whether the parallel plan avoided shared-file conflicts.

Role Patterns

• Worker: scoped implementation for one feature point, subsystem, artifact, or document section with exclusive ownership. Prefer this role for parallel delivery.
• Explorer: read-only investigation of architecture, call chains, failing behavior, data sources, or test coverage. Use only when boundaries are unclear.
• Reviewer: skeptical audit of a plan, diff, paper section, migration, API contract, or UI behavior. Use for risk and contradiction checks.
• Verifier: run or design targeted checks, reproduce bugs, compare expected and actual behavior.

Worker Dispatch Prompt Shape

When launching a worker subagent, include:

• Objective: the concrete deliverable to implement or advance.
• Context: only the relevant user goal, qiushi preflight result, and constraints.
• Exclusive scope: exact files, directories, systems, sources, or artifact sections the worker may modify.
• Forbidden scope: shared files, overlapping areas, unrelated cleanup, assumptions not to make, and anything reserved for the main agent.
• Coordination: whether the worker may edit files directly or must return a patch/proposal.
• Output: changed files, commands run, evidence, risks, and any integration notes for the main agent.

Do not pass hidden conclusions as facts. Independent review should stay independent.