The blank-prompt problem
Most advice about prompting assumes you can write down exactly what you want before you start typing. In practice, journalists usually can't. You know the shape of the story, you know the source you're trying to verify, you know the type of output you want at the end — but the phrasing that gets you there isn't obvious until you've already started writing.
A half-formed prompt produces a half-formed result. You get something vague back, revise, get something slightly better, revise again. Three rounds in, you've burned tokens and still don't have what you wanted. The problem isn't the model. It's that the prompt was never sharp enough to produce a sharp answer.
Interview instead of declare
A better move: don't write the prompt. Ask the tool to interview you about what you want, then write the prompt for you.
A working version of this, pasted straight into a CLI session:
Before you help me with this, interview me about what I'm trying to do. Ask one clarifying question at a time. Don't try to solve the problem yet. When you have enough to write a well-structured request, stop asking and synthesize the request back to me so I can confirm it before you start work.The pattern is the same one a good editor uses when a reporter pitches a story that's half-formed. Instead of writing the story for them, the editor asks: who's the source, what's the scope, what's the deadline, what are you trying to prove. The answers don't change what the reporter knows — they change what the reporter can put on paper.
Why this works for journalists specifically
Journalism training teaches you how to answer questions under pressure. Most reporters can explain their story in plain language even when they can't write a formal spec for it. The interview approach turns that verbal fluency into a structured prompt without asking you to change how you think.
It also catches the thing you didn't realize you were assuming. If the tool asks "what format should the output be in?" and you hadn't thought about it, you now have to decide — and the decision shows up in the final prompt.
Prompt engineering is itself automatable
The guidance usually handed out as "prompt engineering best practices" — assign a role, use structured sections, specify output format, include examples, ask for clarification on ambiguity — is a checklist. Checklists are templates. Templates can be applied automatically.
Which means you don't need to memorize the checklist. You need a tool that applies it for you. Once you've had the interview conversation, the tool can write the role assignment, structure the request, define the output format, and surface the edge cases — because all of that is boilerplate once the underlying intent is clear.
The thing that's still yours to do is the intent. Knowing which question the story is trying to answer, which source is worth chasing, which framing is fair — that's reporting work, and no amount of templating replaces it. What the template replaces is the busywork of turning clear intent into a well-formed prompt.
When to skip the interview
The interview pattern is overkill for short, single-step tasks. If you want to reformat a date string, you don't need a conversation — you need to paste the string and say what format you want.
Reach for the interview pattern when the request has more than two moving parts, when you're not sure how to describe what "done" looks like, or when you've already tried a direct prompt and gotten something that wasn't quite right. The signal to use it is hesitation, not complexity on paper.
SOURCE: Adapted from the "Prompt engineering on steroids" pattern in Advanced Claude Code Patterns That Move the Needle by The Agentic Lab.
NEXT: Head to Module 1 to set up your CLI tool and start writing context files that make these prompts sharper by default.