Pull Request

Create pull requests with proper templates and metadata.

Requirements

• PR should use the PR template of the current repository
• Assignee is automatically set by CI (random CODEOWNER)
• Labels are automatically applied by CI based on changed files

Issue Detection

If the branch name contains an issue number (e.g., feat/123-add-feature, fix/45-parser-crash), extract it and fetch the issue details:

gh issue view <number> --json title,body,labels

Use the issue context to:

1. Link the issue using the Closes section format (see below)
2. Inform the PR summary and description from the issue's title and body

If no issue number is found in the branch name, skip this step.

Issue Link Format

Always use this exact format when linking issues in a PR body. Replace the repo's ## Related Issues template section with a ## Closes section:

## Closes

- Closes #123
- Closes #456
- Relates to #789

This format ensures GitHub renders rich issue links (with title, status, etc.) automatically. Do not append the issue title after the number — GitHub handles that via its rich formatting.

Rules:

• Use a ## Closes heading (not ## Related Issues)
• Each link is a bullet point: - Closes #<number>
• Use Relates to instead of Closes for issues that are related but not fully resolved by this PR
• Do not add any text after the issue number (no titles, no descriptions)

Usage

When asked to create a PR:

1. Ensure pre-commit checks pass (lint, test, Docker if applicable)
2. Push the branch to remote
3. Detect associated issue from branch name (see above)
4. Read the repo's PR template: look for .github/PULL_REQUEST_TEMPLATE.md
5. Fill in the PR template with actual content:
   • Summary: Concise description of what the PR does and why
   • Type: Check the matching type checkbox (feat, fix, test, etc.)
   • Changes Made: Bullet list of specific changes
   • Closes: Replace ## Related Issues with ## Closes section using the issue link format specified above
   • Testing: Check boxes for tests that were added/run
   • Quality Checks: Check boxes for lint/format/build that passed
   • Checklist: Check all applicable items
   • Leave sections like Breaking Changes, Screenshots, Deployment Notes with their placeholder comments if not applicable

6. Create the PR:

   gh pr create --title "<title>" --body "<filled template>"

   Use a HEREDOC for the body to preserve formatting.

Important: Do NOT use gh pr create --fill — it only uses the commit message and skips the PR template entirely. Always read and fill the template.

Note: Assignees and labels are handled automatically by GitHub Actions:

• pr-auto-assign.yml - Assigns a random CODEOWNER
• pr-labeler.yml - Labels based on changed files (see .github/labeler.yml)

Checklist

Before creating PR:

• All linting passes
• All tests pass
• Branch is pushed to remote
• Associated issue detected and linked (if branch has issue number)
• PR template read and filled with actual content
• PR created with filled template (not --fill)