Diane Okafor, a permits clerk at a mid-size city's building department, typed "write a letter about the inspection" into the agency's approved AI assistant. What came back was a vague, three-paragraph nothing that she spent twenty minutes rewriting by hand. She decided the tool was overhyped. Two desks over, her colleague Raj typed a six-line request into the same tool and got a near-final notice he edited in ninety seconds. Same software. Same morning. The difference was entirely in how they asked.

That gap is what prompt engineering closes. A prompt is simply the instruction you give an AI tool. Prompt engineering is the unglamorous skill of writing that instruction well enough to get useful work back on the first or second try. It is not coding. It is closer to writing a clear assignment for a sharp but very literal new intern, one who knows a great deal but cannot read your mind and will never ask a clarifying question. Treat the AI that way and everything it needs has to go into the prompt, because there is no second conversation where it asks you.

In government the stakes behind that skill are not cosmetic. You are not using AI to entertain yourself; you are using it to support decisions that affect people. If you ask a vague question, get a vague answer, and then lean on that answer to make a government decision, you have made that decision on low-quality input and nobody downstream can tell. Learning to write good prompts is not a luxury. It is foundational to using these tools responsibly at all.

Why Diane's prompt failed

"Write a letter about the inspection" gives the AI almost nothing to work with. It does not know who the letter is for, what the inspection found, whether it passed, what tone the city uses, or how long the letter should be. So the tool does what it always does with thin instructions: it guesses, averages, and produces something generic. Garbage in, generic out. The AI is not failing here. It is faithfully answering the question Diane actually asked, which was a vague one, and the fix is a better request rather than a better tool.

Most people arrive at these tools with search-engine habits. You type a few words, you hope for magic, and when the result disappoints you conclude the technology is oversold. But an AI assistant behaves far more like a capable colleague than like a search box. The more specific you are, the more context you supply, and the clearer you are about what you want back, the better the result. That relationship is reliable enough to build a working method on.

The four habits of a good prompt

Before any framework, four habits do most of the work. Build these into how you think and the frameworks become a formality.

• Be specific. Replace "the inspection" with "the failed electrical inspection at 220 Pine Street on June 18." Specifics steer the output. A good test: could a colleague read your prompt and know exactly what you are asking for?
• Provide context. Tell it who you are, who the reader is, and what they already know. "I am a permits clerk writing to a homeowner who is not a contractor" changes everything about the result.
• Set the format. Ask for a letter, a bulleted list, a table, or a 150-word summary. If you do not name a shape, you get a wall of prose and then do the shaping yourself.
• Iterate. Your first prompt is a draft, not a verdict. The fastest path is a decent first answer plus one follow-up like "shorter, and add the re-inspection fee."

The CRAFT framework: a prompt you can build every time

When you want a reliable structure instead of guessing, use CRAFT. It is five parts you can run down like a checklist. You will not need all five for a quick question, but for any real work product they turn a coin-flip into a dependable result.

• C for Context: the background the AI needs. The situation, the facts, the constraints.
• R for Role: who you want the AI to act as. "Act as a plain-language editor for a city agency."
• A for Action: the specific task. "Draft," "summarize," "list," "compare."
• F for Format: the shape of the output. Letter, table, bullets, word count.
• T for Tone: the voice. Formal, warm, neutral, firm but respectful.

CRAFT applied to Diane's letter

Watch the vague request become a strong one. Each line maps to one letter of the framework.

• Context: "A home electrical inspection at 220 Pine Street failed on June 18 because the panel was not grounded and three outlets had no covers. The homeowner is not a contractor."
• Role: "Act as a plain-language writer for a city building department."
• Action: "Write a notice telling the homeowner what failed, what to fix, and how to schedule a re-inspection."
• Format: "Under 200 words, with a short bulleted list of the specific violations."
• Tone: "Clear and respectful, not alarming."

Stitched together, that is the prompt Raj used. The output needs a quick fact-check and a signature, not a rewrite. The whole prompt took forty seconds to write and saved the twenty minutes Diane lost. Notice how much of the work is just moving information you already had in your head into the request, which is why prompting gets faster rather than slower as you get better at it.

Iterating instead of restarting

Raj's first draft was good but not perfect: it buried the re-inspection deadline in a paragraph. Diane, watching him, expected him to scrap the prompt and start over. He did not. He typed one follow-up: "Good. Move the re-inspection deadline to its own bolded line at the top, and add the $75 re-inspection fee." Ten seconds later he had the final version. That is the rhythm to learn. You are not searching for one magic prompt. You are having a short, steering conversation, where each follow-up nudges the output closer. Good prompts often take two or three rounds of refinement, which is far faster than writing from scratch and far faster than over-engineering the opening line.

Weak and strong, side by side

The quickest way to internalise the difference is to read pairs. In each of these, the first version is not wrong so much as unanswerable, and the second gives the tool enough to work with.

On specificity, "write about benefits programs" produces a survey of nothing in particular. Compare: "explain the eligibility requirements for the SNAP program in plain language suitable for someone with a high school education." The second names the program, the task, the register, and the reader, and those four decisions were going to be made by somebody. Making them yourself is faster than editing them out of a draft afterwards.

On context, "what's the best way to reach homeless people?" invites a generic list. Compare: "We're a city social services agency trying to reach unhoused people in our area to inform them about available services. We have a budget of $50,000. We have staff who speak English and Spanish. What outreach approaches would be most effective?" The budget and the language capability are the constraints that make the advice usable rather than aspirational, and the tool cannot guess either.

On format, "summarize the major challenges in disaster response" returns prose you then have to reshape. Compare: "Create a bullet-point summary (5-7 points) of the major challenges in disaster response for a briefing with the city council. Use plain language. Avoid jargon." You have specified the shape, the length, the audience, and the register in one line, and the output arrives ready to use.

On scope, "what should we do about crime?" gives the tool no idea what level of government you are, what your budget is, what type of crime, or what you have already tried. Compare: "We're a police department in a mid-sized city. We have 100 officers. We're seeing increased property crime in the downtown district over the past 6 months. What evidence-based strategies should we consider?" Asking for evidence-based approaches is itself a quality control, because it steers toward claims that can be checked.

Four techniques worth learning by name

Beyond the framework, four moves come up constantly in government work and each one solves a specific problem.

• The role-play prompt. Tell the AI what role to occupy: "You are a senior budget analyst for a city government. You have 10 years of experience." This calibrates the response to the right level of sophistication and vocabulary, which matters when the alternative is output pitched at a general audience you do not have.
• The example-based prompt. Give it a sample of what you want. "Here's an example of a policy memo I like. Please write a memo in this style about..." Examples carry tone, length, and structure more efficiently than description does, and they are the fastest way to get house style out of your head and into the tool.
• The constraint-based prompt. Name the limits: "Write this for an audience with no background in policy. Avoid technical jargon. Keep to one page." Constraints focus the output by removing the choices you did not want it making.
• The iteration prompt. Feed back on what you got: "Good start. I like the structure but it's too technical. Can you rewrite this for a general audience?" Naming what worked as well as what did not keeps the next version from losing the parts you liked.

The facts you put in are facts it will use

One failure mode belongs to you rather than to the tool. Whatever you assert in a prompt, the AI treats as true. If you tell it your city has a population of two million and you are not actually sure, it will build the entire analysis on that number and present the result with the same confidence it would give a verified figure. Nothing in the output will mark the assumption. You supplied a fact, so it used a fact.

The fix is a single sentence of hedging, written into the prompt. "Our city has approximately 2 million people (I'm not certain of the exact number)." Or, for a background detail you half-remember: "I believe the program was established in 2015, but I'm not certain. Please note this assumption in your analysis." Flagged uncertainty tends to come back marked in the output, which means the person who reads your draft later can see which load-bearing facts still need checking.

This runs in both directions. Facts you supply need to be right, and facts the tool supplies need to be verified. The characteristic failure of these systems is the hallucination, a confident, fluent statement that is simply false, and it does not announce itself. Fact-check the claims, verify any citation, and read the output carefully rather than skimming it for tone. The read-through is not a formality; it is the control.

The five mistakes that produce most bad output

Almost every disappointing result traces back to one of a short list, and each has a direct correction.

1. Asking a vague question. The tool cannot supply the level of government, the budget, the constraint, or the history you left out, so it averages across all of them. Correction: name the situation before you name the task.
2. Providing false or unverified information. An unflagged guess in the prompt becomes a confident premise in the output. Correction: mark what you are unsure of, in the prompt, in plain words.
3. Not specifying the output format. "Write a report" leaves length, structure, and audience to chance. Correction: "Write a 2-3 page report suitable for city council members (non-technical audience), with an executive summary, key findings, and recommendations."
4. Asking the AI to make a high-stakes decision. "Should we approve this permit?" is not an appropriate question to put to a model. Correction: "What factors should we consider when evaluating this permit application?" The tool supplies analysis; the judgment stays with you.
5. Not checking the output. If the model invented a fact or got something wrong, you will not know unless you look. Correction: treat every draft as unverified until you have checked the specific claims that carry weight.

One task, worked all the way through

Take a case with no letter template behind it. You work in a city planning department and you want to use AI to research best practices for improving pedestrian safety downtown. The weak version writes itself: "What's the best way to make pedestrians safe?" That is unanswerable, because the tool has no idea what your city is like, what you can spend, how long you have, or who will read the answer. It will return the generic list that any search would have produced.

The strong version carries the situation with it. "I work for the city planning department in a medium-sized U.S. city (population 300,000). We're trying to improve pedestrian safety in our downtown business district. We have moderate funding and can implement changes over 12-18 months. What evidence-based approaches have worked in similar cities? Please format as a bullet list with brief explanations. Assume the reader has no background in urban planning."

Read what that prompt is doing. It provides context in the city size, the funding position, and the timeline. It specifies the format as a bullet list with brief explanations. It sets the audience as a non-technical reader. And it asks for evidence-based approaches, which is a credibility constraint rather than a stylistic one, because it pushes the tool toward claims you can go and verify. Four decisions, one paragraph, and the difference between a result you can take to a meeting and one you cannot.

Two rules that are non-negotiable in government work

Prompting well in a public agency carries two duties a private-sector user does not face as sharply, and both of them sit inside the prompt itself rather than around it.

First, never put protected data in the prompt. Notice that Diane's strong prompt named a street address but no person's name, Social Security number, or other personal identifier. Build prompts that get the job done with the least sensitive information possible, and use placeholders like [HOMEOWNER NAME] where a name would otherwise go. The habit matters most on the days you are rushing, which is exactly when the identifier gets pasted in.

Second, you own the output, not the AI. The model can be confidently wrong. It can invent a fee, a code section, or a deadline that does not exist. Every fact in an AI draft that goes out under your agency's name must be verified by you before it leaves your desk. This is also why the fourth mistake above is the most serious one: a tool that informs your judgment leaves you accountable and equipped, while a tool that substitutes for your judgment leaves you accountable and empty-handed.

Your reusable prompt checklist

Keep this where you can see it. Run it before you send a prompt for any real work product. The first two items are gates rather than suggestions, meaning a "no" on either stops the task rather than adjusting it, and the last item is the one people skip when the output looks good. None of it takes long once the habit is formed, and the checklist mostly earns its keep on the days you are busy enough to want to skip it.

1. Approved tool? Am I in a tool my agency has cleared for this kind of work?
2. No protected data? Have I stripped names and identifiers, using placeholders instead?
3. Context given? Does the prompt include the facts, the situation, and the reader?
4. Facts flagged? Have I marked anything I am supplying that I am not certain of?
5. Role and action clear? Have I told the AI who to be and exactly what to do?
6. Format and tone set? Did I name the shape, length, and voice I want?
7. Judgment kept? Am I asking for analysis rather than asking it to decide?
8. Ready to verify and edit? Am I treating the result as a draft I will fact-check and sign?

Anti-Patterns

These are the habits that survive even after people learn the framework, and each one has a specific risk attached.

• Treating the AI as an oracle. You ask a question and accept the answer as true without verification. The risk is direct: the model may be wrong or may have invented the supporting facts, and you have now carried that into a decision that affects someone. The fluency of the answer is not evidence about its accuracy.
• Copying output straight into a document. The draft goes into the file verbatim, unread and unedited. The risk is that it does not fit your context, contains errors nobody caught, and now carries your name on work you have not actually reviewed.
• Using AI to make high-stakes decisions. Asking "should we deny this person's benefits?" and treating the answer as the basis for the decision. The model is a tool, not a decision-maker, and for consequential determinations it should inform human judgment rather than replace it.
• Not providing context and blaming the tool. A vague question produces generic, low-value output, and the conclusion drawn is that the technology does not work. The risk is quiet: capable people stop using something useful because of a habit they could fix in one line.
• Pasting identifiers because it is faster. Real names and numbers go into the prompt because a placeholder felt like friction. The risk is that sensitive data leaves your control in a way you cannot retract, and speed is never the justification that holds up afterwards.
• Over-engineering the first prompt. Long minutes spent perfecting an opening request that a single steering follow-up would have corrected in moments. Iteration is the cheaper path, and treating the first prompt as final is the mirror image of treating the first output as final.

Practice Prompts

Do these in the approved tool at your desk, on work you actually have. Reading about prompting does not transfer; writing prompts does.

• Write the pair. Write a weak, vague prompt asking an AI tool for something you genuinely need. Then write a better version applying CRAFT. Then write down your reasoning for why the second is better. The third step is the one that makes the lesson stick.
• Build a real one with CRAFT. Take a task from your own queue and write a prompt with all five parts present. Check it against the framework: is it clear, does it carry the context, are the facts you supplied accurate, is the format named, and have you planned to test the result?
• Rescue a bad session. Think about the last time you asked an AI system something and got a poor answer. Rewrite that prompt now with the four habits applied, run it, and compare.
• Practise the follow-up. Take an output that is close but not right and fix it with a single steering instruction rather than a new prompt. Name what worked before you name what did not.
• Reframe a decision question. Identify a high-stakes decision in your work that you might be tempted to hand to a model. Rewrite it so the AI informs your judgment instead: from "should we" to "what factors should we consider."
• Try the four techniques. On one task, run the same request four ways: with a role, with an example, with explicit constraints, and with an iteration follow-up. Note which changed the output most for your kind of work.

Reflection

Think about how you have been talking to these tools. When an answer disappointed you, did you rewrite the prompt or did you conclude the technology was not ready? Most people do the second, and it is worth noticing because the conclusion feels like a judgment about the tool when it is usually a judgment about the instruction. Now consider the opposite failure. When an answer came back polished and confident, how carefully did you actually check it? Fluent output invites less scrutiny than clumsy output, which is exactly backwards, because the polished draft is the one that travels furthest before anyone questions it. Finally, ask what you would be comfortable having attached to your name if a member of the public requested it. Everything you send under the agency's name is your work regardless of what drafted it, and prompting well is partly about making that ownership easy to carry rather than uncomfortable.

Glossary

• Prompt: A question or instruction given to an AI system, which is the whole of what the tool knows about your intent.
• Prompt engineering: The practice of crafting prompts to get better output from AI systems, learnable as a skill rather than an aptitude.
• CRAFT: The five-part prompt structure used in this lesson: Context, Role, Action, Format, and Tone.
• Context: Background information that helps the AI understand your situation, including the facts, the constraints, and who the output is for.
• Role: The persona you assign the tool so that it calibrates vocabulary and depth to the right audience.
• Format: The shape you specify for the output, covering structure, length, and register.
• Iteration: Refining a prompt or steering an output based on what you received, usually over a small number of rounds rather than one attempt.
• Hallucination: When an AI system generates false information with confidence, which is the failure mode that makes verification mandatory rather than optional.
• Placeholder: A bracketed stand-in such as [NAME] used in place of a real identifier so that a prompt can describe a case without exposing the person in it.

Related Lessons

This lesson gets you to a usable draft; the ones around it govern what happens on either side. Your Agency's Approved AI Tools settles the question the first checklist item asks, which is whether you should be in this tool for this work at all. Evaluating AI Outputs and Systematic AI Output Validation take up the verification duty that the second government rule imposes, and they are where the fact-checking habit becomes a method. For harder tasks, Prompt Engineering Mastery: Structured Prompts and Prompt Engineering Mastery: Chain-of-Thought and Few-Shot extend the techniques here, and AI for Government Tasks: Summarization and Drafting applies them to the work most agencies do most often. On the data rule, PII and AI: The Bright Red Lines is the lesson that defines what must never enter a prompt.

Closing

Diane and Raj were never separated by talent or by software. They were separated by the amount of thinking that happened before the Enter key, and that is a gap anyone can close in an afternoon. Start with one task you repeat every week. Write the prompt out properly, with the context, the role, the action, the format, and the tone, then save it somewhere you can find it. The second time you need it you will edit rather than compose, and after a few runs you will have a small library of prompts that produce your agency's voice on demand. That library, not any individual clever request, is what changes how much these tools are actually worth to your office.

Key Takeaways

• The instruction is the lever. The same tool produces useless or excellent output depending entirely on how clearly you ask. Prompting is a learnable skill, not a personality trait.
• Treat the AI like a literal intern. It is fast and knowledgeable but cannot read your mind and will never ask a clarifying question, so everything it needs goes into the prompt.
• Four habits carry most of the load. Be specific, provide context, set the format, and iterate with quick follow-ups instead of chasing one perfect prompt.
• CRAFT gives you a repeatable structure. Context, Role, Action, Format, and Tone turn a coin-flip into a dependable result for any real work product.
• Iteration beats perfection. A decent first answer plus a targeted follow-up is faster than agonizing over the opening prompt, and two or three rounds is a normal path to a usable result.
• Your facts become its facts. Anything you assert in a prompt is treated as true, so flag what you are unsure of in the prompt itself and let the uncertainty show up in the output.
• Name the technique to the problem. A role calibrates the level, an example carries the style, constraints remove unwanted choices, and a follow-up steers without restarting.
• Protect data inside the prompt. Use the least sensitive information possible and replace real identifiers with placeholders like [NAME].
• Ask for analysis, not for the decision. Reframe "should we" as "what factors should we consider" so the tool informs judgment that stays with a person.
• You own every word that ships. AI can be confidently wrong, so verify all facts and figures in a draft before it leaves your desk under the agency's name.

Frequently Asked Questions

How long should a prompt be? Long enough to remove the guesses, and no longer. A quick question needs a sentence; a work product that goes to the public usually needs the five parts of CRAFT, which is a handful of lines. The useful test is not length but whether a colleague reading your prompt could produce roughly the output you wanted. If they could not, the tool cannot either.

What if the first output is close but wrong in one place? Steer it rather than starting over. One instruction naming what to keep and what to change is nearly always faster than rewriting the prompt, because you lose the parts that already worked when you restart. Say what you liked, say what to change, and send it back.

Can I put a citizen's name in the prompt if the tool is agency-approved? Approval of a tool is a separate question from what data belongs in it, and this lesson's rule is to use the least sensitive information the task allows. Use a placeholder such as [HOMEOWNER NAME] and check your agency's data handling rules for the specific category involved. Where the rules are unclear, treat that as a reason to ask rather than a reason to proceed.

Is asking the AI to act as an expert the same as getting expert advice? No. A role prompt changes the vocabulary, depth, and framing of the response, which is genuinely useful for pitching output at the right audience. It does not give the model credentials, access to your jurisdiction's rules, or accountability for being wrong. The role is a formatting instruction with a costume on.

How do I know when the output is good enough to use? When you have checked the claims that carry weight, not when it reads well. Fluency and accuracy are independent in these systems, so the review that matters is the specific one: is this fee real, does this code section exist, is this deadline the one in our process? A draft that survives that check is a draft you can sign.

Should I keep prompts that worked? Yes, and this is the single highest-return habit in the lesson. Most government writing is repetitive, so a saved prompt for a recurring notice turns a forty-second composition into a quick edit, and it spreads good practice when you share it with a colleague. Store them where your team can find them rather than in your own notes.