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 rough ask into a prompt an AI executes well:
clear intent, only the context that matters, structured, token-efficient.
The user's own words are not yours to rewrite. Fire only on an explicit ask, propose rather
than apply, and name every requirement you added or cut, ~/.mastermind/engineering/core/rigor.md § Stay in scope.
Do not fire unless asked
Auto-invocation is the danger here: rewriting a prompt the user meant you to answer replaces their
work with your paraphrase and loses whatever they actually wanted. The bar is an explicit request to
improve the prompt.
| The user does this |
You do this |
| "improve / fix / sharpen this prompt" |
This skill |
| Pastes a prompt and says "run this" / "what do you think?" / nothing |
Answer or execute it. Not this skill |
| Pastes a prompt written for another tool, asking what it does |
Explain it. Not this skill |
| Asks for a prompt to be written from scratch |
Write it: then the checklist below applies |
If it's genuinely ambiguous, ask one question before rewriting. Guessing wrong wastes a turn; rewriting
unasked destroys their text.
The prompt stays theirs
The output is a proposal, never an action:
- Never execute the rewritten prompt: not in the same turn, not "to show it works". Hand it back.
- Never drop a requirement. Every constraint in the original survives, or you say out loud that you
cut it and why. Silent removal is the failure mode that makes this skill dangerous.
- Never add a requirement they didn't imply. Additions get named in "what changed": a specific the
user never chose (a framework, a length, a tone) is a guess wearing their voice.
- Never rewrite a prompt containing credentials, private data, or client names into a form that
moves them somewhere new. Flag them and quarantine instead (
quarantine).
First: get the real intent
If the goal is ambiguous, ask one or two sharp questions before rewriting: the rewrite carries only
requirements the user actually implied. You sharpen their intent; it stays theirs.
The rewrite checklist (apply what fits: keep it lean)
- 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. Context is never the cruft; padding is.
- 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 an example, not just a description: but show two or three varied ones, labeled
illustrative. A single gold example gets copied: the model matches its length, tone and structure.
- Set the role when it sharpens tone/expertise ("You are a senior accessibility engineer…").
One line. A role statement is not a substitute for saying what the output must contain.
- Pin the output contract: format, length, what to include/exclude, and any must-nots.
- Say what to do, not what to avoid. "Answer in three sentences" beats "don't be verbose";
a list of prohibitions can anchor the model toward the very failure it names.
Keyword effects: what words actually do to a modern model
Prompts written for 2023-era models are now actively harmful, because current models follow
instructions far more literally. What to strip, and what to reach for instead:
| Pattern |
Effect today |
Instead |
CRITICAL: / MUST / NEVER / ALL-CAPS, several per prompt |
Emphasis inflation: when everything is critical, nothing is. Causes over-triggering and rigid behavior in gray areas |
Plain imperative + the reason. Reserve emphasis for the one genuinely load-bearing constraint |
"think step by step", <scratchpad> instructions |
Redundant on reasoning models, which already think; can add latency for nothing |
Control depth with the tool's thinking/effort setting, not prose |
| "double-check your work", "verify before answering" |
Current models self-verify; instructing it causes over-verification and padding. This inverts the old best practice |
Delete. State the acceptance test instead |
| "be thorough", "don't be lazy", "don't stop early" |
Written against models that quit early; now just noise |
Delete |
| "try to", "if possible", "ideally" on a real requirement |
Read literally as permission to skip it |
State it as a requirement |
| "don't hallucinate", "only use the provided context" |
Still useful when grounding genuinely matters |
Keep: but pair it with what to do when the answer isn't there ("say you don't know") |
| Politeness padding, repeated context, restated rules |
Consumes budget and makes the model reconcile wordings |
Say it once, in the right place |
Placement matters as much as wording. Long documents go first, the question last: a model
attends best to the start and end, and a question buried above 50k tokens of context gets lost. If the
same preamble is reused across calls, keeping it stable and at the front is also what makes prompt
caching hit (core/agent-loop.md).
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, never a shorter prompt
that drops requirements. Length is not the metric: a too-short prompt produces generic output because
the model fills the gaps with safe defaults.
Output
Return, in this order:
- The optimized prompt: ready to paste, in a copyable block. Nothing else in that block.
- What changed & why: 2–4 bullets, and every one of them names an addition or a removal
(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.
Flag any change of scope out loud. If the request implies a product/business decision, surface it rather
than guessing (product-sense.md).
1---2name: prompt3description: MasterMind: Prompt4---56# MasterMind: Prompt78The single biggest lever on AI output quality is the prompt. Most weak results aren't a model failure,9they're an **under-specified request**. This skill rewrites a rough ask into a prompt an AI executes well:10clear intent, only the context that matters, structured, token-efficient.1112> **The user's own words are not yours to rewrite.** Fire only on an explicit ask, propose rather13> than apply, and name every requirement you added or cut, `~/.mastermind/engineering/core/rigor.md` § Stay in scope.1415## Do not fire unless asked1617Auto-invocation is the danger here: rewriting a prompt the user meant you to *answer* replaces their18work with your paraphrase and loses whatever they actually wanted. The bar is an **explicit request to19improve the prompt**.2021| The user does this | You do this |22| --- | --- |23| "improve / fix / sharpen this prompt" | This skill |24| Pastes a prompt and says "run this" / "what do you think?" / nothing | **Answer or execute it.** Not this skill |25| Pastes a prompt written for *another* tool, asking what it does | Explain it. Not this skill |26| Asks for a prompt to be *written* from scratch | Write it: then the checklist below applies |2728If it's genuinely ambiguous, ask one question before rewriting. Guessing wrong wastes a turn; rewriting29unasked destroys their text.3031## The prompt stays theirs3233The output is a **proposal**, never an action:34351. **Never execute the rewritten prompt**: not in the same turn, not "to show it works". Hand it back.362. **Never drop a requirement.** Every constraint in the original survives, or you say out loud that you37 cut it and why. Silent removal is the failure mode that makes this skill dangerous.383. **Never add a requirement they didn't imply.** Additions get named in "what changed": a specific the39 user never chose (a framework, a length, a tone) is a guess wearing their voice.404. **Never rewrite a prompt containing credentials, private data, or client names** into a form that41 moves them somewhere new. Flag them and quarantine instead (`quarantine`).4243## First: get the real intent4445If the goal is ambiguous, **ask one or two sharp questions before rewriting**: the rewrite carries only46requirements the user actually implied. You sharpen their intent; it stays theirs.4748## The rewrite checklist (apply what fits: keep it lean)49501. **Lead with the task.** State the goal in the first line, plainly. Treat the AI like a sharp new51 hire: say exactly what "done" looks like.522. **Give load-bearing context only**: the *why*, the audience, the stack/constraints, what already53 exists. Cut backstory that doesn't change the output. Context is never the cruft; padding is.543. **Be explicit and concrete.** Replace vague adjectives ("nice", "modern", "clean") with specifics55 (what, for whom, which constraints, which examples to match).564. **Structure it.** Separate the parts, `context` / `task` / `requirements` / `output format`,57 with headings or XML-ish tags (`<context>…</context>`) so the model can parse roles of text.585. **Show an example, not just a description**: but show *two or three varied* ones, labeled59 illustrative. A single gold example gets copied: the model matches its length, tone and structure.606. **Set the role** when it sharpens tone/expertise ("You are a senior accessibility engineer…").61 One line. A role statement is not a substitute for saying what the output must contain.627. **Pin the output contract**: format, length, what to include/exclude, and any must-nots.638. **Say what to do, not what to avoid.** "Answer in three sentences" beats "don't be verbose";64 a list of prohibitions can anchor the model toward the very failure it names.6566## Keyword effects: what words actually do to a modern model6768Prompts written for 2023-era models are now actively harmful, because current models follow69instructions far more literally. What to strip, and what to reach for instead:7071| Pattern | Effect today | Instead |72| --- | --- | --- |73| `CRITICAL:` / `MUST` / `NEVER` / ALL-CAPS, several per prompt | Emphasis inflation: when everything is critical, nothing is. Causes over-triggering and rigid behavior in gray areas | Plain imperative + the reason. Reserve emphasis for the one genuinely load-bearing constraint |74| "think step by step", `<scratchpad>` instructions | Redundant on reasoning models, which already think; can add latency for nothing | Control depth with the tool's thinking/effort setting, not prose |75| "double-check your work", "verify before answering" | Current models self-verify; instructing it causes *over*-verification and padding. This inverts the old best practice | Delete. State the acceptance test instead |76| "be thorough", "don't be lazy", "don't stop early" | Written against models that quit early; now just noise | Delete |77| "try to", "if possible", "ideally" on a real requirement | Read literally as permission to skip it | State it as a requirement |78| "don't hallucinate", "only use the provided context" | Still useful when grounding genuinely matters | Keep: but pair it with what to do when the answer isn't there ("say you don't know") |79| Politeness padding, repeated context, restated rules | Consumes budget and makes the model reconcile wordings | Say it once, in the right place |8081**Placement matters as much as wording.** Long documents go **first**, the question **last**: a model82attends best to the start and end, and a question buried above 50k tokens of context gets lost. If the83same preamble is reused across calls, keeping it stable and at the front is also what makes prompt84caching hit (`core/agent-loop.md`).8586## Token efficiency (efficient ≠ lossy)8788Cut politeness padding, redundancy, and repeated context; compress prose to bullets; keep every89detail that changes the output and no more. Fewer tokens *and* a sharper signal, never a shorter prompt90that drops requirements. **Length is not the metric**: a too-short prompt produces generic output because91the model fills the gaps with safe defaults.9293## Output9495Return, in this order:96971. **The optimized prompt**: ready to paste, in a copyable block. Nothing else in that block.982. **What changed & why**: 2–4 bullets, and every one of them **names an addition or a removal**99 (e.g. "added output format; cut 3 lines of backstory; made 'fast' concrete = <2.5s LCP").1003. **Open questions**: anything still genuinely ambiguous the user should decide.101102Flag any change of scope out loud. If the request implies a product/business decision, surface it rather103than guessing (`product-sense.md`).
mehrad-dm