/pr-create

Auto-create PR based on Git change analysis

Creates Pull Requests automatically by analyzing your Git changes for a smoother workflow.

Usage

# Auto-create PR from your changes
git add . && git commit -m "feat: Implement user authentication"
"Create a Draft PR with the right description and labels"

# Keep your existing template
cp .github/PULL_REQUEST_TEMPLATE.md pr_body.md
"Fill in the blanks but keep the template structure intact"

# Mark as ready when done
gh pr ready
"Switch to Ready for Review after checking quality"

Basic Examples

# 1. Create branch and commit
git checkout main && git pull
git checkout -b feat-user-profile
git add . && git commit -m "feat: Implement user profile feature"
git push -u origin feat-user-profile

# 2. Create PR
"Please create a PR:
1. Check what changed with git diff --cached
2. Use the PR template from .github/PULL_REQUEST_TEMPLATE.md
3. Pick up to 3 labels that match the changes
4. Create it as a Draft (keep HTML comments)"

# 3. Make it ready after CI passes
"Once CI is green, mark the PR as Ready for Review"

Execution Steps

1. Create Branch

# Branch naming: {type}-{subject}
git checkout main
git pull
git checkout -b feat-user-authentication

# Confirm you're on the right branch
git branch --show-current

2. Commit

# Stage your changes
git add .

# Commit with a clear message
git commit -m "feat: Implement user authentication API"

3. Push to Remote

# First push (sets upstream)
git push -u origin feat-user-authentication

# Later pushes
git push

4. Create Draft PR with Automatic Analysis

**Step 1: Analyze Changes**

# See what files changed
git diff --cached --name-only

# Review the actual changes (first 1000 lines)
git diff --cached | head -1000

**Step 2: Auto-generate Description**

# Template priority:
# 1. Keep existing PR description as-is
# 2. Use .github/PULL_REQUEST_TEMPLATE.md
# 3. Fall back to default template

cp .github/PULL_REQUEST_TEMPLATE.md pr_body.md
# Fill empty sections only - don't touch HTML comments or separators

**Step 3: Auto-select Labels**

# Get available labels (non-interactive)
"Retrieve available labels from .github/labels.yml or GitHub repository and automatically select appropriate labels based on changes"

# Auto-selection by pattern matching (max 3)
# - Documentation: *.md, docs/ → documentation|docs
# - Tests: test, spec → test|testing
# - Bug fixes: fix|bug → bug|fix
# - New features: feat|feature → feature|enhancement

**Step 4: Create PR via GitHub API (Preserve HTML Comments)**

# Create PR
"Create a Draft PR with the following information:
- Title: Auto-generated from commit message
- Description: Properly filled using .github/PULL_REQUEST_TEMPLATE.md
- Labels: Auto-selected from changes (max 3)
- Base branch: main
- Preserve all HTML comments"

**Method B: GitHub MCP (Fallback)**

// Create PR while preserving HTML comments
mcp__github__create_pull_request({
  owner: "organization",
  repo: "repository",
  base: "main",
  head: "feat-user-authentication",
  title: "feat: Implement user authentication",
  body: prBodyContent, // Full content including HTML comments
  draft: true,
  maintainer_can_modify: true,
});

Auto Label Selection System

Determining from File Patterns

• **Documentation**: `*.md`, `README`, `docs/` → `documentation|docs|doc`
• **Tests**: `test`, `spec` → `test|testing`
• **CI/CD**: `.github/`, `*.yml`, `Dockerfile` → `ci|build|infra|ops`
• **Dependencies**: `package.json`, `pubspec.yaml` → `dependencies|deps`

Determining from Content

• **Bug fixes**: `fix|bug|error|crash|repair` → `bug|fix`
• **New features**: `feat|feature|add|implement|new-feature|implementation` → `feature|enhancement|feat`
• **Refactoring**: `refactor|clean|restructure` → `refactor|cleanup|clean`
• **Performance**: `performance|perf|optimize` → `performance|perf`
• **Security**: `security|secure` → `security`

Constraints

• **Max 3 labels**: Upper limit for automatic selection
• **Existing labels only**: Prohibited from creating new labels
• **Partial match**: Determined by keyword inclusion in label names

Project Guidelines

Basic Approach

1. **Always start as Draft**: All PRs must be created in Draft state 2. **Gradual quality improvement**: Phase 1 (Basic implementation) → Phase 2 (Add tests) → Phase 3 (Update documentation) 3. **Appropriate labels**: Always add up to 3 labels 4. **Use templates**: Always use `.github/PULL_REQUEST_TEMPLATE.md` 5. **Japanese spacing**: Always add half-width space between Japanese text and alphanumerics

Branch Naming Convention

{type}-{subject}

Examples:
- feat-user-profile
- fix-login-error
- refactor-api-client

Commit Messages

{type}: {description}

Examples:
- feat: Implement user authentication API
- fix: Correct login error
- docs: Update README

Template Processing System

Processing Priority

1. **Existing PR description**: Keep everything that's already written 2. **Project template**: Use `.github/PULL_REQUEST_TEMPLATE.md` 3. **Default template**: Use this if nothing else exists

Existing Content Preservation Rules

• **Don't touch existing content**: Leave what's already there alone
• **Fill in the blanks only**: Add content where it's missing
• **Keep functional comments**: Like `<!-- Copilot review rule -->`
• **Keep HTML comments**: All `<!-- ... -->` stay as-is
• **Keep separators**: Things like `---` stay put

Handling HTML Comment Preservation

**Heads up**: GitHub CLI (`gh pr edit`) escapes HTML comments, and shell processing can mess things up with strings like `EOF < /dev/null`.

**How to fix this**:

1. **Use GitHub API's --field option**: This handles escaping properly 2. **Keep it simple**: Skip complex pipes and redirects 3. **Don't remove anything**: Keep all HTML comments and templates intact

Review Comment Respo