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 saadshahd/moo.md --skill setupgit clone --depth 1 https://github.com/saadshahd/moo.mdWrote 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/saadshahd/moo.md/setup)<a href="https://agentmods.dev/skills/saadshahd/moo.md/setup"><img src="https://agentmods.dev/badge/skills/saadshahd/moo.md/setup/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/saadshahd/moo.md/setup"><img src="https://agentmods.dev/badge/skills/saadshahd/moo.md/setup.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.00062 | $0.02113 |
| Opus 5.5 | $0.00025 | $0.00845 |
| Sonnet 5.5 | $0.00012 | $0.00423 |
| Haiku 4.5 | $0.00006 | $0.00211 |
Grade A, and why
setup 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 5d 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 — 75 lines — stays where its author put it; the contents beside it link to each section on GitHub.
sound:setup
Scaffold a project's taste rules from the sound corpus: probe the stack, select ONLY rules whose subject the repo's code actually shows — evidence-cited per rule, never a tag-wide dump — confirm with the user, then install each confirmed rule's corpus prose verbatim. Each rule lands as a plain reference file in .claude/sound/<topic>/ — the tree sound:prime points at. Written files belong to the user; re-runs reconcile (see Re-runs).
Corpus: ../../corpus/ relative to this SKILL.md — the candidate universe, laid out as <topic>/<rule>.md: the directory is the rule's topic, the file is the pure rule body — no frontmatter, no metadata. Sibling ../../corpus-optin/ (same layout) holds opt-in rules, excluded from candidacy unless the user names one at invocation (Phase 2). If corpus/ is missing or unreadable, STOP and say so — never install a partial set silently.
Phase 1 — Probe
Decide which kind-tags apply (react, db, distributed) — verified STACK FACTS that anchor Phase 2's per-rule judgment and are presented at Confirm, not a filter that earns any rule an install.
Usage decides; manifest presence only says where to look. Verify every hint at its USE sites in source before proposing a tag — deps can be dead weight, hoisted, or tooling-only. Negatives need the same rigor: a client's config/wrapper file never clears a dep; search its use sites (.publish(, .send(, .create(…) before ruling a tag out. Read every package.json (root + workspaces) and workspace markers (pnpm-workspace.yaml, turbo.json) → hypotheses → verify each in source. Note TS / pure-JS / neither: it sets the TS-only veto (Phase 2) and the no-JS/TS abort (Failure modes).
| Tag | Fires on (verified usage) | Does NOT fire on |
|---|---|---|
react |
.tsx/.jsx files, JSX or react imports in real source |
react in deps with zero usage; react-shaped tooling (ink absent too) |
db |
a db client or ORM imported in source, whichever one; redis-as-store; EMBEDDED dbs with owned DDL/schema (sqlite, node:sqlite, level — in-process still counts); owned schema/migration files |
consuming someone else's hosted API without owning storage |
distributed |
any SIDE-EFFECTFUL remote boundary: payments, email/SMS, queue/broker publish, webhook handlers, bot messaging SDKs, multiple owned services reconciling state. FRAMEWORK-WRAPPED senders count: an auth provider configured with an SMTP transport, e.g. next-auth EmailProvider, IS email-sending usage even with no direct nodemailer import. Publisher-side evidence alone is SUFFICIENT — the consumer usually lives outside the repo | READ-ONLY consumption of remote APIs (fetch-and-render); analytics beacons; redis as a plain same-process cache (get/set/del only) |
What ships with it
2 files 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.
- 5d ago Changed · +12 lines 4da786a3a68c
- 1mo ago First seen · 63 lines · 62 tokens per session scan A ff8e17ebee87
setup is a skill published in the GitHub repository saadshahd/moo.md (38 stars, last pushed today), licensed MIT. It adds 62 tokens to every session and 2,113 once invoked, about $0.0002 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-08-30.
Other skills, from other repositories
session-recap
Document Claude Code sessions by extracting knowledge into cross-referenced documentation. Triggers on "recap the session", "summarize the work", or after significant code changes.
knowledge-bank-lookup
Delegates knowledge bank lookups to Explore subagents with reflections-first strategy that learns from past mistakes. Checks /reflections/ directory before documentation to extract documented failures to avoid and proven approaches to apply. Automatically triggers when user mentions services ([project-a], [project-b]…
kb-ingest
Ingest external sources into the knowledge bank through interactive study or quick filing. Two modes — Quick (summarize → file) and Study (theme-by-theme deep dive with online research and personal notes → multi-layer KB output → optional blog/slack synthesis). Triggers on "ingest this", "study this article", "add to…
kb-lint
Health-check the knowledge bank for orphan documents, stale content, broken WikiLinks, index drift, and missing frontmatter. Generates a severity-graded report. Use this skill whenever the user mentions lint, health check, KB maintenance, stale docs, broken links, orphan pages, missing references, knowledge bank…
session-manager
Set the current session's name, project, tags, or summary on its session note. Use when the user names, tags, or summarizes this session, sets its project, or mentions in passing what this session has been about.
lark-openapi-explorer
A skill for finding and calling Lark APIs that are not already available through existing commands. An API is a defined way for software to request work from another service.