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/benjaminard/fable-skills/minimal-diffnpx skills add benjaminard/fable-skills --skill minimal-diffgit clone --depth 1 https://github.com/benjaminard/fable-skillsWhat 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.00059 | $0.00592 |
| Opus 5 | $0.00030 | $0.00296 |
| Sonnet 5 | $0.00012 | $0.00118 |
| Haiku 4.5 | $0.00006 | $0.00059 |
Grade A, and why
minimal-diff 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 3d 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 — 30 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Minimal Diff
Do the simplest thing that works well, and only the thing that was asked. The size of your diff should be proportional to the size of the request.
The rules
- No unrequested work. Do not add features, refactor, or introduce abstractions beyond what the task requires. A bug fix does not need surrounding cleanup. A one-shot operation does not need a helper function. If you notice something worth fixing nearby, mention it in your summary; do not fix it in the same change.
- No hypothetical futures. Do not design for requirements that do not exist yet. Avoid premature abstraction and half-finished generalization. The second use case, when it arrives, will tell you what the abstraction should be; guessed abstractions are usually wrong.
- No impossible-scenario handling. Do not add error handling, fallbacks, or validation for situations that cannot happen. Trust internal code and framework guarantees. Validate at system boundaries (user input, external APIs) and nowhere else.
- Change the code, not around it. Do not add feature flags, compatibility shims, wrapper layers, or "v2" copies when you can simply change the code. Dead paths and parallel versions are debt from the moment they land.
- Match the surroundings. Write code that reads like the file it lives in: same naming, same idiom, same comment density. A correct change in a foreign style is still a costly change.
- Comments state constraints, not narration. Only write a comment for something the code cannot show, like an external constraint or a non-obvious invariant. Never comment what the next line does, where the code came from, or why your change is correct. That last kind is you talking to a reviewer, and it is noise the moment the change merges.
The pre-submit check
Before finishing, read your own diff hunk by hunk and ask of each one: does the task fail without this?
- If yes, keep it.
- If no, but it fixes something real and separate: revert it, and note the finding in your summary as a suggested follow-up.
- If no, and it is stylistic: revert it without comment.
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.
- 3d ago First seen · 30 lines · 0 tokens per session scan A c0439ea39aeb
minimal-diff is a skill published in the GitHub repository benjaminard/fable-skills (30 stars, last pushed 2mo ago), licensed MIT. It adds 59 tokens to every session and 592 once invoked, about $0.0003 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-30.
Other skills, from other repositories
humanizer
Rewrite AI-sounding text so it reads naturally without changing what it says. Use when editing or reviewing prose for inflated claims, sales language, vague sources, repetitive structure, stock AI words, passive voice, filler, or chatbot artifacts. Based on Wikipedia's "Signs of AI writing.".
metrics-instrumentation
Specification for instrumenting an opik-backend workflow with operational OpenTelemetry metrics — per-stage throughput/latency/error counters and native histograms, dimensioned per-customer (workspace). Use when a pipeline (scoring, ingestion, experiments, jobs) needs per-stage visibility. Covers metric emission only…
a-evolve
Apply A-Evolve's agentic evolution methodology to improve AI agent performance across runs. Use when the user wants to diagnose agent failures, generate targeted skills from error patterns, evolve system prompts, or accumulate episodic knowledge. Works standalone or inside AutoResearchClaw pipelines. Triggers on…
discount-review
Inspect the discount policy fixture with a repeatable review checklist and helper script.
happiness-skill
当用户问「怎么才能更幸福/为什么得到了还不满足/怎么减少焦虑」时调用。 核心理念: 幸福是缺憾感清空的默认状态, 是可训练的技能; 欲望是与自己的契约(得到前不快乐), 同时只留一个重大欲望; 活在当下。 不适用于: 临床抑郁等需要专业治疗的场景(本书方法不能替代医疗)。 Triggers: 幸福/不快乐/欲望/焦虑/知足/活在当下/happiness/desire/anxiety.
experimental-design
Best practices for designing reproducible ML experiments. Use when planning ablations, baselines, or controlled experiments.