Backlog Feature Sweep
Run the complete feature workflow: create a backlog, verify it is ready for unattended implementation, then process that backlog until every task is complete.
Workflow
Use the create-backlog workflow.
- Interview the user one question at a time.
- Inspect the codebase whenever the answer can be discovered locally.
- Write or update
codex-backlogs/<feature-slug>.md.
- Decompose the converged design into detailed atomic tasks with acceptance criteria and tests.
- Review the backlog against the agreed understanding and revise it before coding.
- Finish all interviewing, clarification, verification, and backlog enrichment before implementation begins.
Use the process-backlog workflow on that backlog.
- Verify the full backlog is detailed enough to implement unattended.
- Move one task at a time from
Incomplete to In-Progress.
- Implement it fully, review the changes, run specified tests, and verify acceptance criteria.
- Move it to
Completed only when fully resolved.
- Refresh the processing instructions before each task cycle.
- Continue until both
Incomplete and In-Progress are empty.
Stop Conditions
A final response is allowed only when Incomplete and In-Progress are both empty, a blocker cannot be resolved from code, tests, docs, backlog, or reasonable engineering judgment, or the user explicitly says stop, pause, summarize only, or gives a new conflicting task.
Passing a subset of tests, finishing a phase, completing a long task chunk, context pressure, or reaching a useful checkpoint is not a stop condition. If work is extensive, continue across multiple tool cycles and use brief progress updates instead of final summaries.
Operating Rules
- Keep the backlog document as the source of truth throughout the sweep.
- Maintain high implementation quality even during long runs.
- Do not skip unclear decisions; resolve them before coding through code inspection or one-at-a-time user questions.
- Once coding begins, do not return to the user for ordinary clarification; use the backlog, codebase, tests, and reasonable implementation judgment unless truly blocked.
- Do not stop after planning if implementation is feasible in the current workspace.
1---2name: backlog-feature-sweep3description: Plan and implement a feature by first creating a detailed code-informed backlog, then processing it to completion. Use when the user wants an end-to-end feature sweep, from interview and task breakdown through implementation.4---56# Backlog Feature Sweep78Run the complete feature workflow: create a backlog, verify it is ready for unattended implementation, then process that backlog until every task is complete.910## Workflow11121. Use the `create-backlog` workflow.13 - Interview the user one question at a time.14 - Inspect the codebase whenever the answer can be discovered locally.15 - Write or update `codex-backlogs/<feature-slug>.md`.16 - Decompose the converged design into detailed atomic tasks with acceptance criteria and tests.17 - Review the backlog against the agreed understanding and revise it before coding.18 - Finish all interviewing, clarification, verification, and backlog enrichment before implementation begins.19202. Use the `process-backlog` workflow on that backlog.21 - Verify the full backlog is detailed enough to implement unattended.22 - Move one task at a time from `Incomplete` to `In-Progress`.23 - Implement it fully, review the changes, run specified tests, and verify acceptance criteria.24 - Move it to `Completed` only when fully resolved.25 - Refresh the processing instructions before each task cycle.26 - Continue until both `Incomplete` and `In-Progress` are empty.2728## Stop Conditions2930A final response is allowed only when `Incomplete` and `In-Progress` are both empty, a blocker cannot be resolved from code, tests, docs, backlog, or reasonable engineering judgment, or the user explicitly says stop, pause, summarize only, or gives a new conflicting task.3132Passing a subset of tests, finishing a phase, completing a long task chunk, context pressure, or reaching a useful checkpoint is not a stop condition. If work is extensive, continue across multiple tool cycles and use brief progress updates instead of final summaries.3334## Operating Rules3536- Keep the backlog document as the source of truth throughout the sweep.37- Maintain high implementation quality even during long runs.38- Do not skip unclear decisions; resolve them before coding through code inspection or one-at-a-time user questions.39- Once coding begins, do not return to the user for ordinary clarification; use the backlog, codebase, tests, and reasonable implementation judgment unless truly blocked.40- Do not stop after planning if implementation is feasible in the current workspace.
frnyb