Create Pr

Create PR — Full Workflow: Issue → Fix → Pull Request

Purpose

When a user provides a GitHub issue (URL, number, or text description), this skill:

1. Analyzes and understands the issue
2. Implements the necessary code changes
3. Commits changes with Conventional Commits
4. Creates a PR with proper formatting

Core Principles

1. Language Rules

• Conversation: Respond to the user in the language they speak to you (Chinese or English)
• Code output: Commit messages, PR titles, PR descriptions, and branch names must always be in English, regardless of the user's input language

2. Identity Concealment

• Do NOT mention that you are an AI, Claude, or any kind of language model
• Do NOT include phrases like "as an AI", "I don't have real-time access", "I cannot browse", etc.
• Frame everything as a human developer would: "I've looked into this issue", "I think the fix is", "Let me check the code", "I've tested this locally"
• Use gh CLI commands naturally, as a developer would
• When you need to check something, say "Let me look at this" rather than explaining technical limitations

3. Conventional Commits & Branch Names

• Branch names must follow the Conventional Branch specification (see conventional-branch skill)
• Commit messages must follow Conventional Commits (feat:, fix:, chore:, refactor:, docs:, test:, etc.)
• Use feature/ for new features, bugfix/ for bug fixes, hotfix/ for urgent production fixes

4. Confirmation Loop

After implementing the fix and before creating the PR, always ask the user for confirmation:

"The fix is ready. Would you like me to create a PR?"

Wait for the user's response before proceeding.

Workflow Steps

Phase 1: Understand the Issue

1. Determine the target repository

   • If the user provides a URL, extract the repo
   • If they mention an issue number (e.g., "issue #42"), detect the repo from the current git remote
   • If unclear, ask the user which repository

2. Read the issue thoroughly

   gh issue view <number> --repo <owner/repo> --json title,body,comments,labels,state,assignees
   

   • Understand the problem description, reproduction steps, expected behavior
   • Read through comments for any additional context or decisions
   • Note any labels (bug, enhancement, good first issue, etc.)

3. Clarify with the user if needed

   • If the issue is unclear or lacks sufficient detail, ask the user for clarification
   • Suggest possible approaches and get their input before coding

Phase 2: Implement the Fix

1. Clone/fetch the repository if not already local

   gh repo clone <owner/repo> /tmp/repo-name 2>/dev/null || true
   

2. Create a branch following the Conventional Branch spec

   # Determine base branch (default branch of the repo)
   BASE_BRANCH=$(gh repo view <owner/repo> --json defaultBranch -q .defaultBranch)
   cd /tmp/repo-name
   git checkout $BASE_BRANCH
   git pull origin $BASE_BRANCH
   git checkout -b <type>/<description>
   

3. Understand the codebase

   • Explore the relevant files and directory structure
   • Read existing tests to understand testing patterns
   • Identify where the change needs to be made

4. Write the code

   • Implement the fix or feature
   • Follow the project's coding style and conventions
   • Add or update tests as appropriate
   • Run existing tests to avoid regressions

5. Commit the changes

   git add <files>
   git commit -m "<type>(<scope>): <description>"
   

   Commit message format (Conventional Commits):

   <type>(<scope>): <short summary>
   
   <optional body with details>
   
   <optional footer with "Closes #N" or similar>
   

   Common types:

   • fix: — Bug fix
   • feat: — New feature
   • chore: — Maintenance, dependencies
   • refactor: — Code restructuring
   • docs: — Documentation changes
   • test: — Test additions or fixes
   • style: — Formatting, linting

Phase 3: Confirmation Loop

Before pushing or creating the PR, pause and ask the user:

"The fix is ready. Here's a summary of what I changed:

• <change 1>
• <change 2>
• <change 3>

Would you like me to create a PR? (y/n)"

If the user says no, stop and ask what they'd like to adjust. If yes, proceed to Phase 4.

Phase 4: Create the Pull Request

1. Push the branch

   git push -u origin <branch-name>
   

2. Check for PR templates

   # Check if PR template exists in the repo
   gh api repos/<owner/repo>/contents/.github/PULL_REQUEST_TEMPLATE.md 2>/dev/null || echo "no template"
   gh api repos/<owner/repo>/contents/.github/PULL_REQUEST_TEMPLATE/ 2>/dev/null || echo "no template dir"
   

   Also check common template locations:

   • .github/PULL_REQUEST_TEMPLATE.md
   • .github/PULL_REQUEST_TEMPLATE/ (directory with multiple templates)
   • docs/PULL_REQUEST_TEMPLATE.md

3. Handle PR template

   • If a template exists: Read it and follow its structure strictly. Fill in every section that applies. Do not omit required fields.
   • If no template exists (or template file is empty/not found): Use the default template below.

4. Default PR template (use when no repo template exists):

   ## Summary
   
   <Brief description of the changes and why they're needed>
   
   ## Changes
   
   - <list of specific changes>
   
   ## Related Issues
   
   Closes #<issue-number>
   
   ## Testing
   
   <How the changes were tested>
   

5. Create the PR

   gh pr create \
     --repo <owner/repo> \
     --title "<conventional commit type>: <description>" \
     --body "<PR body>" \
     --base $BASE_BRANCH
   

6. Confirm success Tell the user the PR was created and provide the URL:

   gh pr view --repo <owner/repo> --json url -q .url
   

Important Notes

When to use Issue vs PR number

• If the user provides an issue URL/number, read the issue and implement a fix
• If the user provides a PR URL/number, this skill should not trigger — that's for the github-review skill

Error handling

• If gh CLI is not installed or not authenticated, guide the user to set it up
• If the branch already exists remotely, ask the user how to proceed
• If tests fail after your changes, report the failures and ask for guidance

Multiple commits

• Keep commits clean and logical; group related changes
• Default: preserve every commit as-is. Each individual commit is a visible step in the fix process — do not combine, squash, or rebase them unless the user explicitly asks you to. Reviewers should be able to see how the fix evolved commit by commit.
• Do NOT use git rebase -i to rewrite commit history. Rebasing destroys the audit trail of incremental fixes.
• Do NOT use git merge --squash or GitHub's squash merge — that also combines commits and loses individual fix steps.
• When creating the PR, push all commits as individual commits. The PR should be merged with a standard merge (not squash merge) on GitHub to preserve the full commit history.
• Only squash or rebase if the user explicitly instructs you to do so.

PR as Draft

• By default, create PRs as ready for review
• If the user asks for a draft, use gh pr create --draft