pr-create

name	pr-create
version	1.0.0
description	Create a pull request and request review
uses	["development/git"]
requires	{"tools":["git","gh"],"env":[]}
security	{"risk_level":"write","capabilities":["git:read","github:pr:write"],"requires_approval":false}

PR Create

Create a pull request after code is committed and pushed, then request review. This skill handles the transition from local development to code review.

Platform note: This skill currently uses GitHub (gh CLI). The methodology is platform-agnostic; only the tool commands are GitHub-specific.

Execution Model

This is a bash skill (handler: type: bash). When pr_create is invoked, the executor runs gh pr create with the provided parameters. The tool schema in tool.yaml defines the external contract; the executor handles the GitHub CLI call directly.

When to Use

• Code is committed to a feature branch and pushed to remote
• Tests are passing locally
• Ready for code review

Methodology

1. Verify Ready State

Before creating a PR:

• Confirm on a feature branch (not main)
• Confirm working directory is clean
• Confirm all commits are pushed to remote
• Confirm tests pass locally

2. Review What's in the PR

Check what will be included:

• View commits since diverging from base branch
• View the full diff against base
• Ensure no unintended changes are included

3. Write PR Description

Structure:

• Title: Conventional format — type(scope): short description (under 70 characters)
• Summary: What this PR does and why
• Changes: List of specific changes
• Test plan: How to verify the changes work
• Linked issues: Closes #N to auto-close on merge

4. Create the PR

Create with clear title and structured body. Note the returned PR number for tracking.

5. Request Review and Update Task Status

After creation:

1. Update task status: If you have a task_id, call POST /tasks/{task_id}/status with {"status": "review"} to move the task into the review phase.
2. Publish to bus: Use the bus_publish tool with channel="work" and type="pr_created". Include the PR number, title, URL, related issue, and a brief summary in the message payload. This triggers reviewer agents to pick up the PR.

Output Format

## PR Created

- PR number: [#N]
- Title: [title]
- Base: [base branch]
- Head: [feature branch]
- URL: [PR URL]
- Review requested: [yes/no]

Quality Criteria

• PR is created from a feature branch, not main
• All commits are pushed before creation
• Title follows conventional format and is under 70 characters
• Description includes summary, changes, test plan, and linked issues
• Review is requested (not left without reviewers)
• Task status is updated to review via POST /tasks/{task_id}/status
• Bus notification is published via bus_publish tool for automated review pickup

Common Mistakes

• Creating PR from main: PRs should come from feature branches. Creating from main means you're trying to merge main into main.
• Not pushing first: Creating a PR before pushing commits means the PR shows no changes.
• Vague title: "Fix stuff" or "Updates" — use conventional commit format with scope.
• Missing test plan: Reviewers need to know how to verify your changes. Always include a test plan.
• Not linking issues: Missing Closes #N means the issue won't auto-close when the PR merges.
• Huge PRs: PRs with 20+ files are hard to review. If possible, split into smaller, focused PRs.

Completion

PR creation is complete when:

• PR is created with descriptive title and body
• Linked to relevant issue(s)
• Review is requested
• PR number is noted for tracking
• Task status is updated to review
• Bus notification is published via bus_publish tool