Skills › Software Development › Dev workflow & Git
pr-creator
Use this skill when asked to create a pull request (PR). It ensures all PRs follow the repository's established templates and standards.
The full skill
—
name: pr-creator
description:
Use this skill when asked to create a pull request (PR). It ensures all PRs
follow the repository's established templates and standards.
—
# Pull Request Creator
This skill guides the creation of high-quality Pull Requests that adhere to the
repository's standards.
## Workflow
Follow these steps to create a Pull Request:
1. **Branch Management**: **CRITICAL:** Ensure you are NOT working on the
`main` branch.
– Run `git branch –show-current`.
– If the current branch is `main`, you MUST create and switch to a new
descriptive branch:
“`bash
git checkout -b <new-branch-name>
“`
2. **Commit Changes**: Verify that all intended changes are committed.
– Run `git status` to check for unstaged or uncommitted changes.
– If there are uncommitted changes, stage and commit them with a descriptive
message before proceeding. NEVER commit directly to `main`.
“`bash
git add .
git commit -m "type(scope): description"
“`
3. **Locate Template**: Search for a pull request template in the repository.
– Check `.github/pull_request_template.md`
– Check `.github/PULL_REQUEST_TEMPLATE.md`
– If multiple templates exist (e.g., in `.github/PULL_REQUEST_TEMPLATE/`),
ask the user which one to use or select the most appropriate one based on
the context (e.g., `bug_fix.md` vs `feature.md`).
4. **Read Template**: Read the content of the identified template file.
5. **Draft Description**: Create a PR description that strictly follows the
template's structure.
– **Headings**: Keep all headings from the template.
– **Checklists**: Review each item. Mark with `[x]` if completed. If an item
is not applicable, leave it unchecked or mark as `[ ]` (depending on the
template's instructions) or remove it if the template allows flexibility
(but prefer keeping it unchecked for transparency).
– **Content**: Fill in the sections with clear, concise summaries of your
changes.
– **Related Issues**: Link any issues fixed or related to this PR (e.g.,
"Fixes #123").
6. **Preflight Check**: Before creating the PR, run the workspace preflight
script to ensure all build, lint, and test checks pass.
“`bash
npm run preflight
“`
If any checks fail, address the issues before proceeding to create the PR.
7. **Push Branch**: Push the current branch to the remote repository.
**CRITICAL SAFETY RAIL:** Double-check your branch name before pushing.
NEVER push if the current branch is `main`.
“`bash
# Verify current branch is NOT main
git branch –show-current
# Push non-interactively
git push -u origin HEAD
“`
8. **Create PR**: Use the `gh` CLI to create the PR. To avoid shell escaping
issues with multi-line Markdown, write the description to a temporary file
first.
“`bash
# 1. Write the drafted description to a temporary file
# 2. Create the PR using the –body-file flag
gh pr create –title "type(scope): succinct description" –body-file <temp_file_path>
# 3. Remove the temporary file
rm <temp_file_path>
“`
– **Title**: Ensure the title follows the
[Conventional Commits](https://www.conventionalcommits.org/) format if the
repository uses it (e.g., `feat(ui): add new button`,
`fix(core): resolve crash`).
## Principles
– **Safety First**: NEVER push to `main`. This is your highest priority.
– **Compliance**: Never ignore the PR template. It exists for a reason.
– **Completeness**: Fill out all relevant sections.
– **Accuracy**: Don't check boxes for tasks you haven't done.