The Prompt Library Every Mac Power User Should Steal

Most “prompt library” posts are padding around three prompts that boil down to “please be good.” This one is the actual library — all ten prompts I run daily, printed in full, with notes on when to use each and which model tier it needs. Local 8–14B means it works fine on a small Ollama model; frontier means use your strongest model, the task punishes weakness. Copy everything; that’s the point.

The text workhorses

1. The summarizer that preserves numbers and caveats. Generic summarizers produce confident mush and round your numbers. Tier: local 14B is fine.

Summarize the text below in [N] bullet points. Rules:
- Preserve every number, date, percentage, and amount EXACTLY as written.
- Preserve hedges and caveats ("preliminary", "in mice", "up to",
  "excluding one-time costs"). Never upgrade a hedged claim to a
  confident one.
- If the text contradicts itself, say so in a final bullet.
- No introduction, no conclusion, bullets only.

The caveat rule is the load-bearing one. The difference between “the drug worked” and “the drug worked in mice” is the difference between a summary and a liability.

2. The email reply in my style. I keep three real, anonymized emails I’ve written pasted permanently into this template. Tier: local 14B for routine mail; frontier when stakes or nuance are high.

Below are 3 examples of emails I wrote. Learn the style: greeting
form, sentence length, directness, sign-off. Then draft a reply to
the email at the bottom that [GOAL: e.g., declines politely but
leaves the door open].
Rules: my style, not yours. No "I hope this email finds you well."
Match the language of the incoming email (I write Czech and English).
Keep it under [N] sentences.

MY EXAMPLES: [...]
EMAIL TO ANSWER: [...]

3. The rewrite-for-clarity editor that doesn’t change meaning. For my own drafts. Tier: frontier — small models “improve” meaning when asked to improve prose.

Edit the text below for clarity and concision. You may: split
sentences, cut redundancy, fix grammar, reorder within paragraphs.
You may NOT: add claims, remove claims, change hedges to certainties
or vice versa, alter technical terms, change my tone from [casual/
formal]. After the edit, list every place where you were tempted to
change meaning but didn't — that list is how I check you.

That final self-reporting line sounds like a gimmick; it’s the most effective honesty mechanism I’ve found.

4. The translation prompt with tone preservation. As a Czech working in English, I translate daily, and naive translation flattens register — Czech formal vykání and casual tykání both come out as the same beige English. Tier: frontier for anything that will be read by a human who matters.

Translate from [Czech] to [English]. Rules:
- Preserve register: if the source is formal (vyká), the target must
  be equivalently formal; if casual/jokey, keep it casual/jokey.
- Idioms: translate to an equivalent idiom, not literally. If no
  equivalent exists, render the meaning plainly and flag it.
- Keep names, product terms, and numbers untouched.
- Output the translation, then up to 3 translator's notes for choices
  a reviewer should check.

Example of why this earns its place: “to je v pohodě” rendered literally is “that is in calm.” With this prompt: “no worries.” The notes section once saved me from sending a Czech idiom about carrying wood to the forest to a confused American client.

The thinking partners

5. The devil’s advocate for decisions. Used before any decision involving money or commitments. Tier: frontier, always — sycophancy correlates inversely with model strength.

I have decided to [DECISION] because [MY REASONING]. Argue against
me. Specifically:
1. Attack my strongest stated reason, not a strawman.
2. Name the assumption I'm making that is most likely false.
3. Steelman the best alternative I'm rejecting.
4. Tell me what evidence would change your attack.
Do not balance your answer with support for my view. I have the
supportive case already — it's mine.

6. The “what am I not asking” blind-spot finder. The last prompt of any research session, and the one readers thank me for most. Tier: frontier.

Context: I am working on [PROJECT/DECISION] and so far I have asked
you about [LIST OF QUESTIONS ASKED]. Based on this pattern: what
important questions am I NOT asking? List 5, ordered by potential
to change my outcome, with one sentence each on why I'm probably
avoiding or missing it.

When I was choosing between Mac Studio configs, every question I’d asked was about RAM and models. This prompt’s first output: “You haven’t asked what your actual weekly usage hours justify spending.” Annoyingly correct.

7. The research question decomposer. Run before researching anything nontrivial. Tier: local 14B works; frontier decomposes better.

I want to answer: [BIG QUESTION]. Decompose it into 4-7 sub-questions
such that: each is independently answerable, each is concrete enough
to search for, answering all of them answers the original, and they
are ordered by dependency (which must be answered first). Mark which
sub-questions are factual (look-up-able) vs. judgment calls (only I
can answer). Do not answer any of them yet.

That factual-vs-judgment split is the secret: it shows you which parts to delegate to the machine and which parts were always going to be your call.

The professional pair

8. The code reviewer focused on bugs, not style. Tier: frontier for real reviews; a local Qwen-coder 14B catches the shallow half.

Review this diff for BUGS ONLY: logic errors, off-by-ones, race
conditions, unhandled errors and edge cases (empty input, nil,
unicode, huge input), security issues, resource leaks. Do NOT
comment on style, naming, or formatting — a linter owns those.
For each finding: severity (will-break / might-break / smell),
the line, and the failing scenario described concretely. If you
find nothing serious, say so — do not invent findings to seem
useful.

[DIFF]

The anti-invention clause matters: review prompts without it generate noise to justify their existence.

9. The explain-like-I’m-senior. The inverse of ELI5 — explanations that skip the basics. Tier: frontier; this is exactly where weak models hallucinate confidently.

Explain [TOPIC] to someone senior in [ADJACENT FIELD]. Assume I know
[LIST: e.g., transformers, quantization basics]. Skip all analogies
and history. Focus on: what's mechanically different from what I
already know, the non-obvious failure modes, and what the experts
argue about. Use precise terminology without defining common terms.

10. The meeting-notes structurer. Covered in depth in yesterday’s post, included here so the library is complete: transcript in → TL;DR, decisions, action items with owner-or-UNATTRIBUTED, open questions — with hard rules to never guess attribution and preserve numbers exactly. Tier: local 14B handles it well. Find the full text in the meeting-notes article; it’s verbatim stealable there too.

The management layer — storage, versioning, evolution

A prompt library you can’t summon in two keystrokes doesn’t exist. Three storage options, in order of my preference:

Raycast snippets — each prompt as a snippet with a keyword like !sum, !da, !cr, using {argument} placeholders for the variable parts. Type the keyword in any text field, the prompt expands, paste your content. Free, instant, works in every app. Ollama Modelfiles for prompts you use with local models constantly — bake the prompt into a named model so it survives even lazy invocation:

# Modelfile
FROM qwen2.5:14b
SYSTEM "You are a summarizer. Rules: preserve every number exactly..."

ollama create summarizer -f Modelfile
ollama run summarizer < article.txt

Any text expander (Espanso is the free, open-source one) if you don’t use Raycast.

Then version them like code, because they are code — instructions that program a stochastic computer. Mine live in a git repo, one .md file per prompt, with a ## Changelog section. When an output disappoints, the meta-skill is a tight loop: diagnose the failure class, add a rule targeting it, note the change. Concrete example from the summarizer’s history: v1 said “preserve key numbers.” Outputs kept rounding €47,500 to “about €50k” — the model decided which numbers were “key.” v2: “preserve every number, date, percentage, and amount EXACTLY as written.” Failures stopped that day. The general principle: when output disappoints, your prompt has an ambiguity the model resolved differently than you would. Find the ambiguity, close it with a rule, commit. Three or four such cycles and a mediocre prompt becomes a production-grade one — which is exactly how all ten above got that way.

Steal the library. But the durable asset isn’t these ten prompts — it’s the habit of treating prompts as maintained tools instead of incantations typed fresh each time.

Start with the two you’d use tomorrow morning, wire them into Raycast tonight, and let the rest of the library earn its place one disappointing output at a time.