
task-to-pr
Delivers specs or decided tasks as tested, independently reviewed pull requests. Runs the CI and review repair loop, then leaves passing pull requests open unless merging was explicitly authorized.
- Installs
- 418
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/owainlewis/blueprint --skill task-to-pr- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads task-to-pr automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Task to PR
Deliver each task as one focused pull request with proof. The spec is the ticket; accept a Markdown spec, GitHub issue, or decided task with acceptance checks. Do not create a second work definition.
Read required skills directly from their SKILL.md files as instructions for this workflow. Do not invoke them through a skill command that the client blocks.
Prepare
- Read the source, repository instructions, relevant requirements and architecture, code, and tests. Reuse an existing branch, worktree, and pull request when continuing work.
- Confirm the outcome, scope, decisions, and checks are sufficient. If a consequential choice is missing, return to
/specor report the needed decision before implementing. Do not write specs for small, decided work. - Split larger specs with
/planwhen useful. Each task delivers one working result. Identify dependencies and start independent work together when useful.
Deliver and repair
- Create or reuse an isolated branch and worktree. Start independent work from the latest remote default branch. Follow repository naming and worktree rules.
- Implement the task and meaningful tests for changed behavior and affected failures. Update requirements, architecture, and the spec when the change affects them. Keep intended architecture and implementation status accurate.
- Use
/testto prove acceptance and affected rules. Fix failures before committing. - Create a Conventional Commit, push, and open or update the pull request. Follow the repository PR template. Lead with the problem and result; include proof and the source link. Mark it ready for review and move a tracker ticket to Review when supported.
- Use
/reviewwith a fresh subagent that did not implement the change. Wait for configured CI and automated review on the current commit. - Fix valid findings and failures caused by the change. Reply to review findings with the fix or evidence for making no change. Resolve a thread only when fully addressed.
- After changing the implementation, repeat affected
/testchecks and fresh/review, commit, push, and wait for CI and automated review again. Update PR proof. Continue until all available checks pass and no actionable finding remains. - Report a blocker when progress requires a missing decision, permission, unavailable check, or external repair. Do not weaken tests, bypass repository rules, or claim unrun checks passed.
- Record final proof and the PR link in the source spec or task. Update delivery status to reflect the actual result, including whether the PR is open or merged. Update the original tracker item when one exists. Leave passing PRs open for human review by default. Pending human approval is a merge blocker, not a failed implementation check.
Dependencies
Start dependent work only after each prerequisite has an open PR, a fresh
Approve review, and no known blocking finding. Stack its branch on the reviewed
prerequisite. If there are several prerequisites, combine them in dependency
order. Keep each PR diff focused on its own task.
When a prerequisite changes or merges, update dependent branches and PR bases. Repeat affected tests, independent review, and CI against the new base.
Merge only with authority
Explicit /factory or /codex-issue-coordinator use grants their scoped merge
authority. Otherwise merge only when the user asks. Automatic skill selection
does not grant it. Before merging, require:
- Complete scope and acceptance proof on the final commit.
- Passing tests, required CI, and a fresh
/reviewverdict ofApprove. - No unresolved actionable review finding or consequential decision.
- Every repository-required approval.
- A ready, mergeable PR current with its required base.
Merge in dependency order using the repository's preferred method. Never bypass branch protection. Confirm GitHub reports the merge, then update delivery status in the source spec or task and update the original issue and project state. Remove manually created worktrees after merge or close; use the host's lifecycle tools for managed worktrees. Keep open-PR worktrees. Merge authority does not authorize deployment or release publication.
Return
Report each PR, tests, review verdict, CI state, and blocker. Stop with passing PRs open unless scoped merge authority was given. In merge mode, report verified merges and any work that still needs human action.
FAQ
What does the task-to-pr skill do?
Delivers specs or decided tasks as tested, independently reviewed pull requests. Runs the CI and review repair loop, then leaves passing pull requests open unless merging was explicitly authorized.
How do I install task-to-pr?
Run npx skills add https://github.com/owainlewis/blueprint --skill task-to-pr in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/task-to-pr/ (personal) or .claude/skills/task-to-pr/ (project).
Which AI agents can use task-to-pr?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is task-to-pr safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains task-to-pr?
It is published by owainlewis in owainlewis/blueprint. It has 418 recorded installs.
More from owainlewis/blueprint
review
owainlewis/blueprint
Uses a fresh agent to review an implementation change without editing it. Checks behavior, security, regressions, complexity, tests, docs, and missing proof. Use for code, PR, diff, security, second-opinion, or pre-merge reviews.
plan
owainlewis/blueprint
Turns a reviewed spec or decided brief into ordered tasks for separate agent runs. Use for implementation tasks, tracker tickets, or useful milestones. Do not use for one coding task or its short execution outline.
spec
owainlewis/blueprint
Defines one feature or major change: required behavior, technical design, failure handling, and acceptance checks. Use when consequential decisions must be settled before delivery. The spec is the ticket.
tdd
owainlewis/blueprint
Test-first variant of implement: understand the desired behavior, write a failing test, make it pass, then simplify.
refactor
owainlewis/blueprint
Improve the shape of existing code without changing behavior.
improve
owainlewis/blueprint
Makes existing code easier to understand without changing behavior. Use to simplify structure, remove duplication or dead code, improve names, or remove unnecessary abstractions.
Popular code quality & workflow skills
grill-me
mattpocock/skills
A relentless interview to sharpen a plan or design.
improve-codebase-architecture
mattpocock/skills
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
handoff
mattpocock/skills
Compact the current conversation into a handoff document for another agent to pick up.
domain-modeling
mattpocock/skills
Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.
codebase-design
mattpocock/skills
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
diagnosing-bugs
mattpocock/skills
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.