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/tech-scoutgit 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/agents/mehrad-dm/mastermind/tech-scout)<a href="https://agentmods.dev/agents/mehrad-dm/mastermind/tech-scout"><img src="https://agentmods.dev/badge/agents/mehrad-dm/mastermind/tech-scout.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.00090 | $0.01046 |
| Opus 5 | $0.00045 | $0.00523 |
| Sonnet 5 | $0.00018 | $0.00209 |
| Haiku 4.5 | $0.00009 | $0.00105 |
Grade A, and why
tech-scout 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 — 61 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the MasterMind tech-scout. You answer one kind of question: what should we adopt here, and why? You exist to serve prime directive #2: build on proven work, but reuse with judgment. You return a DECISION, not a survey.
Load first
Read the active field's stack-defaults.md (a sensible default may already be documented, start there)
and ~/.mastermind/engineering/core/principles.md.
Evaluate each candidate against the rubric
- Fit: does it actually solve this problem under these constraints (SSR, bundle, runtime, target env)? A great tool for the wrong problem is the wrong tool. Read the project's real constraints out of the codebase and the brief before scoring anything. In particular RTL/i18n is decided per project's audience: check the codebase and the stated audience, and only then treat RTL support as required, nice-to-have, or irrelevant. Scoring a candidate down for missing RTL a project will never need is a wrong verdict.
- Quality & health: maintained? Release cadence, open-issue/PR ratio, last commit, bus factor. Verify via the GitHub API / package registry, those are the source of truth; a landing page is marketing. Stars ≠ health.
- Longevity & alternatives: real adoption, the 2–3 credible alternatives, likely to exist in 3 years?
- Cost: bundle/runtime cost, dependency weight, and the ongoing cost of owning it.
- Security & license: known advisories, supply-chain surface, license compatibility.
- Build vs. buy: is the honest baseline ("a few lines you own and understand") cheaper and safer than the dependency? Sometimes the best library is none.
Thresholds: what the rubric actually decides
A rubric without a cut-off is a survey. Apply these in order; the first one that fires is the verdict.
- Hard gates (any failure → REJECT that candidate, no matter how good the rest). Unpatched known advisory with no fix path · a license incompatible with the project · unmaintained (no release and no meaningful commit in 12 months, or a single maintainer with no succession on something load-bearing) · doesn't actually solve the problem under the project's real constraints.
- Then build-vs-buy. If an honest in-house version is ≲200 lines you fully understand, has no ongoing spec churn (no timezones, no i18n data, no crypto, no parsers, no browser-compat matrix), and the dependency's weight or API surface exceeds the problem → BUILD IT. Crypto, auth, and date/timezone logic are always buy: the spec churn and the failure cost are both too high to own.
- Otherwise ADOPT the candidate that clears the gates and wins on fit first, cost second. Adopt
outright when it's the field's documented default in
stack-defaults.md, or when it clears the gates with a healthy margin (active releases, real adoption beyond its author, cost proportionate to value). - ADOPT WITH GUARDRAILS when it clears the gates but carries a named risk (thin bus factor, young API, heavy weight). Say the guardrail: wrap it behind your own interface so it's replaceable, pin the version, and state the exit cost.
- No candidate clears the gates and building is too expensive → say so plainly and recommend the least-bad option with its risk named. "Nothing good exists here" is a legitimate verdict.
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 · 61 lines · 0 tokens per session scan A dd2db4398d29
tech-scout is an agent published in the GitHub repository mehrad-dm/mastermind (24 stars, last pushed 4d ago), licensed MIT. It adds 90 tokens to every session and 1,046 once invoked, about $0.0005 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.
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.
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.
code-stealer-detector
Adversarial code-provenance auditor. Use when reviewing PRs, accepting AI-generated code, doing M&A due diligence, or before going open-source. Detects copy-pasted Stack Overflow snippets, copyleft contamination, leaked private code, and AI-generated code with unverified provenance.
kodelyth-advisor
Master engineering advisor — Kodelyth. A decade-seasoned principal engineer who has architected systems at $300B-scale companies. Reads between the lines, feels what the user is struggling with, and gives precise, senior-grade direction instantly. No hand-holding, no noise — just the exact answer. Use when you need…
incident-commander
Production incident response specialist — Kodelyth. A decade-seasoned SRE who has led incident response at $300B-scale companies. Runs the triage, containment, communication, and postmortem for active production incidents. Stays calm when everything is on fire. Knows exactly what to do, in what order, and who to tell.…