TL;DR
V1 Instruct is the fifth and final step of the V1 Framework. It is the prompt, treated as a specification rather than a wish. A clean V1 prompt states the problem, the constraints, and the acceptance criteria, then renders them into instructions the model can act on. If the first four steps are clean, the prompt is short and obvious. If the prompt is long and clever, the upstream V1 work was probably skipped.
- The prompt is the last 10% of building with AI.
- A specification can be checked; a wish cannot.
- A clean V1 prompt carries problem, constraints, and acceptance criteria.
- Long, clever prompts usually mask missing upstream thinking.
In this article
Why the prompt is the last 10%
I shipped my first production prompt at CreativeOS, then another, then a hundred more. The pattern across all of them is the same. The prompts that work are short. The prompts that fail are long. The variable is not the prompt itself. It is the thinking upstream of the prompt.
That is why Instruct is Step 5, not Step 1. The prompt is the surface of the upstream V1 work: Strip, Decompose, Constrain, Define Done. When those four steps are done well, the prompt almost writes itself. When they are skipped, no amount of prompt engineering recovers the workflow.
The 90/10 ratio is not poetic. It is operational. 90% of the value comes from the thinking. 10% comes from rendering the thinking into instructions. Teams that reverse the ratio spend three weeks tuning a prompt that needed thirty minutes of decomposition.
Prompt as specification, not wish
The difference between a wish and a specification is whether the result can be checked. A wish describes what you want. A specification describes what passes.
A wish: "Write a friendly customer service response to this refund request."
A specification: "Draft a response to the refund request below. Address the customer by name. Acknowledge the specific issue in their words. Propose one next step (issue refund, ask one clarifying question, escalate). Do not commit to any amount or timeline beyond company policy. Stay under 120 words. Second-person tone, no exclamation points, no apologies that admit company fault."
The first version produces a plausible response that someone has to evaluate from scratch. The second version produces a response that can be checked against seven concrete criteria. If you wrote Step 4 well, you already have those criteria. The prompt is the act of putting them in front of the model.
A specification is also versionable. When the workflow changes (new policy, new tone guideline, new product), you do not rewrite the prompt from scratch. You update the criterion that changed. The other six stay put. The prompt evolves the way a spec evolves: incrementally, with provenance, with a record.
A wish describes what you want. A specification describes what passes. Only the second one is useful to a model.
What a clean V1 prompt looks like
A clean V1 prompt has three sections. The labels are not important; the structure is.
1. The problem
One or two sentences that state the actual job to be done, as it came out of the Strip step. Not the workflow. The job. "Draft the first version of a customer service response to a refund request, suitable for human review and send."
2. The constraints
The boundaries from Step 3. What the model can decide, what it must escalate, what inputs are valid, what outputs are valid, what the failure mode is. These are non-negotiable. They are why the model exists in the system.
3. The acceptance criteria
The list from Step 4. What done looks like. The specific, measurable, agreed, written criteria the output will be checked against. This is the part most prompts leave out, and it is the part that makes the difference between consistent and inconsistent output.
Optional fourth section: example outputs. Two or three labeled examples, anchored to the criteria. These are most useful when the criteria include qualitative dimensions (tone, voice, style) that benefit from being shown rather than only described.
That is the whole shape. Problem, constraints, criteria, optional examples. The art is in the upstream thinking, not in the prompt structure.
Rendering the first four V1 steps into a prompt
The render is mechanical when the first four steps are done. Walk through each artifact and translate it into the prompt.
- From Strip: Take the stripped problem statement and put it at the top. One or two sentences. No process description, no historical context, no how-we-used-to-do-it. Just the job.
- From Decompose: If the task is composite, state which sub-task this prompt is responsible for. Decomposed workflows usually mean multiple prompts, each responsible for one sub-task. Do not try to make one prompt do the work of three.
- From Constrain: Translate the constraints into explicit rules. "Do not X. Always Y. If unclear, escalate." The constraints are the safety rail. They are also the spec for what the model is not responsible for.
- From Define Done: Drop the acceptance criteria in directly. The same list that gates the launch and seeds the eval set is the list the model sees. Same words. Same thresholds.
When the render is done, read the prompt back. If it is long and clever, go check whether the upstream thinking was actually clean. Most of the time, the cleverness is masking a Step 3 or Step 4 gap. Fix the gap, then re-render. The prompt gets shorter and the output gets more reliable.
Prompt failures that are actually upstream V1 failures
The output looks wrong. Before you tune the prompt, check whether the failure is actually a prompt failure.
"The model keeps doing X when I told it not to." Almost always a constraint problem (Step 3). The constraint was either missing or stated as a preference rather than a rule. Make it a rule. State it once, clearly, at the top of the constraints section.
"The output is plausible but always misses what we actually wanted." Almost always a Define Done problem (Step 4). The model is producing something that looks reasonable to it but does not pass the team's private rubric. Write the rubric down. Put it in the prompt.
"The model is doing too many things at once and they all come out half-baked." Almost always a Decompose problem (Step 2). The prompt is asking for a multi-step output in one shot. Split it. Three prompts that each do one thing beat one prompt that does three.
"The model is hallucinating context that does not exist." Almost always a Strip problem (Step 1). The prompt is describing the old workflow instead of the actual job, and the model is filling in assumptions to make the workflow make sense. Strip again. Remove the process language. Leave only the job.
If none of those is the issue, then the prompt itself is the issue. That is the actual 10%. Tune wording, reorder sections, add an example. The tuning is real work; it is just rare. Most teams tune the prompt when they should be redoing Step 3 or Step 4.
Prompting vs asking
There is a difference between prompting and asking, and it is the difference between V1 and chat.
Asking is conversational. You type a question, the model answers, you refine, you ask again. That is how most people experience LLMs day to day. It is also a fine way to use AI for personal work, exploration, or one-off tasks.
Prompting is operational. The prompt is a piece of infrastructure that will run hundreds or thousands of times against a workflow. The output goes into a pipeline, a tool, a customer experience. You will not be in the loop to refine. The prompt either produces consistent output or it does not.
V1 is for prompting, not asking. The five steps are overkill for a one-off conversation, and they are exactly the right discipline for a production workflow. If you are building something that runs more than ten times, treat the prompt as a specification, not a chat turn.
For the methodology overview, see The V1 Framework: An Introduction to Building with AI. For Step 4, the step immediately before Instruct, see V1 Step 4: Define Done. For how this work fits into a broader transformation, see The AI Transformation Playbook for Consumer Brands and the tactical companion, Prompt Engineering for Marketing Operations.
Prompting is operational. Asking is conversational. V1 is the discipline that turns the first into reliable infrastructure.
The bottom line
V1 Step 5 is Instruct, the prompt that renders the upstream V1 work into instructions the model can act on. The prompt is a specification, not a wish. A clean V1 prompt carries the problem, the constraints, and the acceptance criteria. It is the last 10% of the work.
If your prompt is short and your output is reliable, the upstream V1 work was clean. If your prompt is long and your output is inconsistent, the V1 work was skipped somewhere. Go find the gap, fix it, and re-render. The model is doing what you asked. Asking better is the entire game.
FAQ
What is V1 Step 5?
V1 Step 5 is Instruct, the step where you write the prompt that delivers the upstream V1 thinking to the model. It is the last 10% of the work, not the first. If the previous four steps are clean, the prompt is short, obvious, and easy to maintain.
How is Instruct different from prompt engineering?
Prompt engineering is a tactic. Instruct is a step inside a methodology. Instruct is the act of rendering the prior V1 work (problem, constraints, acceptance criteria) into a prompt. Pure prompt engineering optimizes the prompt in isolation; Instruct treats the prompt as the surface of the upstream thinking.
What makes a prompt a specification?
A prompt is a specification when it states the problem, the constraints, and the acceptance criteria in a form the model can act on. A wish describes what you want. A specification describes what passes. The difference is whether the prompt can be checked against the output.
How long should a V1 prompt be?
A clean V1 prompt is as short as the thinking allows and no shorter. If the prompt is long because the thinking is missing, it is bloated. If the prompt is long because the workflow is complex, it is correct. The right length is set by the upstream V1 work, not by personal preference.
Should I use chain-of-thought prompting?
Use chain-of-thought when the task benefits from reasoning the model can show, and skip it when the task is judgment-light or latency-sensitive. Chain-of-thought is a tactic inside Instruct, not a substitute for upstream V1 work. It will not fix a vague specification.
Why is the prompt the last step in V1?
The prompt is the last step because it is the rendering of the upstream thinking into model-readable form. If you write the prompt first, you are guessing at the constraints and the acceptance criteria. If you write it last, you are translating decisions you have already made.