AI Fluency.

The framework

1. 01

   Write the acceptance criteria before you write the ask.

   Finish this sentence before you type a request: I will accept this if it does the following. Make each criterion concrete enough that a stranger could apply it without you in the room — answers these four objections, cites only the documents attached, fits on one page, contains no number I haven't supplied. Most people write their criteria after the third disappointing answer, in the form of corrections, which is the same information arriving at the expensive end of the curve. Written first it costs you a minute. Written as corrections it costs the afternoon.

2. 02

   Two halves: what good looks like, and what wrong looks like.

   The format half says what the output should be — a table with these columns, six bullets, four hundred words — and it is the half that gets written. The failure conditions say what a wrong answer would look like, and they carry more weight: say so rather than guessing if the sources do not cover it, do not invent a citation, flag anything you inferred rather than found. Leave them out and you get a polished answer that satisfies the format while hiding the gaps, and the gaps are precisely the part you'll be held to.

3. 03

   Catch the ambiguity while it's still one sentence long.

   Read your specification back hunting for words two reasonable people would take differently: brief, senior, recent, competitors, key risks. Each one is a decision you've handed over by default, and the model will make it silently and consistently across the whole output. Resolve them in the specification rather than in review, because by review the ambiguity has been built on: three sections written to the wrong reading of recent, and now you have to unpick which parts depend on it. Boehm's curve is the same curve here, only compressed into an afternoon rather than a decade.

4. 04

   A team that shares specifications beats a team of clever prompters.

   When the work finally comes back right, the durable asset isn't the transcript. It's the specification that produced it, which is why the ones worth writing belong somewhere your team can reach: one file per recurring output, holding the criteria, the format, the failure conditions and the two examples that settled the arguments. The prompt swapped around in the group chat is a souvenir of one good afternoon. The file is the thing that gets better every time somebody uses it, because the improvement accumulates in a document instead of in somebody's habits, and documents survive people leaving.