task-to-pr

Name: task-to-pr
Author: owainlewis

238stars46forks

How to install task-to-pr?

owainlewis/blueprint/task-to-pr

$npx -y skills add owainlewis/blueprint --skill task-to-pr

Installs into the current project.

Summary

Takes one task, ticket, or existing pull request to a tested, independently reviewed, green pull request ready for human merge. Use when the user asks to implement, build, fix, deliver, or take one task or issue to a pull request.

Files · 1

View on GitHub

SKILL.md

1	# Task to PR
2
3	Follow this workflow for the requested task, ticket, or pull request:
4
5	1. Resolve the source. Resume an existing pull request and its linked ticket when one exists. Otherwise fetch the ticket or use the task as the source. Create a ticket only when the user asks or durable tracking improves the handoff or proof. Do not duplicate tickets or pull requests.
6	2. Isolate the work before editing. Resume the branch and worktree for an existing pull request. For new work, fetch the remote and create a dedicated branch and worktree from the latest remote default branch, named with the ticket number or task slug. Follow the repository's location convention and reuse a suitable existing worktree. Remove a manually created worktree after its pull request is merged or closed.
7	3. Read the context. Read the repository instructions and inspect the relevant code.
8	4. Outline the change. Define the smallest complete change and check it against the ticket, task, or pull request. This is a local execution outline, not the `/plan` phase. Do not create tickets or a plan document.
9	5. Implement. Make the change and add tests where necessary.
10	6. Test. Run the `/test` phase, including real-browser checks for browser-rendered behavior.
11	7. Review. Run the `/review` phase with a fresh subagent.
12	8. Address findings. Fix valid review findings, then rerun affected tests and fresh review.
13	9. Publish. Create a Conventional Commit, push the branch, and open or update a ready pull request. Link the ticket when one exists and include test and review evidence.
14	10. Finish CI. Wait for checks to finish. Fix relevant failures and rerun affected tests and review until required checks pass. If no checks are configured, continue.
15	11. Handle current feedback. Inspect the human and bot feedback available at that point. Fix important findings, reply to addressed comments with evidence, and rerun affected tests and fresh review. Do not wait indefinitely for future human feedback.
16
17	Commit and push every post-PR fix before reassessing checks or feedback.
18
19	If the ticket, task, or design is wrong or incomplete, update the source of truth before continuing. Prefer the smallest complete change and no unrelated cleanup.
20
21	Stop when the pull request is green, mergeable, and has no important unresolved feedback currently available. Never merge unless the user explicitly asks. Report an exact blocker when required access, checks, or independent review remain unavailable after safe alternatives are exhausted.

People who liked this also viewed

6 picks

Type

task-to-pr

238stars46forks

View on GitHub

How to install task-to-pr?

owainlewis/blueprint/task-to-pr

$npx -y skills add owainlewis/blueprint --skill task-to-pr

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Task to PR
2
3	Follow this workflow for the requested task, ticket, or pull request:
4
5	1. Resolve the source. Resume an existing pull request and its linked ticket when one exists. Otherwise fetch the ticket or use the task as the source. Create a ticket only when the user asks or durable tracking improves the handoff or proof. Do not duplicate tickets or pull requests.
6	2. Isolate the work before editing. Resume the branch and worktree for an existing pull request. For new work, fetch the remote and create a dedicated branch and worktree from the latest remote default branch, named with the ticket number or task slug. Follow the repository's location convention and reuse a suitable existing worktree. Remove a manually created worktree after its pull request is merged or closed.
7	3. Read the context. Read the repository instructions and inspect the relevant code.
8	4. Outline the change. Define the smallest complete change and check it against the ticket, task, or pull request. This is a local execution outline, not the `/plan` phase. Do not create tickets or a plan document.
9	5. Implement. Make the change and add tests where necessary.
10	6. Test. Run the `/test` phase, including real-browser checks for browser-rendered behavior.
11	7. Review. Run the `/review` phase with a fresh subagent.
12	8. Address findings. Fix valid review findings, then rerun affected tests and fresh review.
13	9. Publish. Create a Conventional Commit, push the branch, and open or update a ready pull request. Link the ticket when one exists and include test and review evidence.
14	10. Finish CI. Wait for checks to finish. Fix relevant failures and rerun affected tests and review until required checks pass. If no checks are configured, continue.
15	11. Handle current feedback. Inspect the human and bot feedback available at that point. Fix important findings, reply to addressed comments with evidence, and rerun affected tests and fresh review. Do not wait indefinitely for future human feedback.
16
17	Commit and push every post-PR fix before reassessing checks or feedback.
18
19	If the ticket, task, or design is wrong or incomplete, update the source of truth before continuing. Prefer the smallest complete change and no unrelated cleanup.
20
21	Stop when the pull request is green, mergeable, and has no important unresolved feedback currently available. Never merge unless the user explicitly asks. Report an exact blocker when required access, checks, or independent review remain unavailable after safe alternatives are exhausted.

People who liked this also viewed

6 picks

Type