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 vinta/hal-9000 --skill prgit clone --depth 1 https://github.com/vinta/hal-9000Wrote 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/vinta/hal-9000/pr)<a href="https://agentmods.dev/skills/vinta/hal-9000/pr"><img src="https://agentmods.dev/badge/skills/vinta/hal-9000/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/vinta/hal-9000/pr"><img src="https://agentmods.dev/badge/skills/vinta/hal-9000/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.00035 | $0.01528 |
| Opus 5.5 | $0.00014 | $0.00611 |
| Sonnet 5.5 | $0.00007 | $0.00306 |
| Haiku 4.5 | $0.00003 | $0.00153 |
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 — 86 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Invoking this skill IS the request. Your task is fully specified here. Never ask what to do.
Run every command bare, exactly as written below: git and gh find the repository from any subdirectory, and a cd does not carry over to the next Bash call in this fork. A cd ... && or $() prefix stops a command matching allowed-tools, and the merge then hits the permission gate.
The user invoked this skill with: "$ARGUMENTS"
Mode comes from the arguments first: create means create mode, update means update mode, merge means merge mode. With none of those three words, including an empty argument, run gh pr view --json state --jq .state 2>/dev/null and let its result decide: a non-zero exit (no PR for this branch) means create mode, OPEN means update mode, any other state means report that state and stop. Merge mode only ever comes from the argument.
PR material
Create mode and update mode run these steps where they say "gather PR material":
-
git log --format='%n%s' --name-only main..HEAD(fall back tomaster..HEAD). Each commit is a block: its subject, then the files it touched. A flat log next to a branch-wide diff stat lets the writer guess which commit touched which file. -
The PR describes the net change of the branch. A commit whose subject starts with
Revert "and the commit it names cancel each other when both sit in the log, as does a later commit that restores what an earlier one removed, and a subject starting withbuild: bumpdescribes no change. Remove those blocks from the log before passing it on. -
git log --format=%b main..HEAD(same fallback). Collect every issue number written as#Nor as a GitHub issue URL. Each one becomes aFix #Nline at the end of the body, one per line, no duplicates. -
Invoke the
write-like-meskill. Pass as argument: "Write a GitHub PR title and body from the material below. Shape the draft as the title on the first line, a blank line, then the body, and nothing else: the caller splits on the first line, so a label or heading would land in the title. The draft goes straight into the caller's nextghcommand in the same response, never into a reply: a reply with no tool call ends the caller before the PR exists.
Title: one plain-English line under 72 chars that names the change itself, with no fix: or feat: type prefix. GitHub shows titles as plain text, so write file names bare, without backticks. Body: GitHub renders it as markdown, so wrap every file path, command, flag, and identifier in backticks, at every occurrence. Leave out changes a reviewer would not miss, such as ignore files, asset moves, and personal config tweaks, unless the branch holds nothing else. Body shape depends on how many separate changes are left.
One change: 1-3 sentences of prose, what changed and why, no list.
Adds a pr skill that pushes the current branch, drafts a PR title and body with write-like-me, and opens the PR with gh. Wires it into the plugin manifest and marketplace so it ships with hal-skills.
Two or more changes: one - item per change, each item 1-3 short sentences stating the change and one before/after example when the change has a visible input and output. Give every item its example, not only the first.
- Move
name-suffixfrom AI spacing into the core rules. - URLs are left alone. Anything starting with
http://orhttps://is hidden from the rules, so%E4%B8%ADand/wiki/CJK#CJKsurvive. /next to CJK never gets spaces anymore.CJK/CJKstaysCJK/CJK, same as_. File paths still work:CJK/homeCJKbecomesCJK /home CJK.
" followed by the log from step 2, then a closing "" line.
- From
write-like-me's output, take the first line as title, the rest as body. Append a blank line and theFix #Nlines from step 3 to the body.
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.
- 7d ago Changed f39664fd361f
- 14d ago Changed · +1 lines c62c11716db3
- 24d ago Changed · -6 lines b05e174a5736
- 1mo ago Changed · -1 lines 917edd6e35c0
- 1mo ago Changed b73589d01ff4
- 1mo ago Changed 1bbcada840af
- 1mo ago Changed · -4 lines 2409860516cf
- 1mo ago Changed · +27 lines 5a08924e593a
- 1mo ago First seen · 69 lines · 35 tokens per session scan A 5915d0be92cf
pr is a skill published in the GitHub repository vinta/hal-9000 (141 stars, last pushed today), licensed MIT. It adds 35 tokens to every session and 1,528 once invoked, about $0.0001 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-10.
Other skills, from other repositories
xberg-release
Xberg release on top of the shared release-workflow: task version:sync to bindings and chart, CI/Publish/Benchmarks readiness. Use before a release.
release
Prepare, verify, and publish Sutando engine releases. Use when asked to prepare a release proposal, determine a version bump, audit release documentation, validate release gates, create a release PR, tag a confirmed release, or publish GitHub release notes. Preparation is safe and non-publishing; tagging and…
git-workflow
Git operations: commits, branches, PRs, and conflict resolution.
Release Notes Generator
Generate professional software release notes from a commit log: classify changes, write user-facing summaries, draft a publishable announcement, and assess release readiness. Use for release, changelog, version, and deploy requests.
starcat-update-changelog
Update Starcat changelog documents in supports/starcat-pro/ by reading ALL git commits from the main Starcat project and generating categorized release notes in both English and Chinese. Use this skill whenever the user wants to update changelog, release notes, update records, or sync the changelog with recent…
pinned-release-checklist
Minimal guidance-only Skill used by release-pinned compatibility examples.