Borrowing it
Nothing to install: this file belongs to HexamindOrganisation/hexgate. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/HexamindOrganisation/hexgate/main/.claude/skills/pr-description/SKILL.mdgit clone --depth 1 https://github.com/HexamindOrganisation/hexgateWrote 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/hexamindorganisation/hexgate/pr-description)<a href="https://agentmods.dev/skills/hexamindorganisation/hexgate/pr-description"><img src="https://agentmods.dev/badge/skills/hexamindorganisation/hexgate/pr-description/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/hexamindorganisation/hexgate/pr-description"><img src="https://agentmods.dev/badge/skills/hexamindorganisation/hexgate/pr-description.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.00073 | $0.01931 |
| Opus 5.5 | $0.00029 | $0.00772 |
| Sonnet 5.5 | $0.00015 | $0.00386 |
| Haiku 4.5 | $0.00007 | $0.00193 |
Grade A, and why
pr-description 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.
How it starts
The opening of the file, as written. The whole thing — 157 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Write a hexgate PR description
The goal is a body a reviewer can read top to bottom and know, in order: what this PR is for, how it works, and which files to open first. A clear description is the cheapest way to speed up review — most of the time saved is questions the reviewer never has to ask.
The commit subject is separate and stays type(scope): description (see
AGENTS.md). This skill is about the PR body.
Why the structure matters
- The reader is no longer only human. PRs are read by AI agents too — they summarize the change, review the diff, and answer questions about it. A consistent shape (objective → design → the files that matter) is something both a human skims and an agent parses, and an agent can walk the "important files" table as a review order the same way a person would.
- There is more code per PR than there used to be. The description is the main thing standing between a large, partly machine-written diff and a reviewer who has to trust it. A structured body keeps review fast no matter who — or what — is reading.
- Guard against rubber-stamping. When an agent drafts the description and an agent reviews the diff, the human can slide into approving a change nobody read. At least one section must be written by the person who did the work and be something a model cannot fake: the test plan. An agent can summarize a diff, but it cannot truthfully say what you ran and what you saw.
Principles
- Lead with the objective. The first sentence says what the PR does, before any detail. A reviewer should grasp the point without scrolling.
- Explain why, not just what. The diff already shows what changed; the body's job is the motivation and the approach the diff cannot show.
- Scale length to the change. A one-file fix gets a paragraph. A subsystem gets the full skeleton. Do not pad a small PR into a big one.
- Make it scannable. Short paragraphs, bullet lists, and tables beat prose walls.
- Point at the files that matter. In a 13-file diff, name the three that carry the design; leave the ten mechanical ones out.
- Write for someone without the background. The reviewer may not have been in the design discussion.
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 Changed 5d32a213bab9
- 1mo ago First seen · 157 lines · 73 tokens per session scan A af0a0f322942
pr-description is a skill published in the GitHub repository HexamindOrganisation/hexgate (23 stars, last pushed today), licensed MIT. It adds 73 tokens to every session and 1,931 once invoked, about $0.0003 per session on Opus 5.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-09-24.
Other skills, from other repositories
review-team
Use when assigned a review or when an authored review boundary is reached.
receiving-code-review
Handle review feedback on code with care: understand each point, check it against the real code before changing anything, fix what is right, and push back with reasons on what is wrong. Use when review comments arrive.
oma-refactor
Restructure existing code while preserving observable behavior. Use for targeted technical debt or hotspot work with characterization tests.
address-pr-comments
Work through the review comments on a pull request: check each point against the code, make the changes that are right, answer the ones that are not, and hold every reply for approval before it is posted.
gentle-ai-judgment-day
Trigger: judgment day, judgement day, dual review, adversarial review, juzgar. Run explicit blind dual review with at most two scoped fix/re-judgment rounds.
release
Release gentle-pi through GitHub and npm. Trigger: release, publish, npm publish, GitHub release, version bump.