Why the word feels harder than it is
There is no magic arrangement of words that flips a hidden switch, nobody is holding out on the incantation, and typing a clear ask is not a technical skill. It takes the same judgment as briefing a new project engineer: say what the job is, say what it has to cover, and say how you will know it is right.
That is why "prompt engineering" deserves less reverence than it gets: it is scope writing with a keyboard, and the people who look fluent are simply being specific about work, which is a management skill you have practiced for years in rooms full of people who bill for every gap you leave.
A prompt is only the ask itself, and each message you type is a fresh one; everything else the tool can see, including the documents you pasted and the earlier turns of the conversation, is its context. And revising an ask is normal practice, not failure. No estimator prices a job off the first sentence of a scope, and nobody writes a complete ask on the first pass either.
The closest thing to a prompt in this business is the subcontractor scope letter. When a sub sends a number, the number is not the deal. The inclusions, the exclusions, and the assumptions are the deal, and everyone in purchasing knows the buyout is decided in that letter well before anyone argues about price. A thin scope letter is not dishonest, only quiet, and quiet gets filled in with whatever is standard for the trade. A prompt behaves the same way: whatever you leave out, the tool supplies from the most ordinary version of the work.
What a scoped ask changes
EXAMPLE: A division president pastes three flooring subcontractor proposals into the chat window and types, "summarize these bids." Back comes a tidy table of numbers and durations that answers nothing, because nobody told it what mattered. His second prompt reads like a scope letter: compare all three against these six line items, flag anything a bidder excluded or assumed, and tell me where the low number is carrying the thinnest scope. Same three documents, same tool, a different ask, and the second version addresses the buyout question the first one stepped around.
Nothing in that second attempt required knowing anything about the tool. It required knowing what decides a flooring buyout, and nobody can supply that for him.
Somebody will tell you the tool is not very good. Ask what they typed, in the same tone you would use if a sub's number came in wrong and you wanted to read the scope letter before blaming the estimator. Almost always, the ask named a subject rather than a job. Disappointing output usually traces back to a prompt that left the deciding requirement unstated. Most changes on projects start the same way: the requirement lived in somebody's head and never made it onto paper. Both failures are cheap to fix early and expensive to fix late, which is the whole argument behind early identification.
A prompt is a scope of work that happens to be typed rather than spoken, handed to a counterparty with no way to phone you and ask what you meant. Write it the way you would write it for a sub you have never worked with before, and most of the mystery goes away.
This definition is part of D. Brown Management's AI Literacy Series, written for the leaders of construction contractors. All relationships begin with a conversation.
