Executives (CEO, COO, CTO)

Deciding what to buy, what to build and what to avoid — usually from incomplete information and under time pressure.

What the work looks like

Turn a long document into a decision, with the trade-off stated
Compare vendors on the criteria that actually bind you
Stress-test a plan by asking what would have to be true
Draft a board-ready summary that survives hostile questions
Understand a technical risk well enough to govern it

Leans on

Reasoning & general intelligence 28 Deep research & browsing 3 Long context 4 Enterprise platform & governance 17

Prompt patterns

Decision, not summary

Here is {doc}. I have to decide {decision} by {date}.

Give me: the recommendation in one sentence; the three facts it rests on; the strongest argument against it; and what would have to be true for the opposite choice to be right.

Asking for the counter-argument in the same breath stops the model agreeing with the framing of the question, which is the failure mode that matters when the question came from you.

Stress-test a plan

This is our plan: {plan}.

Do not critique it. Instead, assume it has failed twelve months from now. Write the three most likely post-mortems, each in a paragraph, ordered by probability rather than severity.

A pre-mortem gets specific failures where “what are the risks” gets a list of abstractions. Ordering by probability stops the exciting risk crowding out the likely one.

Vendor comparison on your criteria

Compare {thing} against {alternatives} on exactly these criteria: {criteria}. One row per criterion. Where you cannot find a sourced answer, write “unknown” — do not infer it. End with the single criterion on which they differ most.

Naming the criteria first stops the comparison drifting to whatever is easiest to find, and licensing “unknown” is what stops a plausible guess entering a board paper.

The long document, read properly

Attached is {doc} ({length}). Read all of it.

1. What is this document for, in one line?
2. What does it commit us to?
3. What does it deliberately not say?
4. Quote the three passages I would regret not having read.

Question 3 is the one that earns the long context window — omissions are invisible to a summary and are usually where the risk is.

Software engineers

Shipping and maintaining software: writing it, fixing it, reviewing it, and understanding code nobody remembers.

What the work looks like

Explain an unfamiliar codebase before changing it
Write the failing test first, then the fix
Review a diff for the bug the author could not see
Migrate an API across a repository consistently
Turn a stack trace into a root cause

Leans on

Code & software engineering 16 Agentic & computer use 21 Long context 4 Reasoning & general intelligence 28

Prompt patterns

Understand before changing

Explain how {area} works in this repository. Trace one real request end to end, naming the files in order. Then tell me the three things about this code that would surprise someone reading it for the first time.

The surprises are the tacit knowledge that is not in the README and is exactly what breaks a first change.

Failing test first

This bug: {bug}. Do not fix it yet.

First write a failing test that reproduces it, and show me the test failing. Then fix it, and show the same test passing. Do not change any other test.

Making the reproduction the first deliverable is what stops a confident fix for a bug that was never demonstrated.

Review for what the author could not see

Review this diff. Ignore style. For each problem give: the failure scenario as concrete inputs and the wrong output, and the line. If you find nothing, say so rather than manufacturing a nit.

“If you find nothing, say so” is load-bearing — a reviewer that must find something will find something, and it will not be the bug.

Repository-wide migration

Migrate every call of {old_api} to {new_api} across this repository.

Work file by file. After each file, run {test_command} and stop if it fails. Do not change behaviour. When you are done, list every file you touched and every one you deliberately skipped, with the reason.

The stop condition and the skipped-file list are what turn an agent run into something reviewable instead of a diff you have to read entirely.

Stack trace to root cause

Here is a stack trace and the three files it names: {trace}. Work backwards from the throw to the first place the state became wrong. Tell me where it went wrong, not where it fell over.

The distinction between the throw site and the cause is the whole job, and naming it in the prompt is what stops a fix at the symptom.

AI developers

Building on models: choosing them, prompting them, evaluating them, and keeping them in bounds.

What the work looks like

Choose a model against a real workload, not a leaderboard
Design an evaluation before writing the prompt
Build a retrieval step that cites what it used
Bound an agent loop so a failure costs one turn, not a budget
Reduce cost without moving quality — cache, route, or shrink

Leans on

Code & software engineering 16 Agentic & computer use 21 Reasoning & general intelligence 28 Multimodal understanding 15 Cost-efficient & on-device 22

Prompt patterns

Choose against a workload

I need a model for {workload}. Volume {volume}, latency budget {latency}, and it must {constraint}.

Give me three candidates with the trade-off each one makes, and the single test that would tell them apart on MY data. Do not rank them on a public benchmark.

A leaderboard ranks average performance on someone else's distribution. Asking for the discriminating test turns the choice into an experiment.

Evaluation before prompt

Before we write the prompt for {task}: give me twenty test cases, including five that should fail, three that are ambiguous, and two adversarial. For each, state the pass condition in a way a script could check.

Writing the eval first is the only reliable way to know whether a later prompt change helped, and the failure cases are the half people skip.

Bound the loop

Design an agent for {goal} with: a hard step ceiling, an explicit stop condition, a refusal path when the tools return nothing useful, and one log line per step naming the tool and why. Show me what a failed run looks like before you show me a successful one.

Asking for the failure trace first is what surfaces unbounded loops and silent empty results while they are still cheap.

Cost down without quality down

This prompt runs {n} times a day at {cost}. Find the savings in order of risk: what can be cached, what can be routed to a smaller model, what can be shortened. For each, tell me what would break and how I would notice.

Ordering by risk rather than by saving is what keeps the cheapest change from being the one that quietly degrades the output.

PMO and delivery

Keeping work moving: scope, risk, dependencies and the honest status nobody wants to write.

What the work looks like

Turn a rambling update into a status with dates and owners
Find the dependency nobody has written down
Draft a risk register from a plan and a set of meeting notes
Rewrite a scope so what is excluded is as clear as what is in
Summarise a programme for someone joining it tomorrow

Leans on

Reasoning & general intelligence 28 Long context 4 Enterprise platform & governance 17

Prompt patterns

Status from a mess

Turn these notes into a status: {notes}.

Format: what changed since last week; what is blocked and on whom; what slipped and by how long; decisions needed this week with an owner and a date. Anything you cannot source from the notes goes in a list called “unverified”.

The “unverified” bucket is what stops a status report inventing progress from an ambiguous sentence.

Find the unwritten dependency

Here is the plan: {plan}. List every dependency it assumes but does not state — on other teams, on decisions not yet made, on things that must happen in a particular order.

Stated dependencies are already tracked; the unstated ones are what the plan slips on.

Onboard someone tomorrow

From these documents, write the brief I would give someone joining this programme tomorrow: what it is for, who decides what, the three things that will confuse them, and the vocabulary we use that they will not know.

The vocabulary section is the one nobody writes and everybody needs.

Producing a lot of material quickly, in a voice that stays consistent and does not embarrass anyone.

What the work looks like

Take one idea and cut it for four platforms without it reading like the same post four times
Generate or edit an image to a brief, then iterate on it
Turn a long piece into a short video script with shot notes
Draft replies in a brand voice, with the line on what not to say
Check a claim before it goes out

Leans on

Image generation & editing 18 Video generation 15 Voice, speech & music 24 Reasoning & general intelligence 28 Multimodal understanding 15

Prompt patterns

Brief to image, then iterate

Generate {subject}. Style: {style}. Composition: {composition}. It must work at {size} and survive being cropped square.

Then tell me the three things about this image that would stop it being usable, and regenerate fixing the worst one.

Asking the model to critique its own output gives you the next prompt for free, and crop-survival is the constraint people discover after publishing.

Long piece to shot list

Turn {source} into a {duration} script. Give me a table: shot, on-screen text, voiceover, and what has to be visible for the point to land. First three seconds must work with the sound off.

The sound-off constraint is where most generated video scripts fail, because they are written as narration with pictures attached.

One idea, four platforms

Core idea: {idea}. Audience: {audience}.

Write it for {platforms}. Each version must make a different entry point into the same idea — not the same sentence trimmed. Tell me which one you would post first and why.

Specifying “different entry point” is what prevents four near-identical posts, which is what length-only adaptation produces.

Brand-voice reply, with a boundary

Reply to this as {brand}: {message}.

Voice: {voice}. Do not {limits}. Give me two versions — one warmer, one shorter — and flag anything in the original I should not engage with at all.

The last clause is the one that matters: the useful judgement is often “do not reply to this”, and a model will not volunteer it unless asked.

HR and people

Hiring, policy and the conversations that need care — with personal data in the room.

What the work looks like

Write a job description that describes the job
Turn a policy into the five questions people actually ask
Draft a difficult message and check its tone before sending
Summarise feedback without attributing it to individuals
Prepare an interviewer with questions that probe, not prompt

Leans on

Reasoning & general intelligence 28 Long context 4 Enterprise platform & governance 17

Prompt patterns

A job description of the job

Write a job description for {role}. It must describe what the person will actually do in their first ninety days, not a list of adjectives. Include what this job is NOT, and what would make someone unhappy in it.

The “not” section filters better than any requirements list, and honest friction attracts the people who will stay.

Tone-check before sending

I need to tell {who} that {news}. Draft it.

Then: read your own draft as the recipient on a bad day and tell me which sentence lands worst, and why. Rewrite that sentence only.

Reading as the recipient catches the line that is accurate and unkind, which is the one that causes the follow-up meeting.

Policy into real questions

Here is our {policy}. Write the ten questions an employee will actually ask about it, and answer each in two sentences using only what the policy says. Where the policy does not answer the question, say so — that is the list I need most.

The unanswerable questions are the gaps in the policy, and this is the cheapest way to find them.

Finance

Money: forecasting it, explaining it, and getting the number right the first time.

What the work looks like

Explain a variance in one paragraph a non-finance reader believes
Model a cost per task rather than a cost per token
Pull the commitments out of a contract into a schedule
Reconcile two reports that disagree and say which is wrong
Forecast spend on a usage-priced service with a cap

Leans on

Reasoning & general intelligence 28 Long context 4 Cost-efficient & on-device 22 Enterprise platform & governance 17

Prompt patterns

Variance a non-finance reader believes

{line_item} moved from {a} to {b}. Here is the underlying data: {data}.

Explain the move in one paragraph for someone who does not read management accounts. Name the single largest driver and quantify it. If the data does not explain the whole move, say how much is unexplained.

Quantifying the unexplained residual is what separates an explanation from a story that happens to fit.

Cost per task, not per token

We run {workload} at {volume}. Token price is {price}. Build me a cost per completed task, including retries, failures and the ones a human has to redo. Show the assumptions as a list I can argue with.

Per-token pricing hides retries and rework, which is usually where the real number lives.

Contract to commitment schedule

From this contract, extract every financial commitment: amount, trigger, date, and the clause it comes from. Anything conditional goes in a second table with the condition stated. Quote the clause reference for each row.

Requiring the clause reference makes every row checkable, which is what makes the output usable in an audit rather than as a starting point.

IT administrators

Deploying, securing and paying for all of the above, for everybody else.

What the work looks like

Decide what may be self-hosted and what must be
Work out where data goes before anyone asks you in an audit
Set quotas and guardrails that fail closed
Roll out a tool without a support queue forming behind it
Answer “which model did that” six months later

Leans on

Enterprise platform & governance 17 Cost-efficient & on-device 22 Open weights 40 Agentic & computer use 21

Prompt patterns

Where does the data go

For {thing}: list every place data goes — the provider, any sub-processor, the region, what is retained and for how long, and whether it is used for training. Cite the document for each answer. Mark anything you cannot source as unverified rather than assuming the safe answer.

“Assume the safe answer” is exactly the failure that produces a confident wrong statement in a security review.

Guardrails that fail closed

Design the controls for rolling out {thing} to {n} people: quotas, what happens at the limit, what is logged, and who can override. For each control, say what happens when it fails — and make the answer “nothing proceeds” rather than “it is skipped”.

Most quota designs fail open under load, which is the moment they were bought for.

Self-host or not

For {thing}: what would self-hosting actually require — hardware, licensing, who maintains it, what we lose. Compare against the hosted option on total cost including the engineer-days. Tell me the volume at which the answer flips.

The flip point is the decision; everything else is context for it.

Business analysts

Turning what people say they want into something that can be built, tested and argued about.

What the work looks like

Turn interview notes into requirements with acceptance criteria
Map a capability claim to what a model can actually do
Read a benchmark result and say what it does not tell you
Write the process as it is, not as the diagram says it is
Draft the questions that would falsify an assumption

Leans on

Reasoning & general intelligence 28 Long context 4 Deep research & browsing 3

Prompt patterns

Notes to testable requirements

From these interview notes, write requirements. Each one: a single testable statement, its acceptance criteria, and the quote it came from. Put anything you inferred rather than heard in a separate list marked as inference.

Separating heard from inferred is what lets a stakeholder correct the inference instead of discovering it in UAT.

Falsify the assumption

This is our assumption: {assumption}. Write the five questions whose answers would prove it false, ordered by how cheap they are to ask.

Ordering by cost is what turns a list of concerns into a plan for this week.

Read a benchmark honestly

This claim is made about {thing}: {claim}. Tell me: what was actually measured, on what data, under what harness, and what the number does NOT tell me about my use case. Then give me the one question to ask the vendor.

“What it does not tell you” is the whole skill, and it is the part a vendor deck never contains.

Designers

Making things people look at — and iterating faster than a review cycle.

What the work looks like

Go from a brief to several distinct directions, not variations
Turn a screenshot into a critique with specific changes
Generate assets to a spec — size, format, safe area
Produce a front-end prototype from a design
Build a prompt that holds a visual style across many outputs

Leans on

Image generation & editing 18 Multimodal understanding 15 Code & software engineering 16 Video generation 15

Prompt patterns

Directions, not variations

Brief: {brief}. Give me four directions that differ in CONCEPT, not in colour or crop — each one should be arguable against the others. Name the idea behind each in four words before you generate it.

Naming the concept first is what stops four renderings of one idea, which is what a plain “four options” request returns.

Hold a style across outputs

Here is the style I want: {reference}. Write me a reusable prompt fragment that reproduces it — naming the specific attributes, not adjectives like “clean” — that I can paste in front of any subject.

Extracting the style into a reusable fragment is the difference between one good image and a consistent set.

Critique a screenshot

Here is a screenshot of {thing}. Critique it as a {audience} would experience it, not as a designer. For each problem: what the user is trying to do, what goes wrong, and the smallest change that fixes it.

Framing by user intent is what produces actionable notes rather than taste.

Design to working prototype

Build a working front-end of this design: {design}. Match spacing and type scale exactly; use real content, not lorem ipsum. Where the design is ambiguous, make a choice and list every choice you made at the end.

The list of ambiguities is a design review for free — those are the places the design was under-specified.