New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Codex Issue Coordinator

by owainlewis in owainlewis/blueprint

Lets one Codex thread run a batch of GitHub issues through separate worker threads, each with its own worktree, branch, tested pull request and gated merge.

MITAuto-check passedAgent Workflows

Install Codex Issue Coordinator

skills CLI
$ npx skills add owainlewis/blueprint --skill codex-issue-coordinator -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install owainlewis/blueprint codex-issue-coordinator --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/owainlewis/blueprint.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/codex-issue-coordinator .claude/skills/codex-issue-coordinator && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
codex-issue-coordinator
GitHub stars
412
Token cost
~2.6k tokens
SKILL.md length
1,366 words
Files
1
Skills in repo
11
Repo updated
First seen
Licence
MIT

At a glance

Lets one Codex thread run a batch of GitHub issues through separate worker threads, each with its own worktree, branch, tested pull request and gated merge.

  • Works in 5 steps: Read the repository instructions, parent… → Use Codex thread tools. If visible Codex… → Make every issue a complete task before… → …
  • Completing a parent issue by running its sub-issues in parallel Codex threads
  • SKILL.md covers Preconditions, Coordinator workflow, Worker contract and Merge gates, plus 3 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

One thread stays as coordinator while every active issue gets a worker thread, worktree, branch and pull request. Workers hold the implementation context, and GitHub holds the dependency state, so no second local tracker is created. Merging is off unless you name the skill explicitly or tell the coordinator that agents may merge, in which case workers merge their own PRs after every gate passes. Neither mode allows deployment, release publishing, destructive operations, branch-protection bypasses or changes outside the batch.

Before dispatching, the agent reads the repository instructions, parent issue, sub-issues, declared dependencies, project board and linked pull requests, and treats a merged PR as proof of completion only when it closes the issue and satisfies its scope. It stops if visible Codex threads and worktrees are unavailable instead of falling back to hidden subagents, flags issues with missing decisions as needing human input, and stops on a dependency cycle. Two active workers is the default, and the coordinator thread is named after the parent issue and pinned.

When your agent uses it

  • Completing a parent issue by running its sub-issues in parallel Codex threads
  • Working through a milestone with dependencies between issues
  • Managing several coding sessions from one thread, with review loops before merge

Example prompts

  • “Use /codex-issue-coordinator to finish parent issue 128, no merging.”
  • “Coordinate the open issues in the v2 milestone, and agents may merge once checks pass.”
  • “Run the payments cleanup batch with three workers instead of two.”

Requirements

  • Codex thread tools with visible threads and Codex-managed worktrees
  • A GitHub repository with issues and pull requests

Workflow steps

5 steps, taken from the first numbered list in SKILL.md.

  1. Read the repository instructions, parent issue, native sub-issues, declared
  2. Use Codex thread tools. If visible Codex threads and Codex-managed worktrees
  3. Make every issue a complete task before dispatch. If a missing product or
  4. Build a dependency graph. Treat GitHub as the durable source of issue, pull
  5. Default to two active workers. Use another limit only when the user asks or

What it can do on your machine

Read from SKILL.md and the folder at commit 1d74745. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Codex Issue Coordinator loads about 2.6k tokens when it runs. Until then it costs about 72 tokens; SKILL.md has 1,366 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~72
When it runs · the whole SKILL.md, loaded when a task matches
~2.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from owainlewis/blueprint at commit 1d74745, republished under its MIT licence (© owainlewis). 1,366 words, ~2,621 tokens.

Download SKILL.mdSave it as .claude/skills/codex-issue-coordinator/SKILL.md (or your agent's skills folder).
name
codex-issue-coordinator
description
Coordinates a large batch of GitHub issues through separate Codex worker threads, tested pull requests, review loops, and gated merges. Use when the user asks one Codex thread to manage several coding sessions or complete a parent issue, milestone, or issue batch.
user-invocable
true
argument-hint
<parent issue, milestone, or issue list>

Codex issue coordinator

Use one Codex thread to coordinate a GitHub issue batch. Give each active issue its own worker thread, worktree, branch, and pull request. Workers hold implementation context. GitHub holds dependency state.

Explicitly naming /codex-issue-coordinator, or explicitly telling the coordinator that agents may merge, authorizes in-scope workers to merge their own pull requests after every merge gate below passes. An implicit skill match does not grant merge authority: run in no-merge mode unless the user's words grant it. Neither mode authorizes deployment, release publication, destructive operations, branch-protection bypasses, or changes outside the supplied batch.

Preconditions

  1. Read the repository instructions, parent issue, native sub-issues, declared dependencies, project board, issue state, and linked open or merged pull requests. A merged pull request is only evidence of completion when it closes or explicitly references the issue and its final change and proof satisfy the issue scope. Reconcile that issue and project state instead of dispatching it again. Do not infer completion from a link alone.
  2. Use Codex thread tools. If visible Codex threads and Codex-managed worktrees are unavailable, stop. Do not replace workers with hidden subagents.
  3. Make every issue a complete task before dispatch. If a missing product or technical decision could change behavior, data, security, compatibility, operations, cost, or proof, mark that issue as needing human input.
  4. Build a dependency graph. Treat GitHub as the durable source of issue, pull request, review, and merge state. Stop for human correction if the graph contains a dependency cycle. Do not create a second local tracker.
  5. Default to two active workers. Use another limit only when the user asks or the repository gives a stricter limit.

Coordinator workflow

  1. Keep the calling thread as coordinator. Name it #<parent> Coordinator when the batch has a parent issue. Use set_thread_pinned to pin it at the start of every new or resumed coordinator run, before inspecting or dispatching workers.
  2. Reuse an existing active worker for the same issue. Inspect an unclear or interrupted worker before creating another. If the issue already has an open pull request, create or resume its worker on that pull request's exact head branch and include the branch and pull request URL in its prompt. Otherwise create a Codex project thread in a managed worktree from the latest remote default branch and include the required new branch name.
  3. Name every worker #<issue-number> <short title>.
  4. Start only issues whose prerequisites are merged. Independent issues may run together up to the worker limit. Do not stack dependent branches in this workflow.
  5. Give the worker the full issue URL, dependency state, repository location, resolved branch and pull request state, and the worker contract below. Tell it to use /task-to-pr and pass the coordinator's explicit merge or no-merge mode. Merge mode grants authority only for that worker's issue.
  6. Monitor workers with compact wait_threads snapshots. Use read_thread only when a worker needs help. Send decisions or corrected scope back with send_message_to_thread; do not edit the worker's files from the coordinator.
  7. Continue independent work when one issue is blocked. After three failed attempts at the same check or review finding, pause that issue, record the evidence on GitHub, and request human input.
  8. In merge mode, when a worker reports completion, verify GitHub says the pull request is merged, the issue contains final proof, and the issue is closed. Close it explicitly if the merged pull request did not close it. Then mark the issue Done when the project supports it and archive the worker thread. In no-merge mode, stop that worker after its pull request passes all agent-completable gates, leave the issue in Review, record any pending human approval or merge as its blocker, and leave the thread available.
  9. Refresh the dependency graph after every merge and dispatch newly ready issues from the updated remote default branch. In no-merge mode, when a dependent issue is waiting only for a passing prerequisite pull request to be merged, record that human-merge dependency as its blocker. Do not wait indefinitely or dispatch the dependent from an unmerged branch.
  10. In merge mode, finish only when every in-scope issue is merged, closed, and Done when the project supports that state, or every unfinished issue has a recorded blocker that needs human action. In no-merge mode, finish when every in-scope issue has a ready pull request with all agent-completable gates passing or a recorded human blocker.
Show full SKILL.md (630 more words)Show less

Worker contract

Each worker owns one issue and follows this order:

  1. Read the issue, repository instructions, relevant spec, code, tests, and dependency pull requests. Move the issue to In Progress when possible.
  2. Use the Codex-managed worktree. If the issue has an open pull request, reuse its exact head branch and pull request. Otherwise create the repository's required issue-linked branch from the updated default branch.
  3. Implement only the issue. Add or update tests for every acceptance criterion, affected failure path, regression risk, and named edge case.
  4. Use /test. Browser-facing work requires a real browser check of the affected success and failure flows, responsive widths, keyboard behavior, console errors, and failed requests when relevant.
  5. Commit and push the tested change. Open a draft pull request if one is not already open. Include a short summary and current proof.
  6. Mark the pull request ready for review and move the issue to Review. Do this before requesting independent review or waiting for GitHub review.
  7. Use /review with a fresh subagent that did not implement the change. Wait for required CI and automated review. In merge mode, also wait for every repository-required approval. In no-merge mode, do not wait indefinitely for human feedback; record a pending required approval as a human blocker.
  8. Address every valid in-scope finding. Reply to review threads with the fix or evidence for making no change. Resolve a thread only when it is fully addressed.
  9. After any code change, repeat affected /test proof and fresh /review, commit and push, update the pull request evidence, and wait for CI and automated review again. Iterate until the mode's gates pass; do not manufacture extra rounds or wait indefinitely for optional human feedback.
  10. In merge mode, merge the pull request using the repository's preferred method after every merge gate passes. Never use an admin bypass. Wait until GitHub reports the pull request as merged, record final proof, and verify the issue is closed. Close it explicitly if the pull request did not. In no-merge mode, leave the passing pull request open for a human to merge. Report the final state to the coordinator.

Merge gates

A worker may merge only when all of these are true:

  • The pull request is ready for review, not draft.
  • The complete issue scope and acceptance criteria have recorded proof.
  • Focused and required wider tests pass on the final commit.
  • A fresh /review verdict is Approve on the final code.
  • Every required GitHub check passes.
  • Every actionable automated or human review thread is resolved.
  • Every repository-required approval is present.
  • The pull request is mergeable and current with its required base.
  • No security, data-loss, compatibility, operational, or product decision is unresolved.
  • The pull request changes only the worker's issue.

If a gate cannot pass, do not merge. Record the blocker and continue other independent work.

Worker prompt

Use this shape and replace every placeholder:

text
Use /task-to-pr to complete <issue URL> in this Codex-managed worktree.

Your thread owns only this issue, branch, worktree, and pull request.
Branch state: <reuse PR head branch and PR URL, or create new branch name>.
Delivery mode: <merge after all gates pass, or leave the passing PR open>.
Read the issue and repository instructions as the source of truth.
Implement the smallest complete change and prove acceptance criteria, edge
cases, failure paths, and regressions.

After local proof passes, commit, push, open or update the pull request, and
mark it ready for review. Only then run fresh independent /review and wait for
CI and GitHub review. Address valid findings and repeat test and review after
every code change.

<If merge mode: The user explicitly authorized this /codex-issue-coordinator run to
merge this issue's pull request after every merge gate passes. Wait until
GitHub reports the merge, update and close the issue, and return the result.>
<If no-merge mode: Leave the passing pull request open for human merge and
return its URL and proof.>
Do not deploy, publish a release, bypass repository rules, or change unrelated
work.

Return

For each issue, report its worker, pull request, gate state, and blocker. State which issues are complete and which need human action. Do not repeat worker logs that do not change the result.

Boundaries

  • Use visible Codex threads for workers. Fresh subagents are only for the independent /review inside a worker.
  • Never dispatch two workers for one issue or let two workers share a worktree.
  • Never replace or duplicate an existing pull request for the issue. Resume it.
  • Reconcile already-merged pull requests and closed issues before dispatch, but only after their change and proof satisfy the issue scope.
  • Never start dependent work from an unmerged pull request in this workflow.
  • Never merge an unrelated pull request merely because it blocks the batch.
  • Never infer deployment or release authority from merge authority.
  • Do not archive a worker until its merge and final issue state are verified.

© owainlewis, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/codex-issue-coordinator of owainlewis/blueprint.

Open the folder on GitHubat commit 1d74745

Compare with similar skills

Codex Issue Coordinator next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Codex Issue Coordinator compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Codex Issue Coordinator this skillowainlewis/blueprint412—~2.6kAutomated safety check: PassMIT
PRP Workstream OrchestratorWirasm/prp2.3k—~3.5kAutomated safety check: PassMIT
Branch Standup Facilitatorthedotmack/claude-mem97k—~1.7kAutomated safety check: NotesApache-2.0
Context Mode Opsmksglu/context-mode26k—~6kAutomated safety check: PassCustom licence
Gh Issuestrpc-group/trpc-agent-go1.8k8 repos~8.7kAutomated safety check: PassApache-2.0
Badstephenleo/bmad-autonomous-development107—~7.7kAutomated safety check: PassMIT

Similar skills

  • PRP Workstream Orchestrator

    Wirasm/prp

    Coordinates several PRP workstreams in isolated Git worktrees from one session, verifying proof, holding merge gates and sequencing the merges.

    2.3k GitHub stars~3.5k tokensUpdated 5 days ago
    Agent WorkflowsAuto-check passed

  • Branch Standup Facilitator

    thedotmack/claude-mem

    Facilitates a read-only standup between git worktrees, branches or PRs, where each acts as an agent in a shared markdown chat to agree one consolidation plan.

    97k GitHub stars~1.7k tokensUpdated today
    DevelopmentAuto-check: notes

  • Context Mode Ops

    mksglu/context-mode

    Runs maintenance for the context-mode project with parallel subagents: issue triage, PR review, releases, bug fixes, announcements and branch syncing.

    26k GitHub stars~6k tokensUpdated today
    Agent WorkflowsAuto-check passed

  • Gh Issues

    trpc-group/trpc-agent-go

    Fetch GitHub issues, spawn sub-agents to implement fixes and open PRs, then monitor and address PR review comments.

    1.8k GitHub starsUsed in 8 repos~8.7k tokens
    Agent WorkflowsAuto-check passed

  • Bad

    stephenleo/bmad-autonomous-development

    BMad Autonomous Development — orchestrates parallel story implementation pipelines.

    107 GitHub stars~7.7k tokensUpdated 5 mo ago
    Agent WorkflowsAuto-check passed

  • GitHub Swarm Code Review

    ruvnet/agentic-flow

    Reviews GitHub pull requests with a swarm of specialized agents covering security, performance, architecture, style and accessibility, driven by the gh CLI and ruv-swarm.

    816 GitHub starsUsed in 6 repos~6.5k tokens
    DevelopmentAuto-check passed

More from owainlewis/blueprint

All 11 skills in this repo

  • Markdown PRD to HTML Renderer

    owainlewis/blueprint

    Converts a complete Markdown PRD or technical design into one verified, static HTML reading page without changing what it says.

    412 GitHub stars~1.3k tokensUpdated yesterday
    Auto-check passed

  • Vertical-Slice Task Planner

    owainlewis/blueprint

    Breaks a reviewed spec into ordered, vertical-slice tasks that each fit one agent run and one pull request, grouped into milestones when useful.

    412 GitHub stars~1.5k tokensUpdated yesterday
    Auto-check passed

  • Independent Implementation Review

    owainlewis/blueprint

    Has a separate agent review a code change without editing it, checking behavior, security, regressions, complexity, tests and docs before merge.

    412 GitHub stars~1.5k tokensUpdated yesterday
    Auto-check passed

  • Architecture

    owainlewis/blueprint

    Designs and maintains root ARCHITECTURE.md for the intended system, including its data model and shared technical rules.

    412 GitHub stars~1.3k tokensUpdated yesterday
    Auto-check passed

  • Architecture Review

    owainlewis/blueprint

    Reviews a technical proposal before implementation through an independent subagent, returning findings, open questions and a verdict without rewriting it.

    412 GitHub stars~1.2k tokensUpdated yesterday
    Auto-check passed

  • Product Requirements Document

    owainlewis/blueprint

    Creates or updates a long-running REQUIREMENTS.md that defines a system's users, outcomes, capabilities, business rules, scope and acceptance conditions.

    412 GitHub stars~766 tokensUpdated yesterday
    Auto-check passed

Works with

Categories

Questions about Codex Issue Coordinator

What does Codex Issue Coordinator do?

Lets one Codex thread run a batch of GitHub issues through separate worker threads, each with its own worktree, branch, tested pull request and gated merge. One thread stays as coordinator while every active issue gets a worker thread, worktree, branch and pull request. Workers hold the implementation context, and GitHub holds the dependency state, so no second local tracker is created.

When should I use Codex Issue Coordinator?

Codex Issue Coordinator fits situations like: completing a parent issue by running its sub-issues in parallel Codex threads; working through a milestone with dependencies between issues; managing several coding sessions from one thread, with review loops before merge.

How do I install Codex Issue Coordinator in Claude Code?

Run `npx skills add owainlewis/blueprint --skill codex-issue-coordinator -a claude-code`. Or copy the skill folder (skills/codex-issue-coordinator in owainlewis/blueprint) into .claude/skills/codex-issue-coordinator in your project. Claude Code loads it when a task matches its description.

How do I install Codex Issue Coordinator in Codex?

Run `npx skills add owainlewis/blueprint --skill codex-issue-coordinator -a codex`. Or copy the skill folder (skills/codex-issue-coordinator in owainlewis/blueprint) into .agents/skills/codex-issue-coordinator in your project. Codex loads it when a task matches its description.

Can I use Codex Issue Coordinator in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add owainlewis/blueprint --skill codex-issue-coordinator -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/codex-issue-coordinator, .gemini/skills/codex-issue-coordinator, .github/skills/codex-issue-coordinator and .opencode/skills/codex-issue-coordinator in your project.

What does Codex Issue Coordinator need to run?

SKILL.md names no scripts, command-line tools or credentials: Codex Issue Coordinator is instructions for the agent only. Our summary lists: Codex thread tools with visible threads and Codex-managed worktrees; A GitHub repository with issues and pull requests.

Does Codex Issue Coordinator access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Codex Issue Coordinator safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Codex Issue Coordinator use?

Codex Issue Coordinator is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Codex Issue Coordinator use?

About 2.6k tokens (SKILL.md is roughly 10k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Codex Issue Coordinator?

Skills that share tags, products or a category with Codex Issue Coordinator: PRP Workstream Orchestrator (Wirasm/prp, 2.3k stars), Branch Standup Facilitator (thedotmack/claude-mem, 97k stars), Context Mode Ops (mksglu/context-mode, 26k stars) and Gh Issues (trpc-group/trpc-agent-go, 1.8k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Codex Issue Coordinator?

owainlewis (a GitHub user) maintains it in owainlewis/blueprint, which has 412 GitHub stars. The repository holds 11 skills in this directory. The repository was last updated on October 6, 2026.

Source: owainlewis/blueprint on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.