Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

workon-pr

Sterne3

Forks1

Aktualisiert27. Januar 2026 um 01:24

Create a pull request using the workon CLI. Use when the user says "workon pr", "create a PR", "open a PR", or indicates code is ready for review.

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

evansoderberg

evansoderberg/workon-cli

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

SKILL.md

readonly

name	workon-pr
description	Create a pull request using the workon CLI. Use when the user says "workon pr", "create a PR", "open a PR", or indicates code is ready for review.
disable-model-invocation	true
allowed-tools	Bash(workon:), Bash(gh:), Bash(git:), Bash(cat:), Read

Create a Pull Request

Steps

Gather context by running these commands:
- Read the PR template: cat .github/PULL_REQUEST_TEMPLATE.md
- Get the diff: git diff origin/HEAD...HEAD or git diff main...HEAD
- Get commit history: git log --oneline origin/HEAD...HEAD or git log --oneline main...HEAD
- Extract ticket ID from branch name (format: username/{ticketid}/...)
Offer code review (ask the user):
- Before creating the PR, ask if they'd like you to run a code review first
- If yes, review the changes for issues, improvements, and potential bugs
- Address any findings before proceeding
Generate content for each section (you are responsible for generating this):
- Title: Concise description of the change (often matches ticket name)
- Summary: 1-2 sentences describing what changed and why
- Description: Detailed explanation referencing specific files/functions changed
- How to Test: Step-by-step verification instructions with expected outcomes
Get explicit user approval:
- Show the user the PR details (title, summary, description, testing instructions)
- Ask: "Ready to create this PR and push to GitHub?"
- WAIT for explicit confirmation (e.g., "yes", "go ahead", "create it")
- Do NOT proceed until you receive explicit approval
Create the PR after receiving approval:
```
workon pr -y --title "..." --summary "..." --ticket "..." --description "..." --testing "..."
```
- Always use -y flag to skip confirmation (user already approved)
- Add --draft if user asks for draft PR or mentions "draft", "WIP", "work in progress"
- Ticket ID is auto-extracted from branch if not provided
- Base branch is auto-detected (main or master)
- Use --base <branch> to override if needed

Important Notes

Do NOT modify the "Best Practices" checklist section in the PR template
The workon CLI fills in the PR template sections automatically

Mehr aus diesem Repository

gleiches Repository

ci-flaky

evansoderberg/workon-cli

Analyze flaky CI tests using CircleCI Insights. Use when investigating test flakiness, triaging CI failures, or deciding which flaky tests to fix next.

2026-03-253

workon-ci-status

evansoderberg/workon-cli

Check CircleCI status for a branch and help fix CI failures.

2026-01-273

workon-comment

evansoderberg/workon-cli

Add a comment to the current ClickUp ticket. Use when the user says "workon comment" or wants to add a comment to the ticket.

2026-01-273

workon-merge

evansoderberg/workon-cli

Merge a pull request and post a merge comment. Only use when explicitly requested.

2026-01-273

workon-pr-status

evansoderberg/workon-cli

Check the status of a pull request including CI checks and approvals.

2026-01-273

workon-pr-update

evansoderberg/workon-cli

Update sections of an existing pull request. Use when the user wants to improve or fix the PR description.

2026-01-273

Create a Pull Request

Steps

Gather context by running these commands:

Read the PR template: cat .github/PULL_REQUEST_TEMPLATE.md
Get the diff: git diff origin/HEAD...HEAD or git diff main...HEAD
Get commit history: git log --oneline origin/HEAD...HEAD or git log --oneline main...HEAD
Extract ticket ID from branch name (format: username/{ticketid}/...)

Offer code review (ask the user):

Before creating the PR, ask if they'd like you to run a code review first
If yes, review the changes for issues, improvements, and potential bugs
Address any findings before proceeding

Generate content for each section (you are responsible for generating this):

Title: Concise description of the change (often matches ticket name)
Summary: 1-2 sentences describing what changed and why
Description: Detailed explanation referencing specific files/functions changed
How to Test: Step-by-step verification instructions with expected outcomes

Get explicit user approval:

Show the user the PR details (title, summary, description, testing instructions)
Ask: "Ready to create this PR and push to GitHub?"
WAIT for explicit confirmation (e.g., "yes", "go ahead", "create it")
Do NOT proceed until you receive explicit approval

Create the PR after receiving approval:

workon pr -y --title "..." --summary "..." --ticket "..." --description "..." --testing "..."

Always use -y flag to skip confirmation (user already approved)
Add --draft if user asks for draft PR or mentions "draft", "WIP", "work in progress"
Ticket ID is auto-extracted from branch if not provided
Base branch is auto-detected (main or master)
Use --base <branch> to override if needed

Important Notes

Do NOT modify the "Best Practices" checklist section in the PR template

The workon CLI fills in the PR template sections automatically