Prompting for a Checkable Answer in Legal Work

Prompting for legal work is not about getting a good answer. It is about getting an answer whose defects are visible. A confident, plausible memo with one unverifiable proposition in it is worse than a scruffier one that says which proposition it could not check. The goal is a draft whose claims are traceable, so a qualified person can review it fast.

It would be tidy if skills made prompting obsolete. They do the opposite. A skill is a prompt with a filename, so every weakness in it now runs on every matter. The practices that get real value are the ones whose lawyers can tell, quickly, why an output is not good enough and what would fix it. That is the discipline that makes captured skills worth capturing in the first place.

Three failures, and where they come from

Most bad legal AI output falls into one of three shapes, and none is fixed by a better model:

Vague. The output is generic because the request was. The model filled the gaps with the average of everything it has seen.
Confident. The output asserts something it cannot support, because nothing in the request made uncertainty an acceptable answer.
Inconsistent. The output differs run to run, because the request left the order and format to chance.

Before you send a prompt, apply the one-line test: could a competent colleague act on this brief without asking you anything? If not, the missing thing is what the model will invent.

Six moves, ranked by value per minute

Say what you actually want. "Review this contract" gets you a review of something. Give the purpose, the audience and the deadline. An agreement going to a counterparty on Friday and one sanity-checked before an internal call deserve genuinely different reviews. If you only do one thing, do this: it is the cheapest to type and it changes the answer most.
Show one example. One example of the output you want is worth several paragraphs describing it, and it is the fastest way to transfer a house convention. Paste the paragraphs of last month's advice note you were happiest with: this tone, this hedging, this structure.
Ask for the working. For anything with analysis in it, ask the model to work through the reasoning before the answer. "Work through each limb of the test in turn, then state whether it is met" beats asking whether it is met, and gives something checkable.
Structure the input. When a request contains several things, label them. XML-style tags such as playbook, agreement and question remove the ambiguity about which part is instruction and which is material.
Set the role and the standard. Telling the model who it is shifts what it attends to. A privacy specialist reading a DPA notices different things from a general commercial reviewer.
Chain, do not cram. A prompt that asks for extraction, analysis, judgement and a drafted email in one pass will do all four adequately and none well. Split it. This is also how you find where a workflow needs a human gate.

Where prompts actually live

Most people think there is one prompt. There are four, with different lifetimes. The system prompt holds role and standing constraints for the whole session, and is where every installed skill's description is injected. The user turn holds the task and material you type. The assistant prefill supplies the first characters of the reply, forcing a format open. And descriptions on tools, skills and commands are prompts nobody types but that decide what the model reaches for.

The distinction is not academic. A constraint typed into a user turn applies to that turn, and three turns later it has scrolled into history. "Always cite the tab and cell" typed once is a request. The same sentence in SKILL.md is a property of the process. This is why skills exist: a skill is a system-prompt-level instruction that loads itself when relevant.

Rewrite for verifiability

Consider a contract review. "Any problems with this agreement?" produces a general impression. The better version uses your positions in a playbook, reviews clause by clause, and for each departure quotes the clause, states your position and the fallback, and says whether it needs escalation. The instruction people leave out and the one that matters most: if a term the playbook covers is absent, say so. A missing term is itself a finding.

The pattern worth stealing runs through every good rewrite: a sentence that gives the model explicit permission to fail. Say so and stop. List it as unexplained. Do not characterise anything as market or off-market without a named baseline. Without that permission, the path of least resistance is a complete-looking answer. You have to make the incomplete answer acceptable, in writing.

With long material, position and labelling change the answer more than wording does. Put long documents near the top and the question at the end, wrap each in a tag with an identifier, and ask for citations against it. "LPA clause 8.3 against side-letter paragraph 4" is a citation you can open and check in ten seconds. "As per the agreement" is not.

Make the defects visible

The output you want is not the most confident one. It is the one whose weak points are labelled. Add three short sections to almost any analytical prompt, and in a skill they become part of the output template:

SOURCES: every proposition and where it came from.
UNSUPPORTED: anything you stated that the material does not evidence.
NOT CHECKED: anything you could not verify, and why.

A silent skip is indistinguishable from a pass, which is exactly the failure mode you cannot afford.

Untrusted content, and knowing whether it worked

Anything arriving from outside your firm is untrusted input: a counterparty's mark-up, an opponent's disclosure, a vendor's terms. If that file contains text addressed to the model rather than to you, the model may follow it. There are three layers of defence, not equally strong. Telling the model to treat the material as data reduces the rate. Separating the reader, so one agent parses the document and a second acts only on the structured fields it returns, is better. Removing the capability, so the reading agent holds no tool that could act on an instruction, is the real one. Design as though the prompt defence will eventually fail, because it will. That capability boundary is designed at the connections layer.

To know whether a change helped, keep twenty real examples with known-good answers, including the awkward ones everybody remembers, and run them before and after every material change. Score the properties you actually need: did every figure tie, was every claim sourced, did it refuse where it lacked support, did it flag what it could not check. Correct refusal is worth scoring explicitly, because a prompt that gets more assertive on hard cases is getting worse.

Prompting is how you find out what your process actually is. Everything after is engineering, packaged as plugins and agents. For the whole argument, read the AI guide for legal practice.

Ready to go further? Download the five-part legal series, or send us a workflow and we will tell you whether it is worth building.