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 Gentleman-Programming/gentle-pi --skill branch-prgit clone --depth 1 https://github.com/Gentleman-Programming/gentle-piWrote 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/gentleman-programming/gentle-pi/branch-pr)<a href="https://agentmods.dev/skills/gentleman-programming/gentle-pi/branch-pr"><img src="https://agentmods.dev/badge/skills/gentleman-programming/gentle-pi/branch-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/gentleman-programming/gentle-pi/branch-pr"><img src="https://agentmods.dev/badge/skills/gentleman-programming/gentle-pi/branch-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.00030 | $0.01531 |
| Opus 5.5 | $0.00012 | $0.00612 |
| Sonnet 5.5 | $0.00006 | $0.00306 |
| Haiku 4.5 | $0.00003 | $0.00153 |
Grade A, and why
gentle-ai-branch-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 1mo 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.
This is a copy
97% identical to branch-pr — 81 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 203 lines — stays where its author put it; the contents beside it link to each section on GitHub.
When to Use
Use this skill when:
- Creating a pull request for any change
- Preparing a branch for submission
- Helping a contributor open a PR
Critical Rules
- Every PR MUST link an approved issue — no exceptions
- Every PR MUST have exactly one
type:*label - Automated checks must pass before merge is possible
- Blank PRs without issue linkage will be blocked by GitHub Actions
Workflow
1. Verify issue has `status:approved` label
2. Create branch: type/description (see Branch Naming below)
3. Implement changes with conventional commits
4. Run shellcheck on modified scripts
5. Open PR using the template
6. Add exactly one type:* label
7. Wait for automated checks to pass
Branch Naming
Branch names MUST match this regex:
^(feat|fix|chore|docs|style|refactor|perf|test|build|ci|revert)\/[a-z0-9._-]+$
Format: type/description — lowercase, no spaces, only a-z0-9._- in description.
| Type | Branch pattern | Example |
|---|---|---|
| Feature | feat/<description> |
feat/user-login |
| Bug fix | fix/<description> |
fix/zsh-glob-error |
| Chore | chore/<description> |
chore/update-ci-actions |
| Docs | docs/<description> |
docs/installation-guide |
| Style | style/<description> |
style/format-scripts |
| Refactor | refactor/<description> |
refactor/extract-shared-logic |
| Performance | perf/<description> |
perf/reduce-startup-time |
| Test | test/<description> |
test/add-setup-coverage |
| Build | build/<description> |
build/update-shellcheck |
| CI | ci/<description> |
ci/add-branch-validation |
| Revert | revert/<description> |
revert/broken-setup-change |
PR Body Format
The PR template is at .github/PULL_REQUEST_TEMPLATE.md. Every PR body MUST contain:
1. Linked Issue (REQUIRED)
Closes #<issue-number>
Valid keywords: Closes #N, Fixes #N, Resolves #N (case insensitive).
The linked issue MUST have the status:approved label.
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.
- 1mo ago First seen · 203 lines · 30 tokens per session scan A 83e76526d3c5
gentle-ai-branch-pr is a skill published in the GitHub repository Gentleman-Programming/gentle-pi (804 stars, last pushed 1mo ago), licensed MIT. It adds 30 tokens to every session and 1,531 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 97% identical to branch-pr, differing in 81 lines, and is treated as a copy.
Other skills, from other repositories
explain-pr
Explain a PR: the background problem and the proposed solution.
pi-sync
Daily upstream-sync job for the pi Go port — fetch upstream pi, triage every change since the recorded pin, port what's in scope, verify idiomatic + parity via independent reviews, update the ledger, and push. Use for "sync with upstream", "porting job", or as the scheduled daily run.
ship
Use when code is ready to ship — creates PRs, merges, deploys, and verifies. Handles the full PR-to-production pipeline. Triggers on /ship.
release-readiness
Use after review/qa/security/license-audit/privacy-check to compose a release decision before /ship. Returns OK only when all required upstream evidence is present and clean. Triggers on /release-readiness.
releasing-code
Prepare, publish, or repair a software release and write its release notes. Use for cutting a versioned release or editing release notes. NOT for updating an installed package, publishing articles, or discussing a release; for general documentation use documenting-code.
upload
Pre-upload gate for track handoff. Verifies review status, HLD approvals, deploy checklist, and validator chain before git upload or PR submission.