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 mehrad-dm/mastermind --skill qagit 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/qa)<a href="https://agentmods.dev/skills/mehrad-dm/mastermind/qa"><img src="https://agentmods.dev/badge/skills/mehrad-dm/mastermind/qa/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/mehrad-dm/mastermind/qa"><img src="https://agentmods.dev/badge/skills/mehrad-dm/mastermind/qa.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 2 findings, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Rogue Agent · line 15 Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.Fix: Remove any persistence mechanisms (cron jobs, startup scripts, state files). Skills should not maintain state across sessions without explicit user consent.
- medium Agent Snooping · line 69 Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.Fix: Remove all code or instructions that list or read other skills' files or directories. Skills should operate independently; cross-skill access is a privilege escalation.
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.00066 | $0.01864 |
| Opus 5.5 | $0.00026 | $0.00746 |
| Sonnet 5.5 | $0.00013 | $0.00373 |
| Haiku 4.5 | $0.00007 | $0.00186 |
Grade A, and why
qa 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 15d 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 — 110 lines — stays where its author put it; the contents beside it link to each section on GitHub.
QA: prove it works (verify by default, tests on request)
Proving a change works is mandatory: though the proof is rarely a test suite. Default to verify (drive the real thing, watch what it does). Tests / TDD are a project choice: offer them, don't impose them. After a build, the honest close is: "Built it: want me to QA it? (I can verify it end-to-end, and add tests / do it test-first if you want.)"
Mode 1: Verify (the default; always do this)
-
Write the checklist before you look. Turn the expected behavior into a short list of criteria that are each individually checkable: one line per criterion, phrased so the answer is met or not met, never "looks fine". Write it before exercising anything, because a list written while looking is a list that describes what you found. If you can't say what correct looks like, you can't verify it.
Prefer criteria a person could count or observe over ones needing an opinion: "a second submit while pending is rejected" beats "handles concurrency well." This list is what you report against in step 5, and what makes "it works" mean something.
-
Pick the lightest real check. Drive the actual thing over reasoning about it: run the app and click the flow, hit the endpoint, run the script/CLI, render the component. Reuse the project's run/dev command; reach for harness the project already has.
-
Happy path, then the edges that matter: empty, null, error, loading, zero/one/many, unauthorized, malformed, offline/slow (
~/.mastermind/engineering/core/rigor.md). Observe actual output and state. -
Check the invisible: typecheck, lint, build; console/network for errors; for UI, keyboard + focus, contrast, no layout shift/regression nearby.
-
Say what must NOT happen, not only what must. Half of a real check is a negative: no request was sent, the tokens were not cleared, the user was not bounced to login, no second write landed. A test that only asserts the visible message passes while the damage happens behind it.
-
Report with evidence: what you ran and what you observed (command output, response, screenshot). State confidence plainly. Couldn't run a check? Say so; never present unrun work as verified.
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.
- 15d ago Changed · +5 lines 14802d00235f
- 1mo ago First seen · 105 lines · 66 tokens per session scan A 292d99dcf88e
qa is a skill published in the GitHub repository mehrad-dm/mastermind (23 stars, last pushed 6d ago), licensed MIT. It adds 66 tokens to every session and 1,864 once invoked, about $0.0003 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
test-fix
Diagnose and minimally fix a failing test, then re-run.
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code. Enforces red-green-refactor cycle with strict rules.
browser-inspect
Browser inspection and interaction for verifying rendered web UI during development.
review
Review current code changes for bugs, regressions, test gaps, and project-guideline violations.
coder-self-review
Deterministic self-evaluation rubric for Coder — scored every run using the GRASP framework.
hatch3r-browser-verify
Opt-in browser verification skill — spec-run-first Playwright verification (assertions execute in the runner, agent reads only failures), axe-core a11y audits, toHaveScreenshot() regression diffs, E2E test scaffolds, and snapshot-mode exploratory driving. Default ON for UI-affecting agent invocations; disable globally…