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 rikdc/ai-skills --skill prgit clone --depth 1 https://github.com/rikdc/ai-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/rikdc/ai-skills/pr)<a href="https://agentmods.dev/skills/rikdc/ai-skills/pr"><img src="https://agentmods.dev/badge/skills/rikdc/ai-skills/pr.svg" alt="Measured on agentmods" 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.00043 | $0.00775 |
| Opus 5 | $0.00022 | $0.00387 |
| Sonnet 5 | $0.00009 | $0.00155 |
| Haiku 4.5 | $0.00004 | $0.00077 |
Grade A, and why
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 7d 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 — 102 lines — stays where its author put it; the contents beside it link to each section on GitHub.
PR - GitHub Pull Request Creation
Creates a draft pull request with a conventional-commit title and a short description of what the branch actually changes.
Workflow
- Validate:
gh auth status, current branch, uncommitted changes. - Read the branch:
git log <base>..HEADandgit diff <base>...HEAD— the description covers exactly this, nothing more. - Write the body: use
.github/pull_request_template.mdif present, otherwise the sections below. - Create:
gh pr create --draft --title "<type>(<scope>): <subject>" --body-file <file> --base main
Title Rules
- Conventional commit format:
<type>(<scope>): <subject>. - No emoji. The title is plain text.
- Under 70 characters, imperative mood, no trailing period.
- For a single-commit PR, reuse that commit's subject.
Examples:
feat(auth): add session refresh endpointfix(scanner): match patterns case-insensitivelydocs: document the scanner exit codes
Body Rules
Keep it succinct. The PR body describes the commits on the branch and nothing else.
- Summary: one to three sentences. What changed and why. No restating the title, no background essay.
- Changes: one bullet per meaningful change, one line each. Group trivial edits rather than listing every file. Under six bullets for a normal PR — if it needs more, the PR is probably too large.
- Testing: one line stating what was run (
make test,go test ./...) and the result. Say so plainly if nothing was run. - Drop any template section that has nothing real to say.
- No emoji, no headings beyond the template's, no "Notes for reviewers", "Future work", "Impact", or risk-assessment sections unless asked.
- Do not claim behaviour you have not verified.
Default body when there is no template:
## Summary
<1-3 sentences>
## Changes
- <change>
- <change>
## Testing
<command and result>
Example body:
## Summary
Pattern matching in the MCP scanner was case-sensitive, so uppercase AWS keys
passed the scan. Matching is now case-insensitive.
## Changes
- Add `-i` to the pattern grep in `mcp-security-scanner.sh`
- Cover uppercase keys in `tests/test-scanner.sh`
## Testing
`make test` — all suites pass.
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.
- 7d ago First seen · 102 lines · 43 tokens per session scan A a1fde95eb1db
pr is a skill published in the GitHub repository rikdc/ai-skills (2 stars, last pushed 2d ago), licensed MPL-2.0. It adds 43 tokens to every session and 775 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
skill-ship
Package and finalize completed work for delivery — use when a feature is done and ready to ship.
deploy-steward
Mainline deploy steward. Consumes ready PRs, owns a lease on mainline landing, refreshes PR state, updates stale branches, waits for CI and deploy gates, merges or queues one candidate at a time, and opens repair tasks for failures.
release
CONTRIBUTOR TOOL - Cut a plugin release: bump plugin.json version, finalize CHANGELOG, update README if needed, gate on make ci, commit, tag vX.Y.Z, and create the GitHub release. Use when shipping a new plugin version. NOT distributed.
release
Cut a brooks-lint release: set the version in package.json, propagate it across all four plugin manifests and every version-bearing text file (README badges, docs site metadata), write the CHANGELOG entry, validate, then commit, push, tag, and publish the GitHub release. Triggers when the maintainer asks to "release"…
create-release-checklist
Create a release checklist and GitHub issue for an R package. Use when the user asks to "create a release checklist" or "start a release" for an R package.
push-ci
Push to remote and monitor CI. Validates branch safety, executes git push WITH explicit user approval, then monitors CI run status via gh CLI. Use when: user says 'push', 'push and watch CI', 'ship it', 'push-ci'. Not for: committing (use /smart-commit), creating PRs (use /create-pr), merging (use /merge-prep).