{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiffgn35wzhsg5ah2o7pbmyie7fgfr3adcroxelv6ob6aahpsptbrm",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mpph5r7wtsi2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreicw6rmvjyy3kywgl4diwevh7ewb5ipt34og4r46ixkngv3rnd5q6i"
    },
    "mimeType": "image/webp",
    "size": 65698
  },
  "path": "/shreyshah/steal-my-prompt-to-turn-codex-into-an-orchestration-manager-53fe",
  "publishedAt": "2026-07-03T01:50:14.000Z",
  "site": "https://dev.to",
  "tags": [
    "ai",
    "programming",
    "productivity",
    "agents"
  ],
  "textContent": "The mistake with coding agents is treating them like a single chat window.\n\nYou paste a task. The agent writes a patch. You check it. Something is missing. You paste another task. Then another. Then CI fails. Then review comments come in. Then you realize you are still the project manager, the QA loop, the scheduler, and the person remembering what every thread was supposed to do.\n\nThe better workflow is to make one Codex thread responsible for orchestration.\n\nNot just the code.\n\nThe loop around the code.\n\nYou give Codex a defined batch of work and ask it to act as the Orchestration Manager. It breaks the work into threads, gives them goals, checks progress on a heartbeat, watches PRs or handoffs, routes feedback, requires verification, and keeps going until the work is actually complete.\n\nThis works for any scoped work.\n\nIt can be a bug fix, a refactor, a migration, a documentation cleanup, a test suite repair, a research task, or a backlog of small improvements.\n\nThe whole thing starts from one prompt.\n\n##  The copy-paste prompt\n\nUse this as the starting prompt for the manager thread:\n\n\n\n    You are the Orchestration Manager for this work.\n\n    Your job is to move the work forward until it is actually complete. Do not personally implement everything unless that is the smallest safe path. You are responsible for planning, scheduling, coordination, follow-up, verification, and keeping momentum.\n\n    Work scope:\n    [PASTE PLAN.md, issue list, checklist, bug report, feature list, refactor plan, research brief, or task description here]\n\n    Before starting, review the work scope and tell me if anything is unclear, risky, too broad, underspecified, or likely to cause worker threads to collide. If the scope is clear enough, continue. If not, ask the minimum number of questions needed to make it executable.\n\n    Responsibilities:\n    1. Break the work scope into worker-thread tasks that can run independently.\n    2. Decide which tasks should run now and which should wait.\n    3. Create or instruct worker threads with clear /goal prompts.\n    4. Make sure each worker has a narrow scope, a definition of done, and a reporting format.\n    5. Make sure code changes include tests where practical.\n    6. Make sure non-code work includes a clear verification step.\n    7. Make sure workers open PRs, prepare patches, produce artifacts, or deliver handoffs as appropriate.\n    8. Track worker status, changed files, test results, PR status, CI status, review feedback, and blockers.\n    9. Create follow-up worker threads when tests fail, review feedback appears, work stalls, artifacts are incomplete, or the implementation does not meet the definition of done.\n    10. Keep moving until the work is complete, verified, and ready for human review or merge.\n\n    Use /goal to keep yourself and the worker threads on track.\n\n    Use a heartbeat every 10 minutes.\n\n    At every heartbeat:\n    - check the status of all worker threads\n    - identify stale or blocked work\n    - inspect open PRs or current artifacts\n    - check whether tests, CI, or verification passed\n    - check whether review feedback needs action\n    - decide the next action\n    - create follow-up work if needed\n\n    Worker threads should also check in immediately when:\n    - they open or update a PR\n    - they produce a draft, patch, report, or artifact\n    - tests pass or fail\n    - CI fails\n    - review feedback is addressed\n    - they are blocked\n    - they believe their work is complete\n\n    Every worker thread should report back in this format:\n\n    Status:\n    Done / Blocked / Needs review\n\n    Summary:\n    What changed or what was produced in plain English.\n\n    Files or artifacts changed:\n    - ...\n\n    Verification:\n    - command, check, review step, or result\n\n    PR or handoff:\n    - link, artifact path, or not created yet\n\n    Open issues:\n    - none, or list blockers\n\n    Recommended next action:\n    - merge\n    - review\n    - create follow-up thread\n    - wait for another thread\n    - manual test needed\n    - publish artifact\n    - stop\n\n    Rules:\n    - Keep worker scopes small.\n    - Avoid assigning two workers to edit the same files unless there is a clear reason.\n    - Do not mark work complete just because something was written.\n    - Work is complete only when the definition of done is met and verification has passed.\n    - If UI behavior is involved, require manual testing or a clear test plan before calling it done.\n    - If research or writing is involved, require source review and a final editorial pass before calling it done.\n    - If a worker thread becomes unresponsive, start a replacement thread and preserve the current state.\n    - If you are unsure whether the next step is safe, pause and ask.\n\n    Start by producing:\n    1. The proposed worker-thread schedule\n    2. The /goal prompt for each worker\n    3. The heartbeat plan\n    4. The verification plan\n    5. The first action you will take\n\n\nThat is the workflow.\n\nOne prompt turns a Codex thread into the Orchestration Manager for a piece of work.\n\n##  Why this works\n\nMost agent workflows break at the handoff points.\n\nThe first output might be decent. The problem is everything around the output:\n\n\n\n    Did the agent run tests?\n    Did it verify the result?\n    Did it open a PR?\n    Did CI pass?\n    Did review comments come in?\n    Did a worker get stuck?\n    Did two agents edit the same file?\n    Did anyone follow up after the first attempt failed?\n\n\nThat is where the human usually gets dragged back in.\n\nThe Orchestration Manager prompt moves those handoff points into the agent's job description.\n\nThe manager thread is not there to be clever. It is there to keep state and keep pushing.\n\n##  The mental model\n\nThink of the system as three layers.\n\n\n\n    Human\n    -> defines the work and reviews judgment calls\n\n    Orchestration Manager\n    -> schedules work, checks progress, tracks handoffs, starts follow-ups\n\n    Worker threads\n    -> execute narrow tasks in their own context or worktree\n\n\nThe human still owns taste, judgment, and final approval.\n\nThe manager owns momentum.\n\nThe workers own execution.\n\nThat separation matters because coding agents get worse when one thread has to be planner, implementer, reviewer, tester, project manager, and memory all at once.\n\nA manager thread should stay at the work-loop level. A worker thread should stay at the task level.\n\n##  The work scope has to be real\n\nThis workflow works best when the work is already defined.\n\nBad input:\n\n\n\n    Make the app better.\n\n\nBetter input:\n\n\n\n    Work scope:\n    1. Replace the legacy billing webhook handler with the new event router\n    2. Add tests for invoice.paid, invoice.failed, subscription.updated, and subscription.deleted\n    3. Backfill missing webhook fixtures\n    4. Update the deployment runbook with the new rollback steps\n    5. Open a PR with the migration, tests, risks, and verification notes\n    6. Address review comments until the PR is ready to merge\n\n\nThat scope is specific enough for an Orchestration Manager to split into useful worker threads:\n\n\n\n    Worker 1: event router implementation\n    Worker 2: webhook fixture backfill\n    Worker 3: test coverage\n    Worker 4: runbook update\n    Worker 5: PR review follow-up\n\n\nThe manager can help refine a plan, but it cannot read your mind.\n\nIf you give it vague work, it will create vague workers. If you give it crisp work, it can schedule useful threads.\n\n##  The worker goal matters\n\nThe worker prompt should not be a feature request.\n\nIt should be a finish line.\n\nWeak:\n\n\n\n    Fix the billing webhook code.\n\n\nBetter:\n\n\n\n    /goal Replace the legacy billing webhook handler with the new event router. Keep changes limited to webhook routing, billing event handlers, and directly related tests. Preserve existing behavior for invoice.paid, invoice.failed, subscription.updated, and subscription.deleted. Add or update tests proving the migrated paths work. Report changed files, test results, blockers, and recommended next action. Stop only when the implementation is PR-ready or you are blocked.\n\n\nThat one prompt gives the worker a role, scope, test expectation, handoff format, and stop condition.\n\nThe manager can generate these goals automatically, but the goal shape should stay this explicit.\n\n##  Heartbeats are the safety net\n\nThe heartbeat is what makes this feel different from a normal chat.\n\nEvery 10 minutes, the manager checks the system:\n\n\n\n    What is active?\n    What is blocked?\n    What changed?\n    Which PRs or artifacts exist?\n    Did tests pass?\n    Did CI fail?\n    Did review feedback appear?\n    What needs a follow-up worker?\n\n\nThe heartbeat should not be the only way information moves.\n\nWorkers should check in immediately when they hit a milestone. A heartbeat catches stale work. Worker check-ins keep the loop responsive.\n\nUse both.\n\n##  Feedback is part of the workflow\n\nA lot of agent workflows stop at \"PR opened\" or \"draft produced.\"\n\nThat is too early.\n\nThe Orchestration Manager should treat feedback as new work.\n\nIf review comments appear, the manager should classify them:\n\n\n\n    bug\n    style\n    test request\n    architecture concern\n    documentation request\n    unclear feedback\n\n\nThen it should either assign all comments to one worker or split them across follow-up workers.\n\nExample follow-up goal:\n\n\n\n    /goal Address the unresolved review comments related to the billing event router. Only modify files needed for those comments. Add or update tests if behavior changes. Run the relevant test suite. Report which comments were resolved, changed files, test results, and whether any review feedback remains. Stop only when these comments are resolved or blocked.\n\n\nThis is where the workflow becomes useful.\n\nThe first pass is rarely the final pass. The manager exists to keep the second and third passes from being forgotten.\n\n##  Checks and balances\n\nDo not confuse this with fully trusting the agent.\n\nThe manager thread can stall. Worker threads can hallucinate completion. Heartbeats can keep a bad loop alive. UI changes can look correct in code and still feel wrong in the app. Research can sound complete while missing the primary source.\n\nSo the prompt should force checks:\n\n\n\n    Code changes need tests where practical.\n    PRs need review.\n    CI status matters.\n    UI work needs manual testing or a clear test plan.\n    Research work needs source review.\n    Writing work needs an editorial pass.\n    Unresponsive threads should be replaced.\n    The manager should pause when the next step is unsafe.\n\n\nThe point is not to remove human judgment.\n\nThe point is to remove human babysitting.\n\n##  The reusable pattern\n\nThe pattern is simple:\n\n\n\n    Define the work.\n    Start an Orchestration Manager Codex thread.\n    Ask it to schedule worker threads.\n    Use /goal for every worker.\n    Run a 10 minute heartbeat.\n    Require verification, tests, review, or artifacts depending on the work.\n    Spawn follow-up workers when anything fails.\n    Repeat until the work is complete.\n\n\nThat is a better default than one giant prompt.\n\nA single agent gives you an attempt.\n\nAn Orchestration Manager gives you an operating loop.\n\nThe human still decides what matters.\n\nThe agent keeps the work moving.",
  "title": "Steal my prompt to turn Codex into an Orchestration Manager"
}