SkillsAdd

smithery/evansoderberg

workon-pr

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

$ npx skills add smithery/evansoderberg --skill workon-pr
View on skills.sh ↗ Website ↗

Also in this package

Other skills from smithery/evansoderberg.

npx skills add smithery/evansoderberg
workon 0

Browse all from smithery/evansoderberg

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Skill metadata

Parsed from SKILL.md frontmatter.

Allowed toolsBash(workon:*), Bash(gh:*), Bash(git:*), Bash(cat:*), Read

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,295 B
  • docs SUMMARY.md 163 B

History

  1. First recorded snapshot · 0 installs

SKILL.md

Create a Pull Request

Steps

  1. Gather context by running these commands:

- Read the PR template: cat .github/PULLREQUESTTEMPLATE.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}/...)

  1. 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

  1. 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

  1. 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

  1. Create the PR after receiving approval:

``bash 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