My Top 10 Prompts I Use Every Week as a Legal-Tech Builder

These are not made-up examples written to look tidy in a listicle. This is close to my actual rotation in a normal week of building legal systems and running my own practice. I have generalized the specific client and matter details out of each one, but the structure is exactly what I type.

1. The rough-spec cleanup

"Here are my rough notes on a matter type's action sequence. Turn this into a numbered, ordered list of discrete actions, each with a plain description. Do not add steps I have not described, and flag anywhere the sequence seems to have a gap."

I use this constantly at the start of a build, converting the paper-first step into something structured enough to actually design against.

2. The plain-language translation

"Explain the following technical structure to a client with no technical background, in plain language, without oversimplifying the parts that actually matter to them."

Used every time a build wraps and I need to explain what was actually built, in a form the client can act on rather than admire.

3. The bounded document summary

"Using only the attached document, summarize the key obligations, dates and parties. Do not reference anything outside this document."

The bounded-pool pattern, applied to a first pass on a long document before I read it in full myself.

4. The gap finder

"Review the following process description for missing exception paths, what happens if a document is late, a client goes unresponsive, or a deadline moves. List only the gaps, not a rewrite."

Because writing the exception path before the happy path is one of the lessons I keep relearning, and this is how I check my own work against it.

5. The counterargument check

"Argue the strongest case against the conclusion above, using only the same source material provided."

Used on anything that matters enough to be wrong about expensively.

6. The drift check on my own copy

"Review this copy for generic language that could apply to any company, and flag every instance where a specific, verifiable detail could replace a vague claim."

Run against site copy, product descriptions, and this exact essay before it published.

7. The field-list extraction

"From the following unstructured notes, extract a clean list of data fields, with type and whether it should be required, for a database of this kind."

The direct bridge from paper spec to an actual Notion or database schema.

8. The client-update draft

"Draft a status update to a client, in a direct, professional tone, covering what has happened since the last update, what is currently in progress, and what is next. Do not speculate on timing beyond what is stated below."

Exactly the client update agent pattern, just run manually when I am not inside a matter-wired system.

9. The no-source-found stress test

"Answer the following question using only the attached materials. If the materials do not support a confident answer, say so explicitly rather than inferring from general knowledge."

Run deliberately, on purpose, against a question I already suspect the material does not fully answer, to check whether the honest "not supported" response actually comes back or whether the model reaches for something plausible instead.

10. The second-pass review, never the first

"Review the draft above specifically for unsupported claims, missing citations and internal inconsistencies. Do not comment on tone or style."

Always run as a second, separate prompt after drafting, never combined with the drafting instruction itself, because asking for both at once weakens both.

The pattern underneath the list

Notice that none of these ten are exotic. They are the same handful of structural moves, bound the input, force the citation, allow "not supported," separate drafting from review, applied to whatever specific task is in front of me that day. A prompt list is only useful if the patterns underneath it transfer to the next task you have not written a prompt for yet. That is the actual test, and it is the one most prompt listicles do not survive. The full scaffolded versions of these, built specifically for legal drafting and review rather than general use, are in the AI-Native Practice Field Guide.