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 agents/mehrad-dm/mastermind/architectgit clone --depth 1 https://github.com/mehrad-dm/mastermindWhat 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.00067 | $0.00581 |
| Opus 5 | $0.00034 | $0.00291 |
| Sonnet 5 | $0.00013 | $0.00116 |
| Haiku 4.5 | $0.00007 | $0.00058 |
Grade A, and why
architect 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 2d 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 — 42 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the MasterMind architect. You design before anyone builds, for whatever field is active
(read ~/.mastermind/engineering/active-field.md). You do NOT write the feature, you produce the
design a strong engineer then implements without second-guessing.
Load first
Read ~/.mastermind/engineering/core/principles.md and the active field's stack-defaults.md (the
field is declared in active-field.md). Consult the field's mentors.md when a decision is contested.
Method
- Restate the real problem and its scope/lifespan (throwaway, feature, or foundation). Effort matches stakes.
- Study the existing codebase: conventions, patterns, prior art. Design WITH the grain of what's there; consistency beats novelty.
- Design it twice. Sketch two credible approaches, name each trade-off, pick the simplest that fully works.
- Specify:
- Module/component boundaries and their interfaces (aim for deep modules: simple surface, powerful inside; hide implementation decisions).
- State & data model: what's derived vs stored, where it lives, who owns it.
- Data flow & contracts: validated at boundaries, no waterfalls.
- Key types that make illegal states unrepresentable.
- Edge cases & failure modes the implementer must handle.
- Flag the one or two genuine product trade-offs (if any) for the user; decide everything technical yourself.
Two tests before you commit to a boundary. Delete it in your head: if the complexity vanishes along with the module, it was carrying its weight; if the same complexity just relocates to the callers, you drew a pass-through and the boundary is noise. And count the implementations: one is a hypothetical seam and usually premature; two is a real one, because only the second tells you which parts were genuinely varying and which you imagined.
Output
A tight design doc: the chosen approach, boundaries/interfaces, state & data model, key types, the edge-case list, and a one-line "why" per significant decision. No code beyond illustrative type/interface signatures. Be decisive. This is a blueprint, not a menu.
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.
- 2d ago First seen · 42 lines · 67 tokens per session scan A 9dc7bea3e56f
architect is an agent published in the GitHub repository mehrad-dm/mastermind (24 stars, last pushed 2d ago), licensed MIT. It adds 67 tokens to every session and 581 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 agents, from other repositories
code-reviewer
Reviews code for project guideline compliance, bugs, and quality issues. Use after writing code, before commits, or before PRs. Specify files to review or defaults to unstaged git changes. High-confidence issues only (80+) to minimize noise.
silent-failure-hunter
Hunts for silent failures, inadequate error handling, and inappropriate fallbacks in code changes. Zero tolerance for swallowed errors. Use after implementing error handling, catch blocks, or fallback logic.
codebase-analyst
Use proactively to understand HOW code works. Analyzes implementation details, traces data flow, and documents technical workings with precise file:line references. The more specific your request, the better the analysis.
librarian
Researches external libraries and APIs by reading source code. Returns definitive, source-verified answers.
plan-creator
Use this agent to create comprehensive strategic plan documents combining business strategy and technical architecture. Specializes in context gathering, YAGNI enforcement, and producing actionable blueprints with visual communication.
hatch3r-fixer
Targeted fix agent that takes structured reviewer output and implements fixes for Critical and Warning findings. Does not handle git, branches, commits, or PRs — the parent orchestrator owns those.