Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add owainlewis/blueprint --skill task-to-prgit clone --depth 1 https://github.com/owainlewis/blueprintWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/owainlewis/blueprint/task-to-pr)<a href="https://agentmods.dev/skills/owainlewis/blueprint/task-to-pr"><img src="https://agentmods.dev/badge/skills/owainlewis/blueprint/task-to-pr.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00043 | $0.00909 |
| Opus 5 | $0.00022 | $0.00454 |
| Sonnet 5 | $0.00009 | $0.00182 |
| Haiku 4.5 | $0.00004 | $0.00091 |
Grade A, and why
task-to-pr scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 7d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 68 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Task to PR
Take each task from a decided outcome to a tested and reviewed pull request. Keep one task, branch, and pull request focused on one result.
Review the tasks first. Decide their order, note dependencies, and identify work that can run at the same time. Then make a short plan.
Order dependent work
- Start independent tasks together when useful.
- Start a dependent task only after each prerequisite has an open pull request, an independent
/reviewverdict ofApprove, and no known blocking finding. - Stack dependent work on the prerequisite branch. If a task has several unmerged prerequisites, stack those branches in dependency order before creating the dependent branch.
- When a prerequisite branch or pull request base changes, update every dependent branch to that reviewed state. Repeat
/testand/review. - After a prerequisite merges, retarget its stacked pull requests to the default branch. Repeat the proof against that base.
Phase 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
/testto prove the task works, affected failures are handled, and refactors preserve behavior. - 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
In RevieworReview, when possible. - Use
/reviewwith a fresh subagent that did not write the code. - Fix valid problems, then repeat
/testand/review. Commit and push every reviewed fix before continuing.
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
/testand/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.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 7d ago First seen · 68 lines · 43 tokens per session scan A 31e23dcb2aba
task-to-pr is a skill published in the GitHub repository owainlewis/blueprint (378 stars, last pushed 8d ago), licensed MIT. It adds 43 tokens to every session and 909 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
speckit-resolve-pr
Address actionable review feedback on a pull request, push the fixes, and resolve review threads. Reads the PR comments, updates the code, runs project verification, replies to review threads, and reports what changed.
gsd-pr-branch
Create a clean PR branch by filtering out .planning/ commits — ready for code review.
comet-github-pr-review
A read-only review process for pull requests in Comet's GitHub repositories. A pull request is a proposed code change; the review checks its current code, related issue, comments, merge status, and automated checks.
release-archivist
Close out a spec-superflow change with verification, summary, and archive readiness. Invoke when implementation is complete, verification is underway, or the user asks for a final wrap-up.
review
Adversarial senior review of the spec before any code is written. Constructs a skeptical reviewer whose authority comes from the codebase, §R research, and live best-practice — then tries to REFUTE the spec, not rubber-stamp it. Every finding cites evidence (file:line or source); unverifiable ones are flagged.…
resolve-pr-comments
Evaluate, fix, answer, and reply to GitHub pull request review comments and conversation comments. Handles both change requests (fix or skip) and reviewer questions (explain using reasoning recalled from past Claude Code transcripts). Use when the user asks to "resolve PR comments", "fix review comments", "address PR…