Current version: 0.1.0
issue-driven-delivery is a Codex skill for delivery rounds that need a fixed workflow:
- confirm or refine a plan,
- write the plan into a repository-local
todolist, - split the work into ordered
issues, - pause for user review when requested,
- implement in issue order,
- update progress and review status after each issue,
- report by default only after the whole issue list is complete.
This README is the human-facing overview for GitHub visitors. The actual agent instructions live in SKILL.md.
This skill turns one delivery round into a documented and traceable workflow rooted in the repository itself.
It is designed for cases where the user already has a plan, wants to co-create a plan with Codex, or wants Codex to help consolidate an incomplete plan before execution starts.
Use this skill when you want Codex to:
- discuss and settle the plan before coding,
- create a repository-local work plan under
.work-plans/, - produce both a narrative
todolistand an executableissues.csv, - wait for plan review before implementation when requested,
- execute issues in order and keep tracking artifacts updated,
- finish with a single final report instead of frequent phase summaries.
This skill is not meant for:
- ad-hoc one-off coding tasks that do not need plan artifacts,
- workflows that intentionally skip planning and issue tracking,
- delivery modes where issues are executed in parallel without ordered tracking,
- teams that want status summaries after every phase by default.
The skill follows this default flow:
- Confirm or refine the plan with the user.
- Create
.work-plans/at the repository root. - Write the plan to
.work-plans/<topic>-todolist.md. - Split the plan into
.work-plans/<topic>-issues.csv. - Stop at the documentation stage if the user wants to review the plan first.
- After approval, execute issues in order.
- After each issue, update tracking artifacts before moving to the next one.
- Mark review as passed only after code, documentation, and verification are aligned.
- Give a single consolidated report after all issues are complete unless the user explicitly asks for interim updates.
By default, all delivery artifacts for the round live under .work-plans/.
Recommended filenames:
.work-plans/<topic>-todolist.md.work-plans/<topic>-issues.csv
The todolist is the planning document. It should capture:
- goal and scope,
- confirmed baseline,
- exclusions,
- current gaps or open questions,
- phased plan,
- acceptance criteria,
- execution order.
The issues.csv is the execution tracker. Each row should at least cover:
issue_id,task_title,task_content,status,progress_pct,done_criteria,review_criteria,dependencies,affected_paths,notes.
For the field-level checklist and update discipline, see references/artifact-checklist.md.
This skill assumes a few operating rules:
- Plan sources are flexible: the user may provide the plan directly, co-create it with Codex, or ask Codex to consolidate it.
- Do not enter implementation before the plan is settled.
- Do not mark progress based on intent; only update progress from completed facts.
- Keep issue order aligned with the real implementation order when the user asks for sequential execution.
- Update tracking files before starting the next issue.
- Keep
notesshort and evidence-oriented.
Example requests that should trigger this skill:
Use $issue-driven-delivery to discuss the plan with me first, then write the todolist and issues.Use $issue-driven-delivery for this request, but stop after the plan so I can review it.I already have a plan. Use $issue-driven-delivery to turn it into a todolist and issues.Use $issue-driven-delivery to continue the issues in .work-plans/ and report only after everything is done.
issue-driven-delivery/
├── CHANGELOG.md
├── SKILL.md
├── README.md
├── README.zh-CN.md
├── agents/
│ └── openai.yaml
└── references/
└── artifact-checklist.md
- SKILL.md is the runtime contract for Codex.
- CHANGELOG.md tracks released versions of the skill.
- references/artifact-checklist.md contains the detailed checklist for
todolistandissues.csv. agents/openai.yamlcontains UI metadata for environments that surface skills in a picker or command palette.
This skill currently starts at 0.1.0 as the initial public release.
Versioning is expected to happen at the repository level through Git tags or GitHub Releases, while CHANGELOG.md records the human-readable release history.