EPISODE 05 · How to talk to AI · 2026.05.17

A prompt isn't a spell.
It's a spec.

This is a talk about how to talk to AI.
More accurately — it's a talk about giving up the search for the "magic words."

Start with the word →
AGENT 101 SERIES · EP 05 · NO-BULLSHIT EDITION
§ 01 · Start with the word

"Prompt" also means three different things in three mouths

Like "Agent" in EP01, the word "prompt" is overloaded. Some treat it as a spell, some as a product — only one use loses information when you delete it: a spec you write for a machine so it can do the work.

  • USE · 01 · THE SPELL HUNTERS

    Prompt = a magic incantation

    "Is there one line that makes AI insanely powerful?" — this use imagines the prompt as a magic password, some hidden switch. There isn't one. The same "spell" produces wildly different results in different contexts. Spell hunters are always looking for the next line, never figuring out what they actually want.

  • USE · 02 · THE BUNDLE SELLERS

    Prompt = a product

    "1000 high-efficiency prompts for $99" — the placebo from EP01. Prompts are deeply personal; a prompt written for someone else's workflow runs at under 5% efficiency in yours. Treating prompts as a wholesalable commodity is exactly the sign the seller doesn't know what a prompt is.

  • USE · 03 · THE PEOPLE ACTUALLY USING IT

    Prompt = a spec

    The only use that loses information when deleted. It means: you write out what to do, what context, what constraints, what format, and how "done right" is judged, then hand it to the machine. It's the same thing an engineer does writing a requirements doc — people who can write a spec don't need spells.

§ 02 · Audit your request

"Write me a XX" is an empty phrase

Most of what you say to AI is this kind: write me some copy, analyze this for me, polish this. It sounds like a task, but it fails the three simplest checks. If it fails, all AI can return is a mediocre average.

  • REQUEST TEST · 01

    Is the context you gave enough to get it right?

    "Write me an email" — to whom? What relationship? To achieve what? AI can't read the background in your head. Mediocre output usually isn't it being dumb — it's you treating it like a fortune teller and giving it half a sentence. The information in your context sets the ceiling on the output.

  • REQUEST TEST · 02

    Can you say what "done right" even looks like?

    "Polish this" — polished into what? More formal? Shorter? More persuasive? If you don't have an acceptance standard yourself, AI can only guess at an "average good." A request with no acceptance criteria always returns a safe-but-mediocre answer.

  • REQUEST TEST · 03

    When you're unhappy, can you say exactly what's wrong?

    The critical one. Disliking v1 is normal — but can you point out "too wordy / wrong tone / missed X" so it fixes precisely? If all you can say is "redo it," that's not AI failing, it's you not having thought the request through. The core skill of talking to AI is the ability to give precise feedback.

See the difference? The first makes AI guess; the second lets AI execute — role, context, goal, constraints, format. A good prompt isn't longer — it's more like a spec something can be built from.

§ 03 · After the word

"Hunting spells" and "writing specs" are two completely different ways to communicate

On the same model, two people get output a tier apart. The difference isn't which magic line they used — it's whether their head runs "gamble on a spell" or "write a clear spec." This is the only contrast you need.

SPELL HUNTER · what you might be doing

Gambling, on magic lines

Copies "universal prompts" everywhere, swaps a new one when it fails, never asks what they want.

  • Hoards piles of "god-tier prompt" templates
  • Throws one line over, expects a miracle
  • When unhappy, says "redo it / wrong"
  • Output quality is luck — good some days, not others
SPEC WRITER · who you're becoming

Specifying, with a spec

Writes role + context + goal + constraints + format, then iterates with precise feedback.

  • Decides "what's right" before speaking
  • Gives enough context so AI can aim
  • When unhappy, points to "where, and why"
  • Output is stable, controllable, acceptance-testable
§ 04 · How to write a spec

Four steps: Context → Decompose → Examples → Verifiable output

Every prompt that "nails it first try" is these four steps turning. It's not about writing long — it's about writing all four. Miss context and it drifts; miss acceptance criteria and it's mediocre. Remember the four and you'll know why a prompt doesn't work.

SPEC PROMPT CONTEXT DECOMPOSE EXAMPLES VERIFY
  • 01

    ContextCONTEXT

    Tell it: who you are, who it plays, the background, the goal. AI doesn't read minds; the information you give directly sets the ceiling on its output. Most mediocre answers come from giving the task but not the context.

  • 02

    DecomposeDECOMPOSE

    Don't throw a complex task over in one line. Break it into steps, or have it "think before doing" (outline first, you confirm, then it writes). One-shot big tasks drift most; broken apart, each step is controllable.

  • 03

    ExamplesEXAMPLES

    One good example beats a hundred adjectives. Want a tone or format? Give it one or two samples (few-shot). "Write like this" is far more precise than "write professionally" — examples are the cheapest way to align with AI.

  • 04

    VerifyVERIFY

    Ask for an output whose correctness you can check, and give the acceptance criteria. Then look, give precise feedback, iterate. Treat it like debugging: v1 is a draft; your precise feedback is what forces it into shape.

§ 05 · Patterns by task

Different jobs need a different ask

The "universal prompt" is an illusion. Rewriting, brainstorming, analysis, building — the best ask for each is completely different. Each below gets one minimal pattern + one contrast. Remember the pattern, swap the content anytime.

  • PATTERN · 01 · REWRITE / POLISH "redo it" → nailed in one

    Rewriting: give a "target tone" + an example, not "polish this"

    Contrarian take: rewriting fails most, because "good" is too subjective. Don't say "polish," say which direction — shorter / more formal / more persuasive — and give one sample you approve of as an anchor. Direction + example is how AI knows where to go.

    PATTERNrewrite pattern
    ①SOURCE[paste the text to rewrite]
    ②DIRECTIONtighter / more formal / more casual · be specific
    ③ANCHOR"match the tone of: [a sample you like]"
    ④LIMITSword count / keep these points / avoid these
    FEEDBACK"sentence 2 too stiff, keep the rest" — point precisely
    direction, not "polish" one anchor example precise feedback
  • PATTERN · 02 · BRAINSTORM 5 mediocre → 1 usable

    Diverging: ask for "quantity + dimensions + permission to be wild," not "any suggestions"

    Contrarian take: ask "any suggestions" and you get the safest average. For diverging, reverse it: ask for 20 at once, across different dimensions, allow extreme and absurd. Get breadth first, then have it self-rank the 3 worth digging into.

    PATTERNbrainstorm pattern
    ①QUANTITY"give me 20, not just 3"
    ②AXES"a few each from cost / audience / channel / contrarian"
    ③UNLEASH"allow extreme and seemingly absurd ideas"
    ④CONVERGE"now self-rank, pick the 3 worth digging, with reasons"
    KEYbroad first, narrow later · don't let it pre-judge
    quantity first specify axes converge after
  • PATTERN · 03 · ANALYZE / JUDGE agreeing → actually helping

    Analysis: make it "think before answering" + give the counter-case, don't let it agree with you

    Contrarian take: AI defaults to agreeing with you — ask "is this okay?" and it mostly says yes. For analysis, force independent thinking: reasoning first then conclusion, a mandatory counter-case, explicit flags on what it's unsure of. You want a second brain, not an echo chamber.

    PATTERNanalysis pattern
    ①THINK"reason step by step first, then conclude"
    ②COUNTER"give the strongest opposing case + its basis"
    ③UNSURE"flag clearly what you're unsure of / lack data on"
    ④NO YES-MAN"don't accommodate me just because I lean a way"
    KEYtreat it as a sparring partner · not a fan club
    reason then conclude force a counter-case flag uncertainty
  • PATTERN · 04 · BUILD / CODE runs but wrong → verifiable

    Building: give "verifiable success criteria," not just "write a script"

    Contrarian take: for code/execution tasks, "looks right" is the trap. The key is a machine-checkable success criterion — input/output examples, tests to pass, edge cases. Have it propose an approach for you to confirm, then write, then self-test. Verifiable means trustable.

    PATTERNbuild pattern
    ①GOAL"input is X, expected output is Y" (give examples)
    ②PLAN FIRST"explain approach + trade-offs, I confirm, then write"
    ③VERIFY"include tests / run it to prove it's correct"
    ④EDGES"handle nulls / errors / extreme inputs"
    KEYcode with no acceptance test · equals not written
    give I/O examples plan before code demand self-test
§ 06 · Run it tonight

Three templates — save them tonight, use them tomorrow

Understanding "write a spec" isn't enough; you need a few of your own templates within reach. The three below you can save tonight — not someone's "god-tier prompt," but spec skeletons tailored to your work. Save them, and the first use tomorrow is easier.

DEMO · 01 5 min to save · 10 min saved each time

Build a "spec skeleton" and fit every request to it

Turn "role + context + goal + constraints + format" into a fill-in template and save it to notes or a snippet tool. From now on, any serious request, fill in the five blanks and a spec is done.

  • Save the skeleton below to notes / a Raycast snippet
  • For every serious request, fill in the 5 blanks
  • Can't fill "goal / acceptance"? You haven't thought it through
  • Once it's habit, the skeleton becomes your default ask
  • This one habit beats 1000 copied prompts
spec skeleton · universal template
Role:you are ___ (put it in the right lens)
Context:___ (what it can't know but must, to get it right)
Goal:___ (what to achieve, one line)
Constraints:___ (length / tone / what to avoid)
Format:___ (how it should deliver)
DEMO · 02 10 min setup · reused over and over

Put your most frequent job into a Project's instructions

You don't have to paste a spec every time. Write the "role + context + style + acceptance" of a frequent job once into Claude Project instructions; afterward just give the raw material — the spec is resident.

  • Pick one type of comms you do 3+ times a week (e.g. client replies)
  • Create a Project, write the fixed spec into Instructions
  • Add 1–2 finished pieces you approve of as anchors
  • Afterward, give only this round's material — it knows your standard
  • Unhappy? Go add one more spec line — instructions sharpen with use
claude project · client-reply assistant · instructions
ROLEsenior customer success manager
TONEprofessional, warm, neither servile nor cold (see anchors)
ALWAYSempathize first → give a fix → low-friction next step
NEVERboilerplate openers, over-apologizing, over 150 words
✓ spec is resident · just give material from now
DEMO · 03 each chat · 2 min

Learn to "debug a prompt": let AI question you into clarity

The most counterintuitive and useful move: when you haven't fully figured out what you want, don't force a spec — have AI question you first. It asks, you answer, and a few rounds in, the spec gets forced clear together.

  • Open with: "before you start, ask me the 5 most important questions"
  • Answer its questions seriously — that's the context you were missing
  • Have it organize your answers into a complete spec
  • Confirm the spec, then let it produce for real
  • This "ask first, do later" is especially valuable for complex tasks
claude · have it question you first
YOUhelp me write launch copy. Before starting, ask me 5 key questions.
CLAUDESure — before I write I need to know:
1. Who's it for? Existing users or new?
2. The one thing you most want remembered?
3. Where's it posted? Length and tone limits?
▌ You answer → it builds a spec → then it writes
§ 07 · The next 90 days

From memorizing spells to writing specs

This 90-day path doesn't promise how many magic lines you'll memorize. It gives four specific actions, each with an explicit failure signal. If a week's signal lights up, go back to the previous week. Don't push forward.

  • WEEK 1 – 2 · Quit the one-liner

    Every serious request gets "context + goal" added

    For two weeks, force yourself: no slightly-important request goes out as one line — add at least background and "what counts as right." Failure signal: you still reflexively throw one line over. What to do: stick the §06 spec skeleton next to your input box and fill it in.

  • WEEK 3 – 4 · Practice precise feedback

    When unhappy, force yourself to say "where, and why"

    Drill the feedback after a disliked v1: no "redo it," you must point to the specific sentence, why, and what you want. Failure signal: you're still dismissing with "wrong / rewrite." What to do: stop first, work out your acceptance criteria, then speak.

  • WEEK 5 – 8 · Make frequent specs resident

    Write 2–3 frequent jobs into Project instructions

    Pick 2–3 frequent comms, write the spec into Claude Projects / custom instructions, resident with your standard and anchors. Failure signal: you're still writing the spec from scratch each time. What to do: the job isn't stable enough yet — make the single most repetitive one resident first.

  • WEEK 9 – 12 · Learn to be questioned

    For complex tasks, let AI question you into clarity first

    For a complex task you haven't figured out, switch to "ask first, do later": it questions, you answer, it builds a spec, then executes. Failure signal: you still force a long prompt before thinking it through. What to do: accept that "not figured out" is itself information — hand the clarifying to the conversation.

After 90 days you should be able to answer: "Last time AI gave me a mediocre answer, could I immediately say which part of my spec was underwritten?" — if you can, you've graduated from "memorizing spells" to "writing specs." If you can't, you spent 90 days copying more templates, not learning the real skill of communication.

Real Agent Use Cases

No magic spell — only a clearly written spec

The "god-tier prompt" you copied fails the moment the context changes. But "the ability to state requirements clearly" stays with you for life, on any model.
"Execution is always undervalued." If you don't save your first spec template tonight, tomorrow you'll still throw one line over. That's not a pep talk. It's an observation.

← EP 04 · Obsidian Second Brain　·　EP 05 (you are here)　·　EP 06 (coming)