Learn

Skill mehrad-dm/mastermind/skills/learn

⚗️ Experimental — A genius-builder brain for your AI coding tools: sharp defaults, real judgment, and the discipline to check their own work. For Claude Code, Codex, Cursor & Copilot. Just markdown; it improves itself over time.

Install

npx -y skills add mehrad-dm/mastermind --skill learn

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

29 days oldThe repository was created 29 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
13 stars13 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when a task depends on tech you don't actually know — an unfamiliar library, a fast-moving framework, a tricky API, an unfamiliar codebase — or whenever "I think it works like…" is load-bearing. Just-in-time and task-scoped; distinct from levelup, which updates the durable knowledge base.

SKILL.md

2.8 KB, as published. Nobody here has run it

MasterMind — Learn

The invokable form of ~/.mastermind/engineering/core/agent-loop.md → "Learn the stack before you build." Topic/task: $ARGUMENTS. Goal: reach genuine, current understanding — enough to build to standard — fast, and cheap on context.

1. Detect what's actually used

Read package.json/lockfile, configs, and representative source to see the exact stack (framework + versions, styling, state, data, test runner) and the team's conventions. Installed versions matter — APIs drift, so learn the version that's actually here.

2. Map the skill-tree

Use the relevant roadmap.sh role/topic map as the checklist of what matters and to spot your gaps. Don't learn the whole tree — learn the branch the task touches.

3. Learn to current standards

Read the primary docs for the specific APIs the task needs (verify against the installed version) and skim one battle-tested example (the field's curriculum.md lists them). Prefer primary sources; never rely on stale memory (the field's learning-sources.md).

4. Ground it in this codebase

Grep for how the pattern is already used here and match it. Consistency beats novelty.

5. Grill your assumptions before you build

The costly bugs come from assumptions you never checked. Before committing code:

List what you believe about the APIs you'll use (behavior, signatures, return values, limits, versions, edge cases) — specifically ("getFile streams any size" — true?).
Answer from the source yourself first — verify each against the docs/types/actual source (for the installed version). Confirm ✓, correct ✗, or mark unknown ❓. Never ask the user what the code/docs answer.
For each remaining unknown, propose — don't just flag. State a best-guess resolution + confidence ("probably streams; ~70%") so a human can confirm or correct, not author it. Serve interdependent unknowns one at a time. Anything still unconfirmed becomes an explicit risk or a tiny spike — never a silent guess. No load-bearing assumption ships unverified.

Output & economy

Return a tight working brief: the stack + versions, the few APIs/patterns the task needs, the gotchas (and the grilled assumptions ledger: claim → verified/corrected/unknown → source · confidence), and links to the primary sources — not a tutorial. Delegate wide reading to a subagent to protect context. If you learned something durable and reusable, capture it via levelup.