Our review
Opens a pull request to PyPSA/pypsa-usa following that repo's conventions: base-branch selection, push remote, pre-push gates, and PR body drafting.
Strengths
- Encodes repo policy: `develop` as default base, integration-branch detection via `git merge-base`, and upstream-vs-fork push decided from the GitHub push permission
- Runs a mandatory gauntlet — clean tree, base merged in, `pre-commit run --files`, and `pytest -m fast` — before anything is pushed
- Scales its requirements with change size and opens the PR as a draft when Tier B or equivalence evidence is missing
- Watches the `fast-tests` check with `gh pr checks --watch` and fixes failures in-session until green
Limitations
- Tightly coupled to PyPSA/pypsa-usa: branch names, pytest markers, PR template and test paths are hardcoded
- Assumes an authenticated `gh` CLI and correctly configured `upstream`/`origin` remotes
- Model invocation is disabled, so the user must type `/pr` explicitly; the assistant will not trigger it on its own
Use it when a pypsa-usa branch is ready to push and you want a convention-compliant PR without redoing the checks by hand.
Don't use it for another repository, for a PR targeting `master`, or when you want manual control over every push and drafting step.
Security analysis
CautionThe skill uses powerful network and version-control actions (git push, gh pr create, gh api) but for a clearly scoped, legitimate purpose: opening a PR to PyPSA/pypsa-usa following repo conventions. It does not instruct destructive, exfiltrating, or obfuscated actions. The standing permission to push and open PRs warrants caution, not a risky rating.
- •Grants standing permission to push a branch and open a pull request without further confirmation.
- •Executes network-mutating commands (git push, gh pr create) to a specific repository.
- •Runs repository tests (pytest, pre-commit) which may execute code from the working tree.
Examples
/pr/pr — this branch closes issue #412, please add the Closes line to the PR body./pr — I changed files under workflow/rules/, tell me whether to also run the integration tests before opening.name: pr description: Open a pull request to PyPSA/pypsa-usa following repo conventions disable-model-invocation: true
Open a PR to PyPSA/pypsa-usa
Invoking /pr is standing permission to push the branch and open the PR — no
further confirmation for those two actions. Ask the user only where a step
below says to ask.
1. Pick the base branch
The base is develop on PyPSA/pypsa-usa. Never master — if the user asks
for master, stop and remind them changes land on develop and flow to
master in releases.
Integration-branch exception: when the branch descends from an active
integration branch (a long-lived upstream branch such as v1-epic), target
that branch instead. Detect it:
git fetch upstream develop v1-epic
git merge-base HEAD upstream/develop
git merge-base HEAD upstream/v1-epic
If the merge-base with the integration branch is a descendant of the
merge-base with develop, the branch was cut from the integration branch —
base there.
2. Pick the push remote
gh api repos/PyPSA/pypsa-usa --jq .permissions.push
true → push the head branch to upstream (the PyPSA/pypsa-usa remote).
Otherwise push to the user's fork (origin) and open a cross-repo PR.
3. Gauntlet — every gate green before pushing
- Working tree clean (
git status); commit or stash anything loose with the user's direction. - Branch merges cleanly with the base; rebase or merge the base in if behind.
Leave history otherwise untouched — no squashing. Conventional-commit
titles (
fix(rps): ...) are welcome, not required. pre-commit run --files <changed files>passes.pytest -m fastpasses — Tier A, the same selection CI'sfast-testsjob runs, so a local pass predicts a green check.- Size the change. It is larger when it touches
workflow/scripts/orworkflow/rules/in a way that can alter produced network artifacts, or spans >~300 changed lines / >10 files. For a larger change, ask the user whether to also run Tier B (pytest -m integration, needsdata/andcutouts/) — encourage it, never require it.
4. Draft the body
Fill .github/pull_request_template.md, then add:
-
Testing — which tiers ran and their verbatim results (pass/fail counts).
-
Equivalence (larger changes only) — ask the user whether an equivalence-harness run (
tests/equivalence/) exists for this branch. If yes: paste the report summary and list any deltas-ledger rows (DL-N indocs/superpowers/specs/2026-08-07-deltas-ledger.md) this PR adds or touches. If no: write "No equivalence run for this branch." — stated, never omitted. -
Ask the user whether the PR closes an issue; if so,
Closes #Nat the top. -
Attribution footer:
🤖 Generated with [Claude Code](https://claude.com/claude-code)
5. Open the PR
Open as draft when the change is larger and Tier B / equivalence evidence is missing; otherwise ready-for-review. Mark ready once the evidence lands.
git push <remote> HEAD:<head-branch>
gh pr create --repo PyPSA/pypsa-usa --base <base> [--draft] ...
6. Watch CI
Wait for the fast-tests check (gh pr checks <num> --repo PyPSA/pypsa-usa --watch), fixing failures in-session and pushing until it is green.
e2e-tests runs longer — report its status, don't wait on it.
Done when: PR URL reported to the user, fast-tests green (or its failure
explained), and any skipped evidence (Tier B, equivalence) called out
explicitly in the PR body.
Next.js App Router Expert
Development
A skill that turns Claude into a Next.js App Router expert.
README Generator
Development
Creates professional and comprehensive README.md files for your projects.
API Documentation Writer
Development
Generates comprehensive API documentation in OpenAPI/Swagger format.