Opening a Pull Request
This rule guides you through the process of opening a pull request.
IMPORTANT: when running git commands in this process, always use git --no-pager! The terminal will get STUCK if you do not use git --no-pager!
Pre-flight Checks
- Ensure you are on a non-default branch (not
mainormaster).- HARD ERROR: If on a default branch, STOP. Do NOT create a branch yourself. Output an error and instruct the USER to switch to a feature branch.
Information Gathering
- Extract the GitHub Owner and Repository name from output of
git remote -v - Extract ticket or issue ID if present:
- Parse current branch name for ticket/issue patterns (e.g.,
feature/ABC-123,fix/issue-456). - If the branch is ahead of default, check the new commits' messages for ticket/issue references:
git --no-pager log --oneline main..HEAD
- Parse current branch name for ticket/issue patterns (e.g.,
- Resolve the pull request template. Read only the template you will use — do not load the others into context:
- Look in this repository first (
.github/pull_request_template.mdor.github/PULL_REQUEST_TEMPLATE.md; capitalization may vary). If found, use it. - If none, fetch the repository owner's community-health default from their
.githubrepository at the same paths (e.g.gh api "repos/<owner>/.github/contents/.github/pull_request_template.md" --jq .content, base64-decode; try common capitalizations on 404). If found, use it. - If that is also missing, read
references/pull_request_template.mdnext to this skill and use that.
- Look in this repository first (
Preparation
- Commit all uncommitted changes if needed:
- Use a Conventional Commit message.
- Prefer
featorfixtypes. - If a ticket/issue ID exists, include it in square brackets at the end of the message (e.g.,
feat(scope): description... [ABC-123]). - Use existing scopes from commit history if possible; otherwise, omit scope.
- Prefer
- Use a Conventional Commit message.
- Push the changes up to the feature branch.
- HARD ERROR: If this push fails, STOP. Output an error and instruct the USER to investigate. DO NOT continue with the rest of the process.
- Complete the PR template:
- Fill all sections with appropriate info.
- For checklists, check off only items you have completed. Leave others unchecked.
- Do NOT remove template sections unless explicitly instructed by the template.
- When writing about files in the project, hyperlink the filename to the file on the feature branch. Example:
- pattern:
* Added [README.md](https://github.com/<owner>/<repo>/blob/<branch>/docs/README.md) to doc site - example for repo
texarkanine/onairon feature branchfix-ip:* Added [README.md](https://github.com/texarkanine/onair/blob/fix-ip/docs/README.md) to doc site
- pattern:
Opening the Pull Request
- You MUST write the PR body to a temporary file as follows:
- Use
mktempto create a temp file - You MUST write each line using chained
echocommands with&&, single quotes, and proper escaping for single quotes ('''). Example:TEMPFILE=$(mktemp) && echo '# Feature: New User Authentication' > "${TEMPFILE}" && echo '' >> "${TEMPFILE}" && echo 'Implements new user authentication as specified in ABC-123.' >> "${TEMPFILE}" && echo '' >> "${TEMPFILE}" && echo '## Changes' >> "${TEMPFILE}" && echo '- Added OAuth2 integration' >> "${TEMPFILE}" && echo '- Created user session management' >> "${TEMPFILE}" && echo 'This doesn'''t affect existing users.' >> "${TEMPFILE}"
- Use
- Open a draft pull request using the
ghCLI:- Use
--body-file "${TEMPFILE}"for the body. - For the title:
- If only one commit exists and it is a conventional commit, use its message as the title.
- Otherwise, generate a conventional commit-style title.
- Use the
--draftflag. Example:gh pr create --draft --title "feat(auth): implement OAuth2 authentication" --body-file $TEMPFILE
- Use
- Report the result to the user with ONLY and EXACTLY the following message (filling in the
<information>appropriately): Example:PR Opened: [feat(auth): implement OAuth2 authentication](https://github.com/<owner>/<repo>/pull/<pr_number>)