Pr Creator
Have your coding agent open a pull request that respects branch protection, conventional commits, and your repo’s PR template.
Overview
pr-creator is an agent skill for the Ship phase that enforces branch safety, commits, and template-aligned pull request authoring.
Install
npx skills add https://github.com/google-gemini/gemini-cli --skill pr-creatorWhat is this skill?
- 4-step workflow: branch guard, commit check, template discovery, template-driven PR body
- Hard rule: never commit or PR from main—creates and switches to a descriptive branch first
- Searches `.github/pull_request_template.md`, `.github/PULL_REQUEST_TEMPLATE.md`, and template folders
- Stages uncommitted work with conventional `type(scope): description` commit messages before PR creation
- 4-step PR workflow
- 3 common GitHub PR template lookup paths
Adoption & trust: 2k installs on skills.sh; 105k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You want an agent to open a PR but risk committing on main, leaving dirty state, or ignoring your repository’s PR template.
Who is it for?
Solo builders using agentic git flows who already use PR templates and conventional commits.
Skip if: Repos without git, trunk-only workflows with no PRs, or teams that forbid agent-driven commits without explicit human review.
When should I use this skill?
Use when asked to create a pull request (PR) so it follows the repository’s templates and standards.
What do I get? / Deliverables
You get a branch-correct, fully committed changeset and a PR draft filled out from the repo template, ready to push and open on the host.
- Descriptive feature branch (if was on main)
- Commits with conventional messages
- PR title and body matching repo template
Recommended Skills
Journey fit
How it compares
Use instead of asking the model to “write PR text” without branch checks or template discovery.
Common Questions / FAQ
Who is pr-creator for?
Indie and solo developers who ship via pull requests and want their coding agent to mirror repo standards for branches, commits, and template sections.
When should I use pr-creator?
Use it in Ship when you have local changes ready for review—after a feature branch exists or when you need the skill to create one, and before you paste a PR into GitHub or GitLab.
Is pr-creator safe to install?
It instructs git commit and branch operations; review the Security Audits panel on this Prism page and only run it in repos you trust, with human review before merge.
SKILL.md
READMESKILL.md - Pr Creator
# 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.