Measure Twice, Prompt Once

What's the one thing you need to know and do to get the most from AI as a professional? Why does one person get remarkable work out of these tools while another, using the same model on the same day, gets unusable slop? And where should we start, before the agents and skill files and workflows we need as community managers?

Let me start somewhere other than the technology and the jobs to be done from our work map report.

We have built a world that rewards firing before aiming. Ready, fire, aim – it's practically the operating system of modern work. Ship it, iterate, move fast, we'll fix it in post. There are good reasons we got here, and there's a longer column to be written about what that speed has cost us as a culture and has cost us in terms of our health. But here's what matters for getting underway here together: AI is the first tool I've used that punishes this habit immediately, visibly, and at scale – often in imperceptible ways. The gap between what you meant and what you asked for used to be absorbed by colleagues who knew you, by editors, by the friction of doing the work yourself. Some of that is still done by AI, but largely, that good friction is gone.

And I know this because I am exhibit A.

I'm a shoot-from-the-hip guy. A constructivist. Thirty years of building communities, launching ventures, and living with a brain that wants to chase every shiny idea at once has made me fast, intuitive, and — when I'm honest with myself — occasionally sloppy in exactly the way these tools punish that behavior. When AI arrived, my instinct was to just start typing. To start talking to 'it'. Fire off the half-formed thought, see what comes back, react, fire again. It felt like progress. It produced a lot of words. And it produced a lot of overwhelm.

It was not all progress. It was motion. And because I cared and was curious, I went down that rabbit hole trying to make it better... and got further and further away from my intended objectives.

The single highest-leverage practice I've found — the one thing, the foundation everything else in this series stands on — is the oldest advice in any workshop on earth: measure twice, cut once. Every carpenter learns it before they're trusted with good lumber, because lumber is expensive and a bad cut can't be uncut. Your attention is the lumber now. Plan before you prompt.

The double penalty of winging it

Here's what took me embarrassingly long to internalize: a large language model is an extraordinary pattern-completion engine, but it is not a mind reader. GitHub's engineering team said it plainly when they released their spec-driven development toolkit — a vague request forces the model to guess at thousands of requirements you never stated, and some of those guesses will be wrong (h/t the GitHub Blog). The model doesn't know your community's culture, your VP's pet peeves, or that "short" means 400 words in your world. Leave the gap and it fills the gap... with the statistical average of the internet.

And friends, the statistical average of the internet is mediocre. By definition.

When you skip the measuring, you often pay more than twice as much.

The first penalty is quality, and you've felt it: the report that's technically responsive and completely misses the point, the welcome sequence written in a voice that is warm, professional, and absolutely not yours, the code that compiles beautifully against the wrong problem. Now you're in rework. The most expensive kind of work there is, in any craft, in any century.

The second penalty is the one nobody warned us about, and it's more insidious. Every correction, every "no, not like that," every abandoned draft stays in the conversation, and the model keeps drawing on all of it. Researchers now have a name for how output degrades as a context window fills with noise: context rot. Which means your ten rounds of flailing don't converge on your intent. They bury it. And if you're working at the API level or running agents — as more and more community teams are — those wasted cycles are also literal wasted tokens and literal wasted dollars. Poor preparation compounds: in time, in money, in quality, every single time.

And it scales all the way down. A typo, a wrong name, a missing "not" — the butterfly wing that sends the whole response somewhere you never meant it to go, and now you're spending tokens and more time getting back.

George Bernard Shaw wrote that the reasonable man adapts himself to the world, while the unreasonable one persists in trying to adapt the world to himself — and that all progress therefore depends on the unreasonable man. I've carried that line for decades, and it applies here more than anywhere. The reasonable user adapts to whatever the machine hands back. The unreasonable one insists the machine adapt to what they actually need. In my view, the only way to be productively unreasonable is to know, precisely, what you need before you ask.

Begin with the end in mind

Stephen Covey put "begin with the end in mind" second on his list of seven habits, and I'd argue that with AI it moves to first. Measuring twice comes down to two acts of clarity, and the second is the one almost everyone skips.

First, articulate the objective in a single sentence. Not "help me with my metrics deck." Rather: "Produce a one-page summary of Q2 community health for a VP who is skeptical of community's ROI, leading with the churn-reduction data." If you can't write that sentence, you are not ready to prompt — and honestly? That's the gift hiding in plain sight. The blank prompt box just revealed that you haven't decided what you want yet. And here's the part worth sitting with: the machine will decide for you. It has to. Something has to fill that space, and if you don't, the average of the internet will. Half the value of this practice has nothing to do with the machine. It's a mirror. It always was. It is us. Our understanding of the whole situation and our ability to communicate it clearly.

The clearer your objective, the higher the quality of the output.

Second, define your Conditions of Satisfaction. CoS is a concept I'm borrowing from the world of agile. They are the specific, testable criteria the output must meet before you'd call it done. Some of these might include:

• Under 500 words.
• Cites at least one number from the data I provided, and invents none.
• Second person, warm, zero corporate buzzwords.
• Does not mention competitors by name.
• Ends with a single recommended action, not a menu of options.

Three to seven of these is the sweet spot. Notice that the list includes negative constraints as well as the affirmative. What the output must not do. These models are eager to please, and left alone they will add flourishes, hedges, and features you never asked for. Telling the AI what to leave out is every bit as powerful as telling it what to put in. The fence matters as much as the field.

This isn't just my opinion, IMHO elevated to doctrine. Anthropic — the folks who build Claude — open their own prompt engineering guidance by saying that before you optimize anything, you need a clear definition of success and a way to test against it, or you're optimizing blind (Anthropic). When the people who build the model tell you the first step happens before the prompt, believe them.

Then request what you need explicitly: CIDI

You know what you want and how you'll know you got it. Now you have to hand it over without making the model guess — and credit where it's due, someone already solved that part. I've long been a fan of the CIDI structure, which Gianluca Mauro's AI Academy has been teaching since 2023, and it remains the cleanest on-ramp I know for anyone whose prompts are currently one long breathless sentence. Or a series of rambling questions and statements.

Context. Instructions. Details. Input.

It works because it separates four things we habitually mash together: the situation, the task, the shape of the output, and the raw material. Context is everything a capable new colleague would need to know before starting. Who this is for, what's already happened, what's at stake. Not simply a costume you ask the model to wear or a persona you ask it to adopt.

Mash them together and the model has to infer which part of your sentence is the job and which part is the material, and it will infer incorrectly often enough to matter. Label them or at least separate them and it doesn't have to guess at all. That's the whole trick. It isn't magic; it's putting the parts in named boxes so nothing gets read as something it isn't. It also forces a completeness check, which is where most of its value lives. Four boxes means four chances to notice one is empty. Usually the moment you realize you never actually handed over your data, or never said who this is for.

Now notice what's not in those four boxes. There's no slot for how you'll know it's what you were really working to produce.

The confusion usually comes from the Details, because Details and Conditions of Satisfaction feel as if they are the same thing. They aren't. Details describe the output. Conditions of Satisfaction test it. "Warm and concise" is a preference the AI has to interpret. "Under 500 words, cites one number from my data, invents none, ends with a single action"? That is a rubric it can grade itself against. That difference is the whole reason we measured first. Because a beautifully structured request for the wrong thing is still the wrong thing, delivered faster, but often requiring more rework.

The request that changes everything

Which brings the two halves together. Here's where Conditions of Satisfaction stop being a wish list and become something closer to alchemy that turns your intention into the machine's own conscience. Modern AI systems can be instructed to use your criteria as an internal validation pass before delivering anything. One instruction, appended to your prompt:

"Before delivering your response, review it against each Condition of Satisfaction above. If any condition is not met, revise until all are met. Then show me a brief checklist confirming each one."

You've just made the AI its own first editor, graded against your rubric instead of its defaults. In my experience, this single move eliminates most of the "close but not quite" outputs, because the expectation now lives inside the transaction instead of floating in your head where the model can't see it. So go ahead and copy this and keep it somewhere accessible for future use. (We will talk about prompt libraries and related tools in a future post.)

And one more move, thirty seconds of pure return: before the work begins, ask the AI to restate the assignment and ask its clarifying questions. You would do this with a new hire on day one — actually, you'd do it with any collaborator you respected. Do it with the machine. What comes back will humble you, usually by exposing an ambiguity you didn't know you'd left open.

"Do you understand what I am requesting. Restate the request in your own words and ask me clarifying questions where needed."

Put it together and that sequence is the title of this article. Objective and Conditions of Satisfaction are the measuring. CIDI is the cut. And the self-check is the machine holding your marks up against its own work before it commits.

This is not just a coding thing

The software world has already turned this instinct into a discipline. They call it spec-driven development: write a structured specification — goals, constraints, acceptance criteria — before the coding agent writes a line, and treat the spec, not the prompt, as the source of truth. Sean Grove at OpenAI lit the fuse with a 2025 talk arguing that when agents do the building, the written specification is where human intent actually lives (TrueFoundry; see also Addy Osmani's guide). GitHub built Spec Kit around the idea. AWS built Kiro. The tooling converged quickly because the underlying truth is old. Start with the Product Requirements Document (PRD), then the design doc, and then the build. We always knew this. We just forgot it the instant the machine made starting feel free.

But hear me, especially if you've never written a PRD in your life and never intend to: the practice transfers to everything. Drafting an article? Objective, audience, CoS, negative constraints... then the CIDI prompt. Start with the end in mind and then make the request. Building a meeting agenda? Same. A member re-engagement campaign, a moderation policy, an event run-of-show? Same, same, same. Developer Owain Lewis, after a year of working this way, landed exactly where I have: the power isn't in any tool, it's in the practice of thinking before prompting (Owain Lewis). A humble document that forces you to articulate what you want is probably enough. No framework fixes sloppy thinking.

But I digress, because I can hear the objection, and it's a fair one. Chris, doesn't all this planning kill the very speed that makes AI worth using? Two honest answers. One: scale the ceremony to the stakes. A brainstorm, a riff, a throwaway draft — wing it, play, explore. Exploration is where a lot of the joy lives, and I will never tell you to bureaucratize your curiosity. But the moment the output is something you'd be annoyed to redo or you are working on a real deadline — anything shipping to your community, your boss, or your codebase — 'measure' first, think about it for a moment more. Two: the planning is faster than it feels. Five to ten minutes writing Conditions of Satisfaction routinely replaces thirty minutes or more of iterating on drafts that were never going to land the way you wished. That's not a tax on speed. That is the speed. Clarity is not the opposite of momentum; clarity is where momentum originates.

Which brings us back around to where we started, and to the reason this article was published first. Ready, fire, aim is a habit the world trained into us. Measure twice is a habit we have to choose. Nobody is going to impose it on you, and the tools will happily let you skip it forever.

That is your key to differentiation. For yourself and your career, and for your community and the organization hosting it.

The road ahead

Once objective-plus-CoS becomes automatic, something bigger opens up for you, and this is where I get genuinely excited. A well-specified task is a reusable task. Today's careful prompt is tomorrow's skill file, and a library of skill files is the beginning of a genuine agent workflow and the amazing power that AI puts into your hands. An AI that augments your practices and streamlines your workflows instead of interrupting them. That's the bridge from using AI as fancy autocomplete to directing it as a capable collaborator, and it's exactly where our podcast, this community, and the workflow library we're building together is headed.

But it starts here, with the unglamorous foundation. Know what you want. Write down how you'll know you got it. Tell the machine both. Make it check its own work. Then ask it to produce what you need. Iterate from considered clarity instead of shooting from your hip.

Measure twice. Prompt once. Let's get to work.

The Tangible: Your Pre-Flight Checklist

Do this before simply prompting for any AI task that truly matters.

Measure

1. Objective — Can I state what I want in one sentence? (If not, stop. Think about it for a minute or two and decide, or the machine will decide for you.)
2. Audience & use — Who is this for, and what will they do with it?
3. Conditions of Satisfaction — 3 to 7 testable criteria the output must meet.
4. Negative constraints — What must it not do? (Off-limits topics, banned phrases, sections not to touch.)

Cut

5. Write the CIDI prompt
   • Context — What a capable new colleague would need to know before starting. What's already happened, what's at stake, who this is for.
   • Instructions — The task itself, stated plainly. Your objective, in the imperative.
   • Details — Length, structure, tone, medium. Say it explicitly.
   • Input — The actual raw material. Data, examples, voice samples, the document you're working from. Hand it over.

Verify

6. Clarify first — "Do you understand what I am requesting? Restate the request in your own words and ask me clarifying questions where needed."
7. Validation instruction — "Before delivering your response, review it against each Condition of Satisfaction above. If any condition is not met, revise until all are met. Then show me a brief checklist confirming each one."
8. Iteration plan — Decide in advance: how many rounds before you restart a fresh conversation with a better brief? (When the well is polluted, a clean restart beats a tenth correction.)

Copy it, adapt it, make it yours.

One more ask

This site is in preview, and so is the podcast. Episode 0 is up if you want to hear where the show is heading before we formally open the doors and start promoting to more community managers.

I'd rather hear what's wrong with this now than after the invitations go out. So: what's missing from that checklist? What's your version of "measure twice"? How do you prep before you prompt? Tell me, and help the library to improve the way communities always have: together. I am better off when you are better off.

Sources & further reading

• AI Academy (Gianluca Mauro) — The CIDI prompting technique
• Anthropic — Prompt engineering overview: define success criteria first
• Anthropic — Effective context engineering for AI agents
• GitHub — Spec-driven development with AI: an open source toolkit
• Addy Osmani / O'Reilly Radar — How to write a good spec for AI agents
• Owain Lewis — How I code with AI agents (spec-driven development)
• TrueFoundry — Spec-driven development for AI agents (on Sean Grove's "The New Code," 2025)