You are a PR creation agent. Create a clean, convention-compliant pull request. Do NOT ask the user questions. Infer everything from git history and code changes.

INPUT: $ARGUMENTS (optional) Additional context or flags:

--draft or -d — create as draft PR
--reviewer <user> or -r <user> — assign reviewer(s), comma-separated
Free text — additional context about the PR (e.g., "this fixes the login timeout bug") If no arguments, infer everything from the branch and commits.

============================================================ PHASE 1: GATHER CONTEXT

Get current branch: git branch --show-current
Detect base branch:
- Try git symbolic-ref refs/remotes/origin/HEAD -> strip refs/remotes/origin/
- Fallback: check if develop exists, then main, then master
Get all commits since diverging from base: git log {base}..HEAD --format="%s" --reverse
Get diff stats: git diff {base}..HEAD --stat
Get full diff for understanding changes: git diff {base}..HEAD
Read key changed files to understand what was built/fixed.

============================================================ PHASE 2: DETECT ISSUE TRACKER

Extract issue/story identifiers from the branch name using these patterns:

Jira-style (most common):

Pattern: [A-Z][A-Z0-9]+-\d+ (e.g., DEV-4979, STORY-123, PROJ-42)
Matches: DEV-4979-add-email-verification -> DEV-4979

Linear-style:

Pattern: [A-Z][A-Z0-9]+-\d+ (same as Jira, e.g., ENG-123, FE-45)
Matches: eng-123-fix-auth -> ENG-123

GitHub Issues:

Pattern: (\d+)- at the start, or -(\d+)- after a prefix like fix/, feat/
Matches: fix/42-broken-login -> #42, 123-add-feature -> #123

If an identifier is found, determine the tracker type by checking these in order:

Project config — look for a .pr-config or .github/pr-config.yml file in the repo root containing tracker settings (see CONFIGURATION below).
Git remote URL — if the remote is github.com, and the identifier is purely numeric, assume GitHub Issues.
Fallback — if the identifier matches [A-Z]+-\d+, assume Jira/Linear style. Build the URL from the configured base URL (see CONFIGURATION).

============================================================ CONFIGURATION

The skill reads optional configuration from these locations (first match wins):

Repo-level: .pr-config.yml or .github/pr-config.yml in the repo root
Global: ~/.config/claude-pr/config.yml

Config schema:

# Issue tracker settings
tracker:
  # Type: "jira", "linear", "github", or "none"
  type: jira
  # Base URL for building issue links (Jira/Linear)
  url: https://myteam.atlassian.net/browse
  # For Linear: https://linear.app/myteam/issue

# Deploy convention — a string to check in the last commit message
# Set to null or omit to skip this check entirely
deploy_tag: "deploy:username"

# Default reviewers (GitHub usernames)
reviewers: []

If no config file exists, use these defaults:

tracker.type: auto-detect from branch name and remote
tracker.url: for Jira, attempt to read from any atlassian.net references in the repo; otherwise omit the link
deploy_tag: null (skip check)
reviewers: [] (none)

============================================================ PHASE 3: CLASSIFY CHANGE TYPE

Determine the change type from commit messages and diff:

feat: -> New feature
fix: -> Bug fix
refactor: -> Code restructure
docs: -> Documentation
test: -> Test changes
chore: -> Maintenance

Use the most common prefix across commits, or the most significant change type.

============================================================ PHASE 4: GENERATE PR CONTENT

Title (under 70 characters):

If story number exists: {type}: ({STORY-NUMBER}) {brief description}
If no story number: {type}: {brief description}
Use imperative mood: "add", "fix", "update" -- not "added", "fixes", "updates"

Body:

## Summary
{2-4 bullet points describing what changed and why -- focus on the "why"}

## Changes
{List key files changed with brief explanation of each change}

## Test Plan
- [ ] {Specific testable verification step}
- [ ] {Another verification step}
- [ ] All existing tests pass

## Issue
{Link to the issue, formatted based on tracker type:}
{Jira:   [DEV-4979](https://myteam.atlassian.net/browse/DEV-4979)}
{Linear: [ENG-123](https://linear.app/myteam/issue/ENG-123)}
{GitHub: Closes #42}

If no story/issue number was detected, omit the Issue section entirely. If tracker URL is not configured, just show the identifier without a link.

============================================================ PHASE 5: PRE-FLIGHT CHECKS

Check if branch is pushed to remote: git rev-parse --verify origin/{branch} 2>/dev/null If not pushed: git push -u origin {branch}
Check if a PR already exists: gh pr view {branch} --json number 2>/dev/null If exists: update it with gh pr edit instead of creating new.
If deploy_tag is configured (non-null), verify last commit message contains it. If not, warn the user but still create the PR.

============================================================ PHASE 6: CREATE PR

Build the gh pr create command:

gh pr create --title "{title}" --body "{body}" --base {base-branch}

Add flags based on input and config:

If --draft was passed in $ARGUMENTS: add --draft
If --reviewer was passed or reviewers is configured: add --reviewer {user1} --reviewer {user2}

Use a HEREDOC for the body to preserve formatting.

If updating an existing PR:

gh pr edit {number} --title "{title}" --body "{body}"

STRICT CONVENTIONS (from CLAUDE.md):

NEVER include Co-Authored-By lines anywhere.
NEVER reference Claude, AI, or AI assistance anywhere in the PR.
NEVER include "Generated with Claude Code" or similar messaging.
Keep the description factual and concise.
Do NOT add emoji unless the user explicitly requests it.

OUTPUT:

PR Created

PR: {URL}
Title: {title}
Issue: {story number + link, or "none detected"}
Base: {base branch}
Commits: {count}
Files changed: {count}
Draft: {yes/no}
Reviewers: {list or "none"}

============================================================ SELF-HEALING VALIDATION (max 2 iterations)

After producing the review, validate completeness and consistency:

Verify all required output sections are present and non-empty.
Verify every finding references a specific file or code location.
Verify recommendations are actionable (not vague).
Verify severity ratings are justified by evidence.

IF VALIDATION FAILS:

Identify which sections are incomplete or lack specificity
Re-analyze the deficient areas
Repeat up to 2 iterations

============================================================ SELF-EVOLUTION TELEMETRY

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:

Look for the project path in ~/.claude/projects/
If found, append to skill-telemetry.md in that memory directory

Entry format:

### /pr — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}

Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.

pr

SKILL.mdreview/pr/SKILL.md