Anatomy of a good prompt: five building blocks that change the answer

A prompt is the input instruction you give an AI tool: everything you enter into it, from a single question to an entire contract with detailed instructions on what should be done with it. Apart from the sources the tool has access to, this is the only thing it knows about your matter.

This matters because the tool doesn't guess. If you don't tell it whom you represent, what the client intends, and what you want to see in the answer, it will understand the question in the most general way possible, and the answer will be just as general. Not because it's bad, but because a general answer is simply the correct answer to a question framed that way.

A fair amount of mystique has grown up around prompts: lists of "magic phrases," tricks, wordings that supposedly unlock better results. In practice, the truth is less mysterious. When a legal professional hands a contract to a trainee, they don't just say "take a look at this." They say whom they represent, what the client intends, what concerns them, what the trainee should prepare, and in what form. A prompt is exactly the same instruction, just written down.

In this post, we'll look at what such an instruction is made of. First, using a specific contract clause, we'll show what a typical short question produces. Then we'll break down the five building blocks of a useful prompt and ask the same question again, this time applying all five. Finally, we'll identify the three mistakes we see most often.

Throughout, it's the same document and the same tool. The only variable is the question, and that's exactly why the difference in the answer is so instructive.

The example we'll use

Imagine you're a law firm, and your client is a Slovenian company that in 2023 commissioned a corporate visual identity and a website from an external design agency. Today, the company is expanding into foreign markets and intends to transfer the rights to the materials to a subsidiary. The contract with the agency contains the following clause:

"The Contractor transfers to the Client the copyright in all works created under this contract, in full and without limitation, including the moral rights of the author, as well as for all possible future creations and for all forms of use, known or yet unknown. The fee is included in the price set out in Article 3."

The clause is fictional, but it's an example of the kind we encounter regularly in practice. At first glance, it appears exceptionally favorable to the client.

The original prompt, as most people write it

The trainee asks the model: "Is this copyright transfer clause valid?"

The answer isn't wrong. But it's useless, because it doesn't answer the question the client actually has: what, specifically, are we now allowed to do with this material? The tool can't know that, because we haven't told it whom we represent, what the company plans, or what the subject of the commission even was.

So let's look at the five building blocks of a good prompt.

1. Role

Who should answer, and for whom. For the same clause, an analysis for the contractor (the author) is something entirely different from an analysis for the client: the former wants to know what they haven't given up, the latter what they've received. If you don't specify a role, you get a neutral description that helps no one.

In our example: a lawyer advising the client.

2. Context

What the background is, what stage we're at, and what concerns us. In our example, this building block is crucial for a specific reason: the same clause has a different legal outcome depending on what was commissioned. For a computer program created on commission, the law provides a presumption of exclusive and unlimited transfer to the client (Article 112 of ZASP, the Slovenian Copyright and Related Rights Act). For a visual identity, there is no such presumption, so the general rules apply, which are considerably stricter toward the client. If you don't say in the prompt what was commissioned, the tool can't know which regime to apply.

In our example: an external agency, a logo and a website, the subject of the commission is not a computer program, a planned expansion into foreign markets, and a transfer to a subsidiary.

3. Input material

Attach the document; don't describe it. "We have a clause that transfers all rights" and the actual text of the clause are two different things, and the difference between them is usually exactly what will matter in the analysis.

As for how much to attach, a simple rule applies: attach more, not less, and say what part of it interests you. If you have the entire contract, attach it and indicate which provision the question concerns. The other provisions (the definition of the subject of the commission, payment, duration, termination, any licensing terms) can change the assessment of the same clause. And when only an excerpt is available, say so explicitly in the prompt, so the answer doesn't rest on assumptions about what the tool hasn't seen.

In our example: only the text of the clause is available, so we attach it in full and state in the prompt that we're assessing this provision alone.

4. Task

What exactly the tool should do. The most common mistake is that a prompt contains a question rather than a task. "Is it valid?" is a question. "Determine which rights the client actually acquired, flag the void provisions, and propose revised wording" is three tasks with a clear result. If there are several, number them.

In our example: four numbered tasks (see the prompt below).

5. Format

In what form you want the answer. Format isn't cosmetic; it's an instruction about depth. Ask for a table with a "legal basis" column, and you get an answer in which every claim is tied to an article; ask for a "brief assessment," and you get an assessment without a basis. This is also where you ask for sources to be cited.

In our example: a table with columns for provision, finding, and legal basis, followed by proposed wording and a conclusion of no more than five lines.

The revised prompt, built from the five building blocks

Taking all of the above into account, a good prompt would look something like this:

"I am a lawyer advising a client, the commissioning party, under a contract for a commissioned copyright work. The client is a Slovenian company that in 2023 commissioned a corporate visual identity and a website from an external design agency. The subject of the commission is not a computer program. The company is now expanding into foreign markets and intends to transfer the rights to the materials to a subsidiary. I am attaching the text of the rights transfer clause contained in the contract. I am not attaching the full contract, so assess only this provision, and at the end, state what information from the rest of the contract you would need for a more reliable assessment. I need the following:

1. Determine which rights the client actually acquired under this clause.
2. Flag the parts that are void and state the consequence for the rest of the contract.
3. Assess whether the clause is sufficient for using the materials in foreign markets and for transferring the rights to the subsidiary.
4. Propose revised wording for the clause.

Present the answer as a table with the columns provision, finding, and legal basis, followed by the proposed wording and a conclusion of no more than five lines. For each finding, cite the relevant article of ZASP or the relevant judgment."

The findings such a prompt leads to are calibrated entirely differently:

• A transfer of copyright "in full" and a transfer of moral rights are not possible, but only that provision is void, not the entire contract (Articles 69, 70, and 79 of ZASP).
• Also void are the transfer for all future works and the transfer for as-yet-unknown forms of use (Article 79 of ZASP).
• Whatever remains of the clause is interpreted narrowly: unless otherwise specified, a non-exclusive transfer is deemed to have been agreed, valid only for Slovenia and only to the extent essential to the purpose of the contract (Article 75 of ZASP). So there is no basis for foreign markets.
• The client cannot transfer the rights onward to the subsidiary without the author's consent (Article 78 of ZASP).

The same clause that, in the first answer, was valid in principle with some limitations became, in the second, a concrete list of what the client may not do.

The three mistakes we see most often in practice

• Five questions in one prompt. The answer will say two sentences about each. Ask one question at a time, and the rest as follow-up questions in the same conversation.
• "Be precise" instead of an instruction on what precise means. Precision isn't a quality you summon with a word. You achieve it by requiring an article to be cited for every claim.
• A description of the document instead of the document. A summary of the clause that you write yourself already contains your interpretation. And that is often exactly what you want to check.

What does Veru do differently?

The five building blocks apply to every tool. The difference is how many of them you have to repeat with every question.

Work in Veru takes place in structured workspaces for each matter, where the contract, prior correspondence, and findings stay in context. So the "context" and "input material" building blocks don't need to be pasted in again with every question; what remains is role, task, and format. Every claim in the answer comes with a citation to a source that can be opened and read, and the draft of the revised clause is created in a document editor where you also edit the contract.