---
name: task-runner-loop
description: Orchestrate serial execution of a backlog of tasks or issues by asking for the task source and commit policy, selecting the next unblocked task, delegating each task to one worker subagent, and repeating until no executable tasks remain. Use when the user wants Codex to work through tasks from a local folder, GitHub issues, or another described task source one at a time.
---

# Task Runner Loop

Run a task backlog in series. The main agent owns task discovery, ordering, state, and stop decisions. A worker subagent owns exactly one task at a time and must finish it end to end before the next task is selected.

## Start

If the user's message does not already provide both required values, ask exactly one initial message containing only these two decisions:

1. Task source: local folder path, GitHub issues/repository, or another described source.
2. Commit policy: commit after every completed task, or do not commit.

Accept both answers in one user reply. Do not ask additional startup questions unless the source cannot be resolved or accessed.

Record the answers as run-level rules. Pass the commit policy into every worker prompt and enforce it for the whole run.

## Resolve The Source

Normalize every source into task records with: source, id, title, body/content, status, known blockers, acceptance criteria when present, and source URL/path when available.

- For GitHub issues, confirm repository context with `git remote -v` and `gh repo view --json nameWithOwner,url`. If `/Users/luismi/.codex/skills/gh-next-issue/SKILL.md` is available, read it and reuse its issue-selection rules, but override any commit/close behavior with this run's commit policy.
- For a local folder, use `rg --files <folder>` and read likely task files. Prefer Markdown, text, JSON, YAML, and issue-like files. Infer blockers from sections or phrases such as `Blocked by`, `Depends on`, `Parent`, `Epic`, unchecked prerequisite lists, or explicit issue references.
- For another source, inspect the available data and convert it to the same task-record shape. If the source cannot be inspected with available tools, ask for the minimum missing access detail.

Maintain an in-memory completed/blocked/skipped list for the current run. Do not mutate the task source just to track loop progress unless the user or task explicitly asks for that.

## Select The Next Task

Before every worker launch, refresh or re-check the source enough to avoid selecting stale work.

Choose the next task with these rules:

- Ignore completed tasks from this run.
- Treat tasks with unresolved open blockers as blocked.
- Prefer concrete implementation tasks over parent issues, epics, umbrella tasks, planning tasks, or vague notes.
- Prefer tasks that unlock other tasks, establish foundations, or have clear acceptance criteria.
- If several tasks are equally good, choose the earliest/lowest-numbered one.
- If all remaining tasks are blocked or ambiguous, stop and report why.

## Delegate One Task

Launch exactly one `worker` subagent for the selected task. Do not run task workers in parallel.

Before launching the worker, send a short user-facing progress update that names the task currently being delegated and lists all currently known unblocked executable task IDs still left after it. This update is informational only; it does not need a full ordered plan.

Use the user's language when practical. For Spanish, use this shape:

```text
Vale, estoy trabajando en <current id/title>. He mandado a hacer <current id/title>. Lo siguiente son: <id1>, <id2>, <id3> (<n> siguientes, <n> quedan).
```

If no unblocked executable tasks remain after the current one, say:

```text
Vale, estoy trabajando en <current id/title>. He mandado a hacer <current id/title>. Ya se está procesando el último.
```

The worker prompt must include:

- The complete task record, including full body/content and acceptance criteria.
- The original task source and any relevant URL/path.
- The run-level commit policy, stated explicitly as either `commit after completing this task` or `do not commit`.
- A reminder that the worker is not alone in the codebase, must preserve unrelated user changes, and must not revert work it did not create.
- Instructions to inspect the codebase before editing, implement the smallest coherent end-to-end change, add/update tests proportional to risk, and run relevant verification.
- Instructions to report changed files, verification commands and results, completion status, blockers, and commit hash if a commit was required.

Use this prompt shape:

```text
You are responsible for exactly one task from a serial backlog run.

Run-level rule: <commit after completing this task | do not commit>.
You are not alone in the codebase. Preserve unrelated user changes and do not revert edits you did not make.

Task source: <source>
Task id/title: <id/title>
Task URL/path: <url/path>

Task content:
<full task body>

Acceptance criteria:
<criteria or "Not explicitly provided; derive from task content and existing behavior.">

Implement this task end to end. Inspect the repo first, make the smallest coherent change, update tests as needed, and run relevant verification.

If commits are required, stage only files for this task and create one clear commit. If commits are not required, leave changes uncommitted.

Final response must include:
- status: completed, blocked, or failed
- summary
- changed files
- verification
- commit hash, if committed
- remaining blockers or follow-up, if any
```

Wait for the worker to finish before selecting the next task.

## Accept Or Block A Result

Accept a worker result as completed only when it reports:

- `status: completed`
- what changed
- verification performed or a concrete reason verification could not run
- changed files
- commit hash when commits were required

If commits were required and no commit hash is reported, inspect status/diff and either ask the worker to finish the commit or mark the task failed. If commits were not required, do not create a commit on the worker's behalf unless the user changes the run-level policy.

For GitHub sources, close or update issues only when the task is fully implemented and the source workflow clearly permits it. If commits are disabled, prefer reporting the issue as ready to close rather than closing it with uncommitted local changes.

If the worker reports `blocked` or `failed`, record the reason and continue only if another unblocked task exists.

After accepting, blocking, or failing a worker result, refresh the remaining task list and send the same short progress update before delegating the next worker. If the run is stopping because nothing unblocked remains, report that instead.

## Stop

Repeat selection and delegation until no unblocked executable tasks remain.

In the final response, report:

- completed tasks
- blocked/skipped tasks with reasons
- failed tasks, if any
- commits created, if any
- verification gaps and remaining user decisions