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 imMamdouhaboammar/get-fable --skill pr-explainergit clone --depth 1 https://github.com/imMamdouhaboammar/get-fableWrote 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/immamdouhaboammar/get-fable/pr-explainer)<a href="https://agentmods.dev/skills/immamdouhaboammar/get-fable/pr-explainer"><img src="https://agentmods.dev/badge/skills/immamdouhaboammar/get-fable/pr-explainer/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/immamdouhaboammar/get-fable/pr-explainer"><img src="https://agentmods.dev/badge/skills/immamdouhaboammar/get-fable/pr-explainer.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.00019 | $0.00721 |
| Opus 5 | $0.00010 | $0.00360 |
| Sonnet 5 | $0.00004 | $0.00144 |
| Haiku 4.5 | $0.00002 | $0.00072 |
Grade A, and why
pr-explainer 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 9d 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 — 71 lines — stays where its author put it; the contents beside it link to each section on GitHub.
name: pr-explainer
description: Generate a shareable walkthrough artifact for a pull request — what changed, why, and a reviewer-oriented before/after narrative.
No PR number was given — explain the current branch's pending PR:
git log --oneline @{upstream}..HEADfor the commit list (fall back toorigin/main..HEADif no upstream)git diff @{upstream}...HEADfor the unified diff
Goal
Produce a shareable PR walkthrough artifact — a self-contained HTML page a
reviewer can read before opening the diff to understand what this change does,
why it's being made, and where to focus attention. Pitch the writing at a
reviewer seeing this PR for the first time.
Wherever the answers end up in the sections below, the page must answer all
five of these questions:
- What is the problem this PR is trying to solve?
- Why is it a problem?
- How are we solving it?
- What alternatives did we consider?
- Why is the current approach better than the alternatives?
If the diff, PR body, and commit messages give no evidence for one of these —
most often 4 and 5 — say that plainly (e.g. "the PR doesn't record what
alternatives were considered") instead of inventing an answer.
Build it from the explainer template
Load the artifact-explainer skill and build the page from its template,
publishing with the Artifact tool as that skill directs. Use the
template's sections flavor — keep the sections structure, delete the
numbered steps. Fill the slots as follows:
- Lede — what this PR changes and why it's needed, in two or three
sentences. If the PR body already says this well, reuse it. - Sections — lead with one architecture or flow diagram when the change
has a structural story; otherwise skip straight to the code. Open with a
before/after section showing the user-observable change (behavior, API
shape, or output); skip it if the change has no observable surface. Then
group the diff into sections cut at the material's joints — group related
changes rather than splitting per file. In each section the code snippet is
usually the subject matter itself: a trimmed snippet, a plain-language
explanation, and anything a reviewer should look closely at; add a diagram
only where structure or flow genuinely needs one (the skill's diagram-first
default applies to concept explainers, not PR walkthroughs, which are
mostly symbolic content). End with a section for what's not obvious from
the diff — context the diff alone doesn't show (why this approach over an
alternative, what was tried and rejected, follow-ups intentionally left
out). - Recap — restate the takeaways as where a reviewer should focus
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.
- 9d ago First seen · 71 lines · 19 tokens per session scan A 1c23819c9587
pr-explainer is a skill published in the GitHub repository imMamdouhaboammar/get-fable (3 stars, last pushed 4d ago), licensed MIT. It adds 19 tokens to every session and 721 once invoked, about $0.0001 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
omh-deploy-and-monitor
This is a Hermes-native deploy-and-monitor workflow skill.
release-cut
Cut a new pi-agent-dashboard release: promote ## [Unreleased] in CHANGELOG.md, bump every workspace package.json per SemVer, commit, tag v , and push — triggering the Release workflow that publishes every non-private workspace, builds the Electron artifacts, and creates a GitHub Release. Use on "cut a release"…
release-revoke
Revoke or rollback a pi-agent-dashboard release: delete the GitHub Release, remove the git tag locally and on origin, deprecate the npm version (npm unpublish is blocked after 72h), and optionally revert the release commit. Use when the user says "revoke release", "rollback release", "delete release", "unpublish…
public-plugin-packaging
Use when packaging an Agentlas agent repo for public GitHub release, Codex plugin submission, Claude adapter distribution, or one-line terminal installation.
shipping-a-pr
Use when finished work needs to ship as a pull request, or when the ask is about a PR — creating one, bringing it up to date, adding screenshots, watching its checks, or addressing its review comments. Not for reviewing a PR you are not shipping.
dev-git-workflow
Designs team Git workflows for branching, PRs, and releases. Use when choosing branching models, stacked PRs, merge queues, worktree isolation for agents, or collaboration rules.