The One-Sentence Fix for Bad AI Output

A few weeks back I was on a call with someone who had just stepped into a new job: leading AI strategy inside her company. The rollout that happened before she arrived is the most common one in business right now. Here's Claude, go experiment. Usage got measured. Asking never got taught.

So when someone on her team tells her the AI gave them a bad answer, she's learned to ask one question first. Show me your prompt.

What she finds, in her words, is almost always the worst prompt she's ever seen.

She wasn't knocking her team, and neither am I. Nobody taught them, and these tools feel enough like magic that nobody thinks asking needs to be taught. But that gap produces a specific, expensive moment: a smart person stares at a disappointing response and draws the wrong conclusion. Either the tool is overhyped, or they're bad at this.

Neither one is true. In almost every case, the fix is one sentence.

Bad output is a diagnostic, not a verdict

There are only five things a prompt can specify. When output comes back wrong, one of them is missing. Find it, add a sentence, run it again. That's the whole skill.

We taught this at the first session of our AI for Operators series in June, using the framework we run every day at Gnar. We call it RCTFC. (The name does not roll off the tongue. It's not supposed to. It's supposed to be a checklist.)

• Role: who should Claude be? "You are a proposal manager at a professional services firm." One sentence that sets the lens for everything after it.
• Context: the background it can't infer. The situation, who the output is for, what happened before you showed up with this document.
• Task: your single biggest quality lever. Not "help me with this." "List every requirement in the document, organized by category."
• Format: what the output should look like. A table, an email, a numbered outline. If you don't say, it guesses.
• Constraints: the guardrails. Length, tone, what to leave out, what not to assume.

You don't need all five every time. That's the part people miss. The framework earns its keep when output comes back wrong: check which of the five your prompt never mentioned. That's usually your answer.

At the session we proved it live on a real 50-page RFP we'd responded to. A lazy prompt got us something clever we couldn't use. The RCTFC version turned qualifying the bid, assessing our fit, and outlining a response into about 20 minutes of work that used to eat half a day. Same document. Same model. Different sentences.

The five fixes

Watch enough operators try this and the failure modes turn out to be predictable. Five flavors of bad output, five one-sentence fixes:

• The answer is generic. Missing context. Add your role, the audience, the situation: "This is for our board, who already saw the Q1 version."
• The answer is the wrong length. Name the length. "Two paragraphs." "Under 100 words." Done.
• The answer is the wrong shape. A format problem, and showing beats telling. Paste an example of what great looks like and say "match this structure and style."
• The answer is confidently wrong. Give it an out: "If the document doesn't say, tell me instead of guessing." This single sentence removes most of the confident-sounding errors that scare people off AI. Verify anything that matters anyway; you own what you ship.
• The answer is off in tone. Describe the tone in plain words, or paste a writing sample to match.

If you're using AI at all, you'll hit one of these this week. Everyone does.

When you can't tell what's missing

Sometimes you stare at a bad answer and can't tell which element your prompt lacked. There's a move for that, and almost nobody uses it. Ask Claude:

What assumptions are you making in this response?

It will list them. Somewhere in that list is an assumption that makes you wince, because it guessed at something you knew and never said. That's your missing element. Add it, rerun, and you're done. The model just debugged your prompt for you, and it beats rereading the thing for the tenth time hoping the problem introduces itself.

You're not writing prompts. You're building templates.

At the session Q&A, someone pushed back with the objection you're probably thinking: this framework seems like a lot of work for one prompt. Is it really faster?

Fair. The first RCTFC prompt costs you a few extra minutes. But my co-founder Nick gave the answer worth keeping: you're building a template, not writing a prompt. The next time you qualify a vendor contract or summarize a board packet, you paste the same prompt and swap the document. One great prompt saves you hours across a year.

Here's the one we hand out:

‍

Role: You are a [role] experienced in [domain].

Context: Here's the situation. [Background, who this is for, what happened.]

Task: [The explicit ask: "list every requirement," "draft a one-page summary."]

Format: Give it to me as [a table / an email / a numbered outline].

Constraints: Keep it [under 300 words / formal in tone]. If you're unsure about

anything, say so rather than guessing.

[Paste your document, email, or data below.]

‍

Fill it in once for a task you repeat. Keep it somewhere you can reach it. That's the entire setup.

Borrow her question

A confession before I close. I'm skeptical of most prompt-engineering content. Forty tips, ten secret hacks, most of them restating each other. And here I am handing you a prompting framework. Both things are true. The difference is that this one exists so you can find the missing sentence, not so you can memorize forty.

The AI strategy lead I opened with doesn't teach forty tips either. She asks to see the prompt, because that's where the problem lives. Next time AI disappoints you, or someone on your team announces that it doesn't work, borrow her question before you draw any conclusions.

Show me the prompt.

The fix is usually one sentence away.

Session 1 of AI for Operators, where we teach this live and run the full RFP demo, is on YouTube. One free registration covers the whole series: every recording, the follow-up materials, and the final live session on Tuesday, August 11, on what your engineering team should be doing with AI and how to assess it without being technical.

‍