/task-to-pr
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.
$ npx -y skills add owainlewis/blueprint --skill task-to-pr --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/task-to-pr
Context preview
The summary Claude sees to decide when to auto-load this skill.
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.
SKILL.md
task-to-pr.SKILL.mdname: task-to-pr
description: "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."
user-invocable: true
argument-hint: "<tasks, tickets, pull requests, or milestone>"
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.
Do not start a task until the tasks it depends on are merged.
Phase 1: Build the code
1. Create or reuse a branch and worktree for the task. Start new work from the latest default branch. 2. Write the code. 3. Run tests that prove the task works, affected failures are handled, and refactors preserve behavior. Run relevant quality checks. If tests cannot cover something, give other proof. 4. Ask a fresh subagent that did not write the code to review it without editing. 5. Fix valid problems, then repeat the tests, quality checks, and review. 6. Commit and push the changes. 7. Create or update one pull request on GitHub. Include a short summary and the current proof. 8. Mark the ticket as `In Review` when possible.
Phase 2: Pass the automated checks
1. Use the GitHub CLI to wait for CI and automated code review when the repository uses them. 2. Fix failures caused by your changes and valid review findings. 3. After changing code, repeat the tests, quality checks, and subagent review. 4. If you changed code, commit and push it. Update the pull request summary and proof when needed. 5. Reply to every automated review finding. Say what you changed or why you made no change. Resolve the thread when it is fully addressed. 6. Wait for the automated checks again. 7. Repeat until all available checks pass and the automated review has no unresolved findings.
If the user asked you to merge the pull requests, merge each one after its automated checks pass. Otherwise, leave it open.
Continue 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. If no remaining task can move forward, explain what is needed.
Read more
name: task-to-pr description: "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." user-invocable: true argument-hint: "<tasks, tickets, pull requests, or milestone>"
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.
Do not start a task until the tasks it depends on are merged.
Phase 1: Build the code
1. Create or reuse a branch and worktree for the task. Start new work from the latest default branch. 2. Write the code. 3. Run tests that prove the task works, affected failures are handled, and refactors preserve behavior. Run relevant quality checks. If tests cannot cover something, give other proof. 4. Ask a fresh subagent that did not write the code to review it without editing. 5. Fix valid problems, then repeat the tests, quality checks, and review. 6. Commit and push the changes. 7. Create or update one pull request on GitHub. Include a short summary and the current proof. 8. Mark the ticket as `In Review` when possible.
Phase 2: Pass the automated checks
1. Use the GitHub CLI to wait for CI and automated code review when the repository uses them. 2. Fix failures caused by your changes and valid review findings. 3. After changing code, repeat the tests, quality checks, and subagent review. 4. If you changed code, commit and push it. Update the pull request summary and proof when needed. 5. Reply to every automated review finding. Say what you changed or why you made no change. Resolve the thread when it is fully addressed. 6. Wait for the automated checks again. 7. Repeat until all available checks pass and the automated review has no unresolved findings.
If the user asked you to merge the pull requests, merge each one after its automated checks pass. Otherwise, leave it open.
Continue 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. If no remaining task can move forward, explain what is needed.
A small set of instructions for AI coding. Blueprint helps agents decide what to build, make focused changes, test them, get an independent review, and open pull requests.
Other skills on blueprint.
- /architecture-review
Reviews a technical proposal before implementation. Use for specs, designs, RFCs, ADRs, architecture proposals, and issues that specify how a system change should work. Finds material ambiguity and flaws in correctness, scalability, performance, security, operations, and proof.
Open skill - /architecture
Explains how an existing system works today. Use for architecture maps, audits, or ARCHITECTURE.md. Return a chat report unless the user asks for a file. Use design for proposed changes.
Open skill - /design
Writes a clear spec for a proposed feature or system change. Use when important product or technical choices must be settled before coding. Covers behavior, interfaces, failures, risks, acceptance criteria, and tests. Use architecture to explain the current system.
Open skill - /improve
Makes existing code easier to understand without changing behavior. Use to simplify structure, remove duplication or dead code, improve names, or remove unnecessary abstractions.
Open skill - /plan
Turns an approved design 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.
Open skill - /review
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.
Open skill

