task-to-pr
Original:🇺🇸 English
Translated
Completes one or more tasks. Creates one tested and reviewed pull request for each task. Use to implement, build, fix, or deliver tasks, tickets, pull requests, or a milestone.
2installs
Sourceowainlewis/blueprint
Added on
NPX Install
npx skill4agent add owainlewis/blueprint task-to-prTags
Translated version includes tags in frontmatterSKILL.md Content
View Translation Comparison →Task to PR
Review the tasks you were given. Decide the order and which tasks can run at the same time. Make a short plan.
Complete each task in two phases. Keep working without waiting for the user while any task can make progress.
Independent tasks may start together. Start a dependent task after every prerequisite has an open pull request, an independent verdict of , and no known blocking finding. Stack dependent work on the prerequisite branch. If several unmerged prerequisites feed one task, stack those prerequisite branches in dependency order before branching the dependent task. When a prerequisite branch or pull request base changes, update every dependent branch to that reviewed state and repeat and . Retarget each stacked pull request to the default branch after its prerequisite merges, then repeat the proof against that base.
/reviewApprove/test/reviewPhase 1: Build the code
- Create or reuse a branch and worktree for the task. Start independent work from the latest default branch and dependent work from its reviewed prerequisite or stacked base.
- Write the code.
- Use to prove the task works, affected failures are handled, and refactors preserve behavior.
/test - Commit and push the changes.
- Create or update one pull request on GitHub. Include a short summary and the current proof, then mark it ready for review.
- Move the ticket to the repository's review state, such as or
In Review, when possible.Review - Use with a fresh subagent that did not write the code.
/review - Fix valid problems, then repeat and
/test. Commit and push every reviewed fix before continuing./review
Phase 2: Pass the automated checks
- Use the GitHub CLI to wait for CI and automated code review when the repository uses them.
- Fix failures caused by your changes and valid review findings.
- If a fix needs a product or technical decision that the task does not contain, stop that task and report the missing decision.
- After changing code, repeat and
/test./review - If you changed code, commit and push it. Update the pull request summary and proof when needed.
- Reply to every automated review finding. Say what you changed or why you made no change. Resolve the thread when it is fully addressed.
- Wait for the automated checks again.
- Repeat until all available checks pass and the automated review has no unresolved findings.
- Update the ticket with final proof and the pull request link when possible. Keep it in the repository's review state while the pull request is open.
If the user asked you to merge the pull requests, merge them in dependency order after their automated checks pass, the final verdict is , required approvals are present, and no review thread is unresolved. Explicitly naming , or explicitly telling its coordinator that agents may merge, is a merge request for only the issues in its supplied batch. Automatic skill selection is not merge authority. After each prerequisite merges, retarget its dependents to the default branch, update them to that base, and repeat , , CI, and automated review before merging them. Never bypass repository rules. Wait until GitHub reports each pull request as merged before marking its ticket complete when possible. Otherwise, leave it open.
/reviewApprove/codex-issue-coordinator/test/reviewContinue with every task that can make progress. Stop when every task has a pull request with all available checks passing and no unresolved automated review findings. When merge was requested, stop only after every in-scope pull request is merged and its ticket is complete when possible. If no remaining task can move forward, explain what is needed.