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 agentmods add skills/ericandrechek/pacer/shipnpx skills add EricAndrechek/Pacer --skill shipgit clone --depth 1 https://github.com/EricAndrechek/PacerWhat 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 | $0.00138 | $0.01297 |
| Opus 5 | $0.00069 | $0.00648 |
| Sonnet 5 | $0.00028 | $0.00259 |
| Haiku 4.5 | $0.00014 | $0.00130 |
Grade A, and why
ship 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 2d 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 — 107 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Ship a Pacer release
This skill is the orchestration and the gate. The deterministic plumbing —
computing the next version, tagging, watching the Release workflow, verifying
the published artifact — is in bin/ship.sh. Read docs/releasing.md for the
pipeline and one-time setup.
There is exactly ONE human gate: a single approval right after a local install. Everything after it is autonomous and backgrounded. The whole point is that a release costs almost no attention (and almost no expensive model tokens): the waiting and verifying happen in a backgrounded script, and the draft/review chores go to a cheap model.
0 · Before a release (during the work)
- Branches and PRs are your judgement — stack/rename branches freely as scope grows, push for backup whenever. Do not open the PR yet, and never tag/merge here.
- When the work is done,
make installso the maintainer can see it live. Stop there.
1 · The gate — right after make install is live
bin/ship.sh preflight→ prints the suggested bump (patch, or minor if a@Model/schema change is detected — you confirm; minor = a SwiftData reset) and the next version.bin/ship.sh notes <version>→ previews the exact notes CI will publish (--generate-notes), so what you show matches what ships.- Surface bump + notes:
- Not pre-authorized → ask once with
AskUserQuestion(it push- notifies the maintainer and blocks). Offer: ship it · hold · change the bump. This is the only AskUserQuestion in the flow. - Pre-authorized — the kickoff request already said to ship ("…and
release it", "ship it autonomously", "merge and release") → send a
PushNotificationFYI with the bump + notes, then proceed.
- Not pre-authorized → ask once with
The only other permitted interruption anywhere is a genuine implementation/ direction fork you shouldn't guess on.
2 · Prep — into the PR, before merge
Do the release housekeeping and commit it to the branch before merging (so the shipped PR is self-contained):
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.
- 2d ago First seen · 107 lines · 138 tokens per session scan A 6895b0c10d93
ship is a skill published in the GitHub repository EricAndrechek/Pacer (8 stars, last pushed 21d ago), licensed MIT. It adds 138 tokens to every session and 1,297 once invoked, about $0.0007 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
macos-patterns
Essential native macOS development patterns that web developers don't know about. Use this skill whenever the user is building a macOS app and needs guidance on native patterns, or when they ask about menu bar apps, floating panels, window levels, keyboard shortcuts, file pickers, clipboard, drag and drop, screen…
macos-settings-ui
Build a proper macOS settings/preferences window with liquid glass support for macOS 26 (Tahoe). Use this skill whenever the user asks to create a settings window, preferences UI, settings view, or preferences pane for a macOS app. Also trigger when the user mentions "liquid glass settings", "NavigationSplitView…
macos-auto-update
Add Sparkle auto-update support to a native macOS app. Use this skill whenever the user wants to add auto-updates, implement Sparkle, set up an appcast feed, add "Check for Updates" to their app, or integrate automatic update checking. Also trigger when the user mentions Sparkle, appcast, SUFeedURL, EdDSA signing, or…
macos-notch-ui
Add a Dynamic Island-style notch UI to a macOS app. Use this skill whenever the user wants to create a notch overlay, notch extender, Dynamic Island for Mac, notch indicator, or any UI that extends from the MacBook notch area. Also trigger when the user mentions "notch shape", "notch window", "notch cutout", "notch…
macos-release
Release a native macOS app to GitHub with DMG packaging and Sparkle appcast updates. Use this skill whenever the user wants to publish a new version, create a release, ship an update, push a release to GitHub, or update the appcast. Also trigger when the user mentions DMG creation, Sparkle signing, notarization…
ideation
Tokfuel の機能アイデアの壁打ち相手。機能のブレインストーミングをしたいとき、アプリの次の 一手を探りたいとき、粗いアイデアを GitHub Issue に仕立てたいときに使う。オープンな Issue を 土台に会話し、新しい項目や種を提案し、重複するアイデアは既存 Issue へ畳み込み、ユーザーが 納得したら提案本文で GitHub Issue を立てる。スコープは起案のみで、機能の実装は一切しない （実装は implementation スキルの担当）。.