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/mehrad-dm/mastermind/explainnpx skills add mehrad-dm/mastermind --skill explaingit clone --depth 1 https://github.com/mehrad-dm/mastermindWrote 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/mehrad-dm/mastermind/explain)<a href="https://agentmods.dev/skills/mehrad-dm/mastermind/explain"><img src="https://agentmods.dev/badge/skills/mehrad-dm/mastermind/explain.svg" alt="Measured on agentmods" 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 | $0.00059 | $0.01053 |
| Opus 5 | $0.00030 | $0.00526 |
| Sonnet 5 | $0.00012 | $0.00211 |
| Haiku 4.5 | $0.00006 | $0.00105 |
Grade A, and why
explain 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 4d 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 — 62 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Document Package: make an internal package self-explaining to any model
Most internal packages ship with no usage docs, so every consumer: a teammate, or an AI: reads the source, guesses the intended usage, and gets the gotchas wrong. This skill fixes that: one colocated usage doc per public unit, capturing the API and the non-obvious rules, so the next reader is correct on the first try. It applies to any package: a UI component kit, a utils library, a services/API layer, a hooks package, an internal SDK.
Why it matters for portability: these docs are the layer that makes your package understandable to any model. If you move from one AI tool to another, the new model still understands your package immediately: the knowledge lives in the repo, not in one model's head.
Ask first: always
This writes files into the user's repo. Confirm before doing anything: "I can generate AI-friendly
usage docs for <package> so any model (and teammate) understands it correctly: one doc per public unit,
with the gotchas. Want me to? (I'll show one sample first.)" Show a sample doc for one unit and get a
thumbs-up before fanning out across the package.
Method
- Discover the public units. Read the package's public entry (
index.ts/exports) for the real list, components, exported functions, hooks, services, classes. Note any existing docs' style and match it. - Never write a line you have not read the source for. For each unit: the implementation, its types, its variants/options, its tests/stories, and one real usage in the codebase. Verify every claim against the code (never document a guess; mark "unverified" or omit).
- Write a colocated doc (a
README.md/doc beside the unit) with a consistent template:- Title + one-line purpose + what it's built on.
- Signature / API: a table: params/props/args · type · default · description; what it returns.
- Quick start: the minimal correct usage (real import path).
- Variants / options / states (where applicable), with a code example each.
- Composition: how it combines with siblings.
- Examples: the handful of real scenarios people actually need.
- Gotchas: the highest-signal section: rules the API doesn't enforce but people get wrong (default values, which state hides what, reserved-but-unimplemented options, ordering constraints).
- Errors / accessibility / TypeScript: as relevant to the unit's kind.
- Prioritize the gotchas. The API table can be inferred from types; the gotchas cannot. That's the value.
- Stamp it so drift is detectable. The code is the SSOT; the doc is derived: so record what it
was derived from, the way
engineering/ROUTER.mdrecords a hash per node. End each doc with a footer naming the source file(s), the repo commit SHA at generation time, and a short content hash of each source (git rev-parse --short HEAD,git hash-object <file>):
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.
- 4d ago First seen · 62 lines · 0 tokens per session scan A cda283f01601
explain is a skill published in the GitHub repository mehrad-dm/mastermind (24 stars, last pushed 4d ago), licensed MIT. It adds 59 tokens to every session and 1,053 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
docker-extend
Use when: User wants to extend Docker with custom tools, personalize the Docker environment, or set up user-specific Docker customization. Triggers: 'extend docker', 'docker-extend', 'add tools to docker', 'customize docker', 'add my tools to the container', 'personalize docker setup', 'docker user setup', 'install…
write-zot-themes
Help the user create, install, or package zot themes, including theme-only extensions.
st-full-workflow
Use when the user asks to run the complete end-to-end Strikethroo workflow for a work order in one shot in this repository — triggers include full workflow, end-to-end, plan and execute, do everything, run the whole strikethroo workflow. Do not use when the user wants only one stage (create a plan, generate tasks, or…
st-code-review
Use when the blueprint execution gate asks for an independent second-harness review of a Strikethroo plan's cumulative diff in this repository — triggers include code review gate, review the plan diff, second-model review, CODEREVIEW hook, review the cumulative diff. Do not use to review a single task, to review code…
st-refine-plan
Use when the user asks to review, refine, improve, interrogate, pressure-test, or update an existing Strikethroo plan by plan ID in this repository — triggers include refine plan, improve plan, review plan, red-team the plan, update plan. Do not use to create a new plan, to generate tasks, or for generic brainstorming…
tlamatini-daily-chat-test
Run the daily automated Tlamatini chat regression — drive a visible Chrome via Playwright, log into agentpage.html, ask up to 1000 curated safe questions one-by-one (Multi-Turn ON, ACPX/Ask-Execs/Exec-Report/Internet OFF), wait for and qualify each answer (heuristic + LLM judge on failures), then write a dated report…