Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add gjoranv/claude-plan-skills --skill gh-create-prgit clone --depth 1 https://github.com/gjoranv/claude-plan-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/gjoranv/claude-plan-skills/gh-create-pr)<a href="https://agentmods.dev/skills/gjoranv/claude-plan-skills/gh-create-pr"><img src="https://agentmods.dev/badge/skills/gjoranv/claude-plan-skills/gh-create-pr/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/gjoranv/claude-plan-skills/gh-create-pr"><img src="https://agentmods.dev/badge/skills/gjoranv/claude-plan-skills/gh-create-pr.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00037 | $0.00831 |
| Opus 5 | $0.00018 | $0.00415 |
| Sonnet 5 | $0.00007 | $0.00166 |
| Haiku 4.5 | $0.00004 | $0.00083 |
Grade A, and why
gh-create-pr scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 12d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
What it actually says
Create GitHub pull request(s) from the current branch. If this session touched multiple repos (check conversation context, plan issue, or ask the user), create a PR in each repo. Run steps 1-8 for each repo in sequence.
- Check state: Run
git statusandgit branch --show-current. - Prepare a branch:
- Always fetch the latest base branch (main/master) first.
- If the current branch is main/master, create a new branch off the freshly fetched base. Pick a short, descriptive branch name from the conversation context (e.g.
resource-tags-docs). Move any uncommitted changes to the new branch. - Otherwise, rebase the current branch onto the freshly fetched base. If there are conflicts, stop and ask the user to resolve them.
- Handle uncommitted changes: If there are uncommitted changes on the (now non-master) branch, ask the user if they want to commit first. Do not proceed until the working tree is clean.
- Push the branch: Push the current branch to remote with
git push -u origin. - Gather context: Read the git log for all commits on this branch since it diverged from the base branch. If a plan issue was referenced in this conversation, read it for additional context. Check for a PR template at
.github/pull_request_template.mdor.github/PULL_REQUEST_TEMPLATE.mdin the repo. If one exists, use it as the structure for the PR description. - Create the PR: Use
gh pr createwith--title,--body, and--web(opens the browser with the PR pre-filled for editing). Do not use--edit(opens a terminal editor, unreliable).- A concise title (under 70 characters)
- Body: for trivial PRs (single commit, simple change), a few plain-text sentences covering what, why, and how it was tested. For non-trivial PRs (multi-commit, multi-file, or complex changes), use three sections:
## What,## Why,## Tested. Use bullet lists when listing multiple changes or test steps. Keep each section concise; reviewers read the diff for details.- Size the body to the change's consequence, not to the work behind it: a comment-only fix stays trivial however much investigation established it, while a one-line change to a widely-instantiated module is not.
- Lead with what the change does for the reviewer rather than the method that found it, and leave evidence, log excerpts and ruled-out hypotheses in the plan issue.
- Do not restate what the commit messages already say. The PR body adds the overarching why and how it was tested; the per-commit details are in the commits.
- Link to the plan issue only if it is in the same repo as the PR. Do not link to plan issues in other repos.
- Do not set reviewers or labels.
- Footer: Check for
~/.claude/skills/gh-create-pr/pr-footer.md. If it exists, append its content to the PR body, separated by---. Replace{{model}}with the full model slug including version and variant (e.g. "Claude Opus 4.8", "GPT-5.6 Sol").
- Post-creation: If creating PRs across multiple repos, cross-link them in each PR description (e.g. "Related: owner/other-repo#N"). Do NOT cross-link from a public repo to a non-public repo.
Rules:
- Never create a PR without pushing the branch first.
- Keep the description concise. No empty boilerplate sections.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 12d ago First seen · 31 lines · 37 tokens per session scan A b8eddb3ee216
gh-create-pr is a skill published in the GitHub repository gjoranv/claude-plan-skills (5 stars, last pushed 12d ago), licensed MIT. It adds 37 tokens to every session and 831 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
understand-diff
Use when you need to analyze git diffs or pull requests to understand what changed, affected components, and risks.
release-skills
A release workflow for preparing and publishing a new version of a software project. A release is a named version that may include updated version files, release notes, tags, or a GitHub Release.
git-commit
A Git assistant for reviewing local changes and creating conventional commit messages, which are standardized summaries of code changes. It can also run Git hooks and push the commit.
git-pr-review
A read-only reviewer for GitHub pull requests, which are proposed code changes submitted for review. It produces an evidence-based report about whether a pull request should be merged.
git-workflow
A Git workflow guide for organizing commits, branches, pull requests, releases, and automated version-control tasks. Git is the system developers use to track code changes and collaborate.
git-publish-release
A release assistant for GitHub, a service for hosting software projects. It compares project history and creates a GitHub Release with notes for a chosen version tag.