---

name: to-pr description: Use when the user types /to-pr, asks to prepare or open a PR, or wants Claude to standardize branch checks, validation, a suggested commit message, and draft PR creation for this repo. Follows the repo PR template, develop base branch, and the repo-root Python quality gate (ruff, black, pytest). version: "1.0.0"

To PR

Prepares and opens a GitHub pull request for this repository using the documented workflow, without creating commits or pushing branches.

When to use

• When the user types /to-pr
• When the user asks Claude to prepare, publish, or open a PR
• After the implementation is complete and ready for review handoff

Preconditions

• Run git and gh commands from the repo root.
• Run validation from the repo root (Python project, no subfolder build step).
• Do not create commits in this skill.
• Do not push branches in this skill. If the branch is not already on origin, stop and ask the user to push it manually.
• A linked GitHub issue is not required — this is a solo, course-scale project (see docs/INDEX.md). If an issue exists, link it; if not, proceed without one.

Workflow

1. Inspect scope first with git status -sb and git diff --stat. If the worktree includes unrelated changes, do not stage everything; ask which files belong in scope.
2. Check the branch. Never open a PR from develop or main. Branch names should follow feature/..., fix/..., chore/..., docs/..., refactor/..., or test/..., optionally with an issue number (see CONTRIBUTING.md).
3. If a related issue exists and its context is unclear, fetch it with gh issue view <number> --comments before drafting the PR summary.
4. Verify GitHub CLI readiness with gh --version and gh auth status. If auth is missing, stop and ask the user to authenticate.
5. Run the required local quality gate from the repo root:

ruff check .
black --check .
pytest

6. Generate a suggested commit message using this repo's convention (see CONTRIBUTING.md): a single line, type(scope): description, no body unless the user asks for one, and never a Co-Authored-By: Claude trailer.
7. Confirm the branch is already ready for review. If there are uncommitted changes or unpushed commits that should be part of the PR, stop and ask the user to handle commit/push manually before continuing.
8. Open a draft PR targeting develop with gh pr create --draft --base develop.
9. Use .github/PULL_REQUEST_TEMPLATE.md for the PR body and fill every section that applies. If there's no linked issue, write Not applicable under Related Issue instead of leaving it blank or fabricating one.
10. Keep the PR text high-signal. Prefer short factual statements tied to the actual diff. Avoid filler, vague benefits, generic AI phrasing, and claims like "improves maintainability" unless the PR body explains exactly how.
11. After creation, report the suggested commit message, branch name, validation status, and PR URL.

Safety rules

• Never stage unrelated user changes silently.
• Default to a draft PR unless the user explicitly asks for ready-for-review.
• Never create a commit or push a branch from this skill.
• If ruff, black --check, or pytest fail, stop and fix or report the failures before opening the PR.
• Never pad the PR description with low-information text just to make sections look fuller.