Prompt
⚗️ 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.
npx -y skills add mehrad-dm/mastermind --skill promptAssembled 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 request aimed at an AI is vague, rushed, or under-specified and the user wants it sharpened — "improve my prompt", "fix this prompt", "how should I ask for this" — or before firing an expensive task off a thin prompt. About prompts for an AI, not about optimizing code.
SKILL.md
2.8 KB, as published. Nobody here has run it
MasterMind — Prompt
The single biggest lever on AI output quality is the prompt. Most weak results aren't a model failure —
they're an under-specified request. This skill rewrites a user's rough ask into a prompt an AI will
execute well: clear intent, only the context that matters, structured, and token-efficient. Grounded in
Anthropic's prompt-engineering guidance (~/.mastermind/engineering/core/agent-loop.md, product-sense.md).
First: get the real intent
If the goal is ambiguous, ask one or two sharp questions before rewriting — never invent requirements the user didn't imply. You sharpen their intent; you don't hijack it.
The rewrite checklist (apply what fits — don't bloat)
- Lead with the task. State the goal in the first line, plainly. Treat the AI like a sharp new hire: say exactly what "done" looks like.
- Give load-bearing context only — the why, the audience, the stack/constraints, what already exists. Cut backstory that doesn't change the output.
- Be explicit and concrete. Replace vague adjectives ("nice", "modern", "clean") with specifics (what, for whom, which constraints, which examples to match).
- Structure it. Separate the parts —
context/task/requirements/output format— with headings or XML-ish tags (<context>…</context>) so the model can parse roles of text. - Show, don't just tell. Add one short example of the desired output (or a reference to match) when words alone are ambiguous — few-shot beats adjectives.
- Set the role when it sharpens tone/expertise ("You are a senior accessibility engineer…").
- Pin the output contract — format, length, what to include/exclude, and any must-nots.
- Ask for reasoning on hard/analytical tasks ("think step by step before answering").
Token efficiency (efficient ≠ lossy)
Cut politeness padding, redundancy, and repeated context; compress prose to bullets; keep every detail that changes the output and no more. Fewer tokens and a sharper signal — not a shorter prompt that drops requirements.
Output
Return, in this order:
- The optimized prompt — ready to paste, in a copyable block.
- What changed & why — 2–4 bullets (e.g. "added output format; cut 3 lines of backstory; made 'fast' concrete = <2.5s LCP").
- Open questions — anything still genuinely ambiguous the user should decide.
Never silently change scope. If the request implies a product/business decision, surface it rather than
guessing (product-sense.md).