---
title: Try This — Saturday AI Thoughts
source: https://steadman.ai/newsletters/david/try-this.html
published: 2026-08-07
summary: Every practical tip from Saturday AI Thoughts, collected in one place with copy-and-paste prompts, filterable by category and searchable by keyword.
---

# Try This

Every practical tip from [Saturday AI Thoughts](https://steadman.ai/newsletters/david/), collected in one place with copy-and-paste prompts. Filter by category, search by keyword, copy for your AI tool of choice.

74 tips from 25 editions (22nd February to 8th August 2026). Six categories: Quality & verification, Workflow & skills, Discovery & use cases, Personal practice, Leadership & adoption, Building.

---

## Edition 25: My newest colleague (8th August 2026)

### Never ask it for the average. Ask it segment by segment.
*Quality & verification*

Ask a model for a random number between one and ten. It reaches for seven far more often than a person does. Seven is the number humans pick, and the model overshoots towards it. Every answer you take at face value is a population average, and averages hide the groups who differ. Medicine learned that the hard way. So don't ask how popular something is. Ask it to answer as a woman from Newcastle, then a man from Manchester, then an affluent American.

#### Prompt: Ask it segment by segment
```
I want to understand how [subject] varies, not what the average person thinks about it.

Do not give me a single blended answer. Answer the question below separately, once as each of the groups I list, staying in that group's frame of reference for each pass. Then give me a short comparison: where the groups agree, where they diverge sharply, and which group's answer you are least confident about.

The question: [paste your question]

The groups:
1. [group 1, described by what they need or how they behave, not just demographics]
2. [group 2]
3. [group 3]
4. [group 4]
```

#### Prompt: When you don't know the groups yet
```
Before you answer this, tell me which distinct groups of people would answer it differently, and why. Define them by what they need or how they behave rather than by age and income. Aim for four to six groups that genuinely diverge, and tell me which one is usually left out of research on this subject.

Then answer the question separately for each group, and flag any group where you are extrapolating rather than drawing on something specific.

The question: [paste your question]
```

### Feed it a transcript you already have and ask what they didn't tell you.
*Workflow & skills*

In a coaching session this week I suggested inverting the usual use of a transcript. You already have a pile: the last expert call, adviser session or supplier pitch. Rather than compress what was said, feed one back and ask what wasn't said. The expert's answers give the model enough seed context to explore the ground around the conversation, which you could never reach from a cold start. Start with the most important meeting you were in last week. It will make you see it differently. It always does.

#### Prompt: Ask what they didn't tell you
```
Below is the transcript of a conversation with an expert on [subject]. Do not summarise it.

Tell me what they didn't tell me:
- the questions I should have asked and didn't
- the things a specialist in this field would treat as obvious that never came up
- where their answers were vague, and whether they had any interest in keeping them vague
- what someone with a different position in this market would have said instead

Then give me the five questions I should send them, in priority order, and say what I would learn from each.

[paste the transcript or your notes]
```

#### Prompt: For a supplier pitch or proposal
```
Below are the notes from a supplier pitch about [subject]. I am deciding whether to go ahead.

Work out what has been left out. Cover the costs that were not mentioned, the failure modes a buyer would want to know about, the comparisons they avoided making, and anything they described in language that sounds specific but commits them to nothing.

Then write the three questions that would be most uncomfortable for them to answer, and tell me what a good answer to each would sound like.

[paste your notes]
```

### Ask for tracked changes, not a rewrite.
*Workflow & skills*

Hand a model a document to improve and it hands back a rewrite, which you then have to re-read from scratch to find what moved. Instead, ask for tracked changes: Claude's add-in marks up the open document, and you accept or reject each change like an editor, with a reason beside anything material. The diff becomes the unit of review rather than the document, which is the difference between a check that happens and one that gets skipped on a busy Thursday.

#### Prompt: The tracked-changes instruction, for Word
```
Mark this document up with tracked changes rather than rewriting it. I want to accept or reject each change individually, and I want a one-line reason beside anything material.
```

#### Prompt: The same discipline in any chat
```
Do not rewrite this. List your proposed edits as a numbered change list. For each one: quote the exact current wording, give the replacement wording, and add one line on why the change earns its place.

I will reply with the numbers to apply. Then produce the final version with only those changes made, and nothing else altered.
```

## Edition 24: Smooth enough (1st August 2026)

### Edit two by hand, then ask it what you changed
*Quality & verification*

I had a batch of near-identical outreach emails going out this week, some already sent, the rest still sitting as drafts. Rather than try to describe the changes I wanted, I edited the sent ones myself and gave one instruction: look at the tweaks I made, then do the same to the drafts. The line doing the real work was five words long: "Note the style changes also." I never had to explain my own style, which is just as well, because I couldn't have. Ask it to tell you the rule it inferred before it applies anything.

#### Prompt: Infer the rule from my edits
```
Here are two pieces of work, and the versions I edited by hand afterwards.

The originals:
[paste the two original versions]

My edited versions:
[paste my two edited versions]

Work out what I changed and why. Cover the style changes as well as the substantive ones: word choice, sentence length, what I cut, what I softened, how I open and close.

Before you touch anything else, write out the rule you have inferred, as a short list of the rules you think I follow, so I can check it. Do not apply anything yet. Once I have confirmed the rule, apply the same treatment to the drafts below and show me each revised version next to its original.

[paste the remaining drafts]
```

#### Prompt: Match someone else's judgement
```
A document of mine came back marked up by someone whose standard I need to match. Here is my version and their edited version.

My version:
[paste my version]

Their edited version:
[paste their edited version]

Work out what they changed and what it tells me about what they care about. Separate substance from style. Then rewrite the piece below so it would survive the same review first time, and tell me which of their preferences you are least confident about, so I know where to ask.

[paste the next piece]
```

### Move your best standing instruction into the settings box
*setup*

Setting up Claude with a senior leader who has just gone independent this week, I found they had already worked out an instruction that mattered to them: "I need for you to not guess and don't make assumptions ... if you don't know, and your response isn't based on data and facts, just say you don't know." A second clause was added from irritation: "I really don't need you to waste half a screen telling me how brilliant I am." They had been repeatedly typing it into individual chats. To make it count for all future chats, all I did was show them the settings box.

#### Prompt: The instruction, for your settings box
```
I need for you to not guess and don't make assumptions. If you don't know, and your response isn't based on data and facts, just say you don't know. And I really don't need you to waste half a screen telling me how brilliant I am.
```

#### Prompt: A project-level variant
```
For everything in this project: don't guess and don't make assumptions. If you don't know, and it isn't in the material I have given you here, say you don't know and tell me what you would need. Where a status or a decision is not recorded in the material, say it isn't recorded rather than inferring what it probably is. Keep answers short and skip the praise.
```

### Give your plan an escape hatch
*Workflow & skills*

Working through a multi-step production plan last week, I stopped writing instructions and added one sentence at the end: review this plan, and if you agree with it, execute it; if you disagree, execute whatever path you think is best instead. Hand over a plan and ask for it to be followed and the result can only be as good as the plan. Give it permission to disagree and it can tell you the route is wrong before it spends an hour walking it. Of course I carefully checked, edited and owned the results!

#### Prompt: The escape hatch
```
Here is my plan. Read it through before you start.

[paste the plan]

If you agree with it, execute it as written. If you disagree with any part of it, execute the approach you believe is better instead, and tell me what you changed and why as you go.
```

## Edition 23: Burned and earned (25th July 2026)

### Get most of the way with AI, then pay the expert only for the last mile
*Quality & verification*

I had a business question this week with real money riding on it, and my adviser's time runs to £375 an hour. Rather than book the whole job, I worked it through with Claude for about half an hour, going back and forth, then sent my adviser the answer I'd reached. They replied that I was mostly there, and just wanted a quick call on the final points. Arriving most of the way changes what you are paying for: the judgement and the sign-off, not the spadework. The prompt below asks the model to show its reasoning and cite the rules it relies on, and to say plainly when it cannot find the actual text of a rule rather than paraphrasing it as a citation.

#### Prompt: Work it through before the adviser
```
I have a [tax / legal / contract] question with real financial consequences, and I want to work it through before I take it to my adviser. Here is the situation:

[paste the full situation: the facts, the numbers, the documents or clauses involved, and the specific question I need answered]

Work through it with me step by step. Show your reasoning as you go. Cite the specific rules, sections or clauses you are relying on, and quote them where you can. If you cannot find the actual text of a rule, say so rather than paraphrasing it as a citation. Where you are uncertain, or where the answer depends on a fact I haven't given you, say so clearly and tell me what you'd need to know. End with a short plain-English summary I could put in front of my adviser, plus the two or three points you'd most want a specialist to confirm.
```

#### Prompt: For a document you already hold
```
Here is the full contract: [paste]. I'm trying to work out [the question]. Point me to the specific clauses that bear on it, quote them, and explain how each one applies. Don't give me a verdict; help me find the parts I need to read myself.
```

### Give your own AI everything I've written, then ask it for your next AI paper
*setup*

Every essay, news item and tip from all 23 editions so far lives on the archive, and each page has a button that copies everything, formatted for a model to read. Paste it into a project or a chat. Then the next time you need an AI strategy paper, a board note or a weekly update, you are not starting cold. You have arguments, numbers and examples to draw on. If your AI can browse, skip the copying and point it at the .md companions instead. Or skip the paste entirely and ask the chatbot on the site; it has read the lot.

#### Prompt: Load the archive as context
```
I'm giving you the full contents of David Boyle's weekly AI email (essays, news analysis and tips from steadman.ai/newsletters/david/). Read it and hold it as context for our future work.

[paste the copied content here]

When I ask you for help with AI strategy work, a strategy paper, a board note, a talk, or a weekly update of my own, draw on this material: the arguments, the numbers, the examples and the positions. Tell me which edition an idea came from when you use one, so I can link to the original.
```

### On Friday, have the model mark your own week's AI usage
*habit*

Ask the model you use most to look back over your chats and tell you three things: what you leaned on, what you never touched, and what to try next. Someone I work with does exactly this every Friday. Most of us settle into a few habits without noticing. This breaks the rut. Keep it to your own history: across a team it would mean reading other people's private chats.

#### Prompt: Mark my own week
```
Look back over my chats with you this week. Tell me three things:

1. What I mostly used you for, in plain terms.
2. What I clearly avoided, underused, or never tried, that I probably could have.
3. The three things I should experiment with next week to get more out of you, with a one-line reason for each and a concrete first step I could take.

Be specific and use examples from our actual conversations. Don't flatter me; if I've plateaued on a couple of habits, say so.
```

## Edition 22: Futures and fears (18th July 2026)

### Ask the AI what you should be worried about, not what you should do
*Quality & verification*

Weighing a significant business proposal this week, I pasted it into Claude and asked what I should be worried about, not what I should do. Several of the questions I went on to raise weren't mine. The model flagged whether the terms would stay fair as both sides grew, and how each party's contribution would be counted, considerations I hadn't put near the top of my list. The move is a one-line reframe on whatever decision you have open right now: hand over the material, then ask for the questions rather than the verdict. A second mind widening the frame before you decide.

#### Prompt: Ask for the questions, not the verdict
```
Here is a proposal I'm considering: [paste the proposal, or describe the decision and its terms]. Don't tell me whether to accept it, and don't summarise it back to me. List the questions I should be asking and the considerations I'm most likely to have skipped: how the terms play out as things grow or change, the edge cases, and anything I'll wish I'd asked about in a year. Rank them by how much the answer would change my decision.
```

#### Prompt: For decisions without a document
```
I'm about to decide: [describe the decision in a sentence or two]. Before I do, act as the cautious colleague. What should I be worried about? List the risks, assumptions and second-order effects I'm most likely to be underweighting, and for each one tell me what would make it matter.
```

### Point the AI at the statements nobody reads
*Workflow & skills*

On a call this week, an artist described a payment from a collecting society several times larger than anything they'd ever received, with no new release and nothing obvious to explain it. My suggestion: this is exactly the work a language model is for. Reconciling opaque statements is dull, error-prone work it does well, across a whole back-catalogue at once, surfacing the payment that breaks the pattern and the likely reason. Everyone sits on some pile they've stopped reading: invoices, expense reports, royalty runs. This one is a habit, not a one-off — run it once now, then re-run it monthly with the latest statement added, and anomalies surface while they're still explainable.

#### Prompt: Reconcile the pile
```
Here are [twelve months of statements / invoices / royalty reports / payment records]: [paste or attach them]. Reconcile them. List every payment or line item that breaks the pattern of the others, note what changed around it, and give your best explanation for each anomaly. Where you can't explain one, say so plainly and list what extra information would settle it. Show the numbers you used so I can check them.
```

### Spend ten minutes checking what your AI tools can reach
*Building*

The Grok Build episode in Three things this week is also a to-do item. A researcher's write-up showed an official tool from a major AI lab quietly zipping up whole project folders, sweeping in a secrets file holding a live access key the user never handed over. xAI switched the upload off within a day, but the lesson stands for every AI tool that runs on your machine: the thing to audit is its reach. Which folders, which files, which credentials. Pleasingly, the best tool for auditing your AI tools' reach is an AI tool — ask it to enumerate its own access alongside everything else's. List your tools and what each can see. Ten minutes, well spent.

#### Prompt: Enumerate every tool's reach
```
List every AI tool, extension, agent or assistant with access to this machine or my accounts, including you. For each one: which files, folders, credentials and services can it reach? Which of those can it write to, or send data from? Rank the list by what I'd least like leaving the building, and flag anything whose access you can't verify.
```

#### Prompt: Walk me through a ten-minute audit
```
Help me run a ten-minute access audit of the AI tools I use. Walk me through it one question at a time: (1) which AI tools are installed on this machine or connected to my accounts, (2) what access each was granted when I set it up, (3) which can read beyond the folder or document I point them at, (4) which hold or can see live credentials or account keys, (5) which send data off this machine, and to where. At the end, give me a summary table and the top three things to tighten.
```

## Edition 21: Sarah stays (11th July 2026)

### Split the job: let the strong model plan and check, and a cheaper one do the work
*Workflow & skills*

Dharmesh Shah, the founder behind HubSpot who now writes at simple.ai, has a tidy answer to the bill that arrives when you run everything on your best model. Ask the expensive model once to write step-by-step instructions a cheaper assistant could follow every time. Run the task itself on the cheaper model. Then hand the result back to the strong one to grade against its own plan. You pay premium rates only for the thinking and the checking, never the grunt work. The same week Shah published this, a large company reportedly burned its entire 2026 AI budget in four months by doing the opposite.

#### Prompt: Split one repeated task across price tiers
```
I run this task regularly: [describe the task and paste a typical input].

Write step-by-step instructions that a cheaper, less capable AI assistant could follow to do this task well every single time. Be explicit about the inputs, the steps, the format of the output, and the common mistakes to avoid. I'm going to hand these instructions to a cheaper model, so assume less reasoning ability and spell things out.
```

#### Prompt: Check the cheaper model's result
```
Here is the plan I wrote for this task, and here is the output a cheaper model produced by following it.

PLAN:
[paste the instructions]

OUTPUT:
[paste the cheaper model's result]

Grade the output against the plan. What did it get right, what did it miss, and what would you fix? Be specific.
```

### Ask the model to regroup the data around the decision you're actually making
*Workflow & skills*

Last week I was staring at a group grocery order for a retreat, and the same things were scattered all through it: three cheeses in one place, three more further down, milks and juices spread out because that's the order the supermarket puts them in. So I asked the model to put it back together my way. All the cheeses together, quantities added, each item tagged by which meal it was for, rendered as a clean table I could think with. That's the general move. A list, an export or a bank statement is almost always arranged for some system's convenience. When it's hard to reason about, don't read it harder. Ask the model to rearrange it around the decision you're trying to make.

#### Prompt: Rearrange data around your decision
```
Here is a [list / export / report]. It's currently ordered for [the system that produced it, e.g. the supermarket / my CRM / the bank].

Regroup it around the decision I'm actually making, which is [state the decision, e.g. planning meals for the week / working out which accounts to call / seeing where the money went].

Group it by [the thing I care about], add the fields I need ([e.g. quantities, dates, owner, total]), tag each item by [meal / project / stage], and render it as a clean table.

Take your time, and ask me a clarifying question rather than guessing if anything is ambiguous.
```

### Write your one-line refusal before you scale a single agent
*Leadership & adoption*

CVS Health, the American pharmacy and health-insurance company, drew its boundary in one sentence before scaling anything: AI will never make decisions. Period. Hallelujah. More should say this loudly. Underneath sit three hard nevers: never diagnose a patient, never drive a claim denial, never take the human out of the patient's experience. Every use case has to fit inside the line or it doesn't ship. It sounds limiting to many, but their agentic claims system still assembles the eligibility and coverage data and recommends next steps, and complex-claim time fell by more than 20%. A one-line refusal travels through an organisation faster than a strategy deck. Write yours, then hold your current and planned AI uses up against it. Please.

#### Prompt: Test your uses against the line
```
Here is my organisation's one-line refusal for AI, and the hard nevers underneath it:

REFUSAL: [your sentence]
NEVERS: [never X, never Y, never Z]

Here are the AI uses we're currently running or planning: [list them].

Go through each one and tell me which breach the refusal or any of the nevers, which sit close to the line, and which are clearly fine. For any that breach it, suggest the smallest change that would bring them back inside the line.
```

## Edition 20: Look at the grass (4th July 2026)

### Give any automation a few reversible dress rehearsals before you trust it for real
*Quality & verification*

This week I set up an agent to grab a hard-to-get morning swim slot for Teresa at our local gym, and I didn't hand it the real booking on day one. For the three days before the one that mattered, it booked a genuine slot the proper way, then immediately cancelled and emailed me the confirmation. My thinking was simple: "If it works for three days, then we can feel good. If it doesn't work for three days, then we've got three chances to fix it before it goes live." The rehearsal runs the whole chain against the real system, but in a mode where any failure is free to fix.

#### Prompt: Brief the agent to run book-then-cancel for three days
```
Before you do this for real, run it as a dress rehearsal for the next three days.

The task: [describe the real action, e.g. "book the 7am swim lane the moment reservations open"].

Rehearsal mode: each day at the real time, carry out the full task against the
real system exactly as you would for real (log in, navigate, complete it), then
immediately undo it (cancel the booking / delete the draft / reverse the action)
so there is no lasting effect. After each run, email me a short confirmation:
what you did, whether every step worked, and anything that failed or looked off.

If all three rehearsals succeed, tell me you're ready to go live. If any fails,
stop, tell me exactly where it broke, and wait for me to fix it before trying again.
```

### Find the one thing your AI reliably gets wrong, then make it your first check
*Quality & verification*

Any AI tool you use on a repeated task has a consistent blind spot: the transcript that always mangles names, the meeting summary that always drops the final ten minutes, the invoice reader that always leaves the tax field blank. Mine was that last one. Catching it recovered £9,860 of VAT that would otherwise have gone unclaimed. The habit: the first few times you use a tool, compare its output with the source and note what it consistently misses. Then make that one thing your standing first check. You keep the time-saving without inheriting the blind spot.

#### Prompt: Spot-check the one field that's always wrong
```
You've read [N] documents into [system / spreadsheet]. Before I trust the result,
do one narrow check.

The field that's often wrong here is: [e.g. the VAT / tax amount].

For every document, show me a small table with three columns: the document
reference, the value you recorded in that field, and the value that actually
appears in the source. Flag any row where they differ or where the field came
back blank, and total up the difference. Don't check or summarise anything else,
I only want that one field verified against the source.
```

### Queue what you'd doomscroll past, and have a model teach it back at your level
*Personal practice*

Suhail Doshi, the founder behind Mixpanel and Playground, described the habit on X: queue every interesting blog post, paper or tweet, ask a model to teach it back to you, and read the approachable version in spare moments instead of doomscrolling. The model doesn't just summarise; it teaches, pitched at how much you already know, so a dense paper meets you where you are. The simplest way in: paste a link or the text into Claude or ChatGPT with "Teach me this. Here's what I already know:" and one honest sentence. Read that version instead.

#### Prompt: Teach this back to me at my level
```
Teach this back to me rather than summarising it.

Here's where I'm starting from: [one line on what you already know, e.g. "I understand
the basics of how language models work but not the maths, and I've never read a
machine-learning paper"].

Explain the piece as if you're bringing me up to speed: start from what I already
know, introduce each new idea only when I need it, define any term the first time
you use it, and use a concrete example wherever an abstract point would otherwise
be hard to hold. At the end, give me the three things worth remembering and one
question I should be able to answer if I've followed it.

[paste the article / paper / thread here]
```

## Edition 19: A thousand small bargains (27th June 2026)

### Make the model cite its sources, so a check is one click, not a re-read
*Quality & verification*

A documentary production team I worked with this week showed me the cleanest version of this. They were using a Claude-based transcript tool I built to mine hours of footage, and the editor insisted every quote come back tagged with its time code. The reason was simple: the AI's transcription could be slightly wrong, but the time code never is. When a summary looked off, the editor jumped straight to the original clip and checked what was actually said rather than trusting the paraphrase. Time codes, page numbers, line references all do the same job. The pointer costs nothing to ask for, and it lets you own the output on a light read, then jump straight to the source on the one part that has to be right.

#### Prompt: Ask for the location pointer
```
For every quote, fact or passage you return, include the exact location it came from in the source, in square brackets immediately after the item.

Use the most precise pointer the source supports:
- Audio or video transcript: the time code
- PDF or document: the page number, plus a section heading if useful
- Code: the file path and line number
- Long-form text: the paragraph or section reference

If you cannot locate a specific item in the source, say so explicitly rather than guessing.
```

#### Prompt: Meeting-transcript variant
```
Read the attached transcript and return:
1. Every decision that was made
2. Every action item, with the person who owns it
3. Every open question that didn't get resolved

For each item, include the time code from the transcript in square brackets. If the speaker isn't identified at that point, mark it [unattributed].

If you can't find clear evidence of a decision or action in the transcript, leave it out rather than inferring it.
```

### Build an AI version of the person before a high-stakes meeting, then mine its blind spots
*Discovery & use cases*

Before interviewing GitHub's chief operating officer, the writer Mike Taylor, writing in Every, built an AI persona of the COO from everything publicly known about them and ran his planned questions past it first. The simulation's misses were the useful part. Where the persona's answers went thin or vague was exactly where public information ran out, so Taylor spent the real conversation on what no model could already know. Most people use AI to generate questions. This inverts it: ten minutes rehearsing in front of an AI version of the person tells you which questions aren't worth their time, and points you at the ones that are.

#### Prompt: Rehearse the meeting against an AI persona
```
You're going to play the role of [name], [role at company]. I have a meeting with them on [date] and I want to use the next ten minutes to work out where my prepared questions are weakest.

Below is everything I have on them from public sources. Read it carefully, then answer my planned questions in their voice, drawing only on what's plausibly knowable from the public record.

After each answer, rate your own confidence from 1 to 5, where 5 means "this is well-covered in public and the real person would say something similar" and 1 means "I'm guessing, the public record doesn't reach this".

My planned questions:
1. [question]
2. [question]
3. [question]
...

Public material on [name]:
[paste bio, interviews, posts, company announcements]
```

#### Prompt: Sales or pitch-call variant
```
Play the role of [name], [role at company]. I'm pitching them [what you're pitching] on [date].

Based on everything you can infer from the public material below, list the three to five objections they're most likely to raise, ranked by how hard each one is to answer. For each objection, note what about their background or their company's recent moves makes you think they'd raise it.

Then tell me which objection I'm probably least prepared for, given the pitch outline I've pasted in.

Pitch outline:
[paste outline]

Public material on [name]:
[paste]
```

### Stop asking your inbox vague questions. Label first, then ask one scoped thing
*Workflow & skills*

The AI assistant now sitting inside most email gives a vague answer when you ask it a vague question across the whole inbox. Narrow it. Label the threads that belong to one project or client, then ask something specific: "what am I waiting on from Sam about the website", or "the action items under the Clients label that I never replied to". It comes back with who you owe, the questions you left unanswered, and what people asked you to send. Then ask it to turn those into a checklist, and the list drops straight into your week.

#### Prompt: The four-line task brief
```
Goal: [what you want, in one sentence, with the shape of the output: number of items, length, format, level of language]

Scope: [what the model can decide for itself; what it can't; any sources or tools to prefer or avoid]

Stop: [the condition under which the model should pause and come back to you rather than push on, e.g. "if two searches turn up nothing useful, stop and tell me what you tried"]

Exclude: [anything off-limits: personal or sensitive information, particular sources, particular framings, particular conclusions you don't want it reaching for]
```

#### Prompt: Worked research example
```
Goal: Summarise five AI news items from the last 24 hours. Three sentences each, plain language, with the source URL at the end of each item.

Scope: Choose the sources freely. Avoid paywalled sites. Prefer named reporters or named research labs over anonymous aggregators.

Stop: If two searches turn up nothing useful in the last 24 hours, pause and tell me what you searched for so I can adjust.

Exclude: No personal or sensitive information about individuals. No items where the only source is a single anonymous social post.
```

#### Prompt: Worked writing example
```
Goal: Tighten the attached draft for length and rhythm. Target 600 words, keep every argument and every named example, cut hedging language and redundant transitions.

Scope: You can rewrite sentences. You cannot change the order of the arguments, add new examples, or soften the conclusions.

Stop: If you can't get to 600 words without losing an argument or an example, stop and tell me which two or three cuts you'd recommend so I can choose.

Exclude: No new claims, no new data, no smoothing of the conclusions. The voice should stay the same.
```

## Edition 18: Average by default (20th June 2026)

### Tell the model what's at stake before you ask the question
*Quality & verification*

In a coaching session this week, a senior leader asked Claude to advise on a question relating to government policy. The first answer was confident, generic, and thin: the sort of thing a busy colleague would shrug at you across a desk. Adding one sentence changed the work. "The answer is critical. Provide authoritative sources." The model switched register, went to the primary regulatory documents, quoted the relevant sections, and linked each claim back so the human could check it. Nothing about the question had changed. The model simply hadn't known the stakes.

#### Prompt: Naming the stakes before the question
```
The answer to the question below is critical to a live decision I'm about to make. Treat this as a high-stakes request. Go to primary sources, quote the specific sections you're relying on, and link each claim back to its source so I can verify the work. If the sources disagree, surface the disagreement rather than picking a side. If you can't find authoritative sources for a claim, say so explicitly rather than filling the gap.

My question:
[paste your question here]
```

#### Prompt: Short variant
```
Stop. Treat the question above as a high-stakes decision. Re-answer it from primary sources only, quote the relevant sections, and link each claim. Flag anything you can't source.
```

### Stamp every AI output "raw, not yet checked" until you've taken ownership
*Quality & verification*

Mentoring Ethan, Steadman's placement-year researcher running an interview project, this advice landed as a rule for any document created by AI: it's either raw AI output, or it's something you've checked, edited, and will stand behind. Set your tool to auto-stamp every output with a line saying "raw AI output, not yet checked, edited and owned," and leave it there. Removing the stamp by hand becomes the deliberate act of taking ownership. Anyone who picks up the file later, or has it forwarded to them, knows exactly which of the two things they're holding.

#### Prompt: The raw-or-owned stamp
```
At the very top of every document, draft, summary, plan, or written output you produce for me, include this line, in italics, exactly as written:

*Raw AI output. Not yet checked, edited and owned by a human. Remove this line once it has been.*

Keep the line in place on every revision until I explicitly tell you I've taken ownership of the document. If I ask you to edit a document that still has the line, keep the line. If I paste in a document that already has the line, keep the line. Removing the line is something I do by hand, deliberately. It is my signal that I've read the work, edited it, and will stand behind it.

If a document is short enough that the line would dominate it (a one-line answer, a quick lookup, a single sentence), skip the stamp.
```

### Book a meeting with yourself, hit transcribe, ramble for fifteen minutes
*Personal practice*

A senior advisor told me this week that their real value sits as strong points of view in their head, none of it written down anywhere. The fix: put a meeting in your own diary, hit transcribe, put your feet on the desk, look out of the window, and talk. Don't try to be structured. Change your mind, go down rabbit holes, tell stories. The transcript becomes a thesis document you can feed any model so future answers come back already loaded with your frame, your caveats, your taste.

#### Prompt: For the recording session
```
I'm recording a fifteen-minute ramble about [topic]. I'm going to think out loud, change my mind, go down rabbit holes, and tell stories. The point is to capture how I actually think about this, not to produce a polished view. I won't try to be structured. The transcript will be fed to an AI later as my point-of-view reference on [topic].
```

#### Prompt: The standing instruction
```
Below is a transcript of me thinking out loud about [topic]. It is unstructured, contradictory in places, and full of asides. Treat it as my authoritative point of view on [topic] going forward.

When I ask you anything about [topic], answer in my frame, with my caveats already loaded. Prefer my framings and examples over generic ones. Where I've changed my mind in the transcript, treat the later view as the current one unless I tell you otherwise. Where I've contradicted myself and not resolved it, flag the contradiction rather than picking a side. Don't smooth out the edges of what I think; if I'm sharp on something, stay sharp.

Transcript:
[paste transcript here]
```

## Edition 17: Ride the bike (13th June 2026)

### Ask the AI to write the marking scheme before it writes the answer
*Quality & verification*

Ben Yoskovitz, a non-developer who ships production software with AI, wrote this week about how he stops the model declaring something done before it's actually done. Before any non-trivial task, he asks the AI to write three to five specific pass-or-fail checks for the work. He approves them. The AI then does the job, grades itself against each check, cites the evidence, and stops the moment one fails. The discipline costs ninety seconds and saves the long loop of "looks good" followed by "wait, no it isn't".

#### Prompt: The marking scheme
```
I'm about to ask you to do this task: [the task].

Before you do any of the work, write three to five specific pass-or-fail checks I can use to tell whether the finished output is actually good. Each check should be concrete enough that you and I would agree on the verdict. No vague criteria like "clear" or "useful". Something I could grade objectively.

Show me the checks. Wait for me to approve or amend them.

Once I've approved them, do the task. Then grade your finished work against each check, one at a time, in order. For each check, cite the specific evidence in your work that supports the pass or fail verdict.

If any check fails, stop. Don't paper over it. Tell me which check failed, why, and what you'd need to change. We'll decide together whether to fix it or whether the check itself was wrong.
```

### Plan in one session, then start a fresh one to build
*Workflow & skills*

Tiago Forte, the productivity author, wrote this week about treating the first AI session as planning-only when the goal is a concrete document or deck. Work out the brief in chat one. Don't let the model start drafting. Then open chat two, paste the brief, and build from there. Three things happen. Long sessions accumulate irrelevant context and quietly degrade, so a clean start gives you a sharper model. The deliberate stop forces you to ask whether the brief actually holds together. And if the second session crashes, you've still got the brief.

#### Prompt: The fresh-session starter
```
Here is the brief I worked out in a separate planning session:

[paste brief]

Start fresh. You haven't seen any of my earlier thinking on this. Build the [document / deck / analysis / artefact] from this brief alone.

If anything in the brief is ambiguous or contradictory, ask me before guessing. If anything is missing that you'd need, name it and stop.

When you're done, tell me what you built and where it is. Don't summarise the brief back to me.
```

#### Prompt: Variant for a research task
```
Here is the research question and scope I worked out in a separate planning session:

[paste brief]

Start fresh. Do the research. Gather what's relevant, weigh it, and write me a one-page synthesis. If you find the question needs reframing once you've started looking, say so before you go further.
```

### Keep your AI project lean
*Workflow & skills*

In a training I ran, someone asked why their Claude project had got slower over a few weeks. They'd been adding reference files to it. The model reads everything in a project on every request, and once it's getting crowded the answers go duller and the replies take longer. Two habits help. Book fifteen minutes on a Friday to prune, the way you'd tidy a desk. And never leave fat PDFs in there. Ask the model to convert each one to plain text first. PDFs burn far more of the model's time and reading capacity than the same content as text, and the conversion takes a minute.

#### Prompt: Convert a PDF to lean text
```
Here's a PDF that's currently in my project. Read it carefully and write it back to me as plain text or markdown.

Preserve the structure: headings, sections, lists, tables. Don't lose any detail. Don't summarise. The goal is a faithful conversion that I can swap in for the PDF, so the project takes up less of your reading budget without losing any of the substance.

If anything in the PDF is genuinely unclear (an image, a chart with no caption, an unreadable scan), name it rather than guessing.
```

#### Prompt: The Friday-prune audit
```
Audit the files in this project. Tell me:

1. Which files look stale, in the sense that they cover something we're no longer working on or have been superseded by something newer in the project.
2. Which files look like duplicates or near-duplicates of each other.
3. Which files are PDFs that would be much smaller as plain text, and which of those are worth converting.
4. Which files you find yourself rarely needing when answering my questions in this project.

For each, recommend prune, convert, or keep, with one line of reasoning. I'll decide what to action.
```

## Edition 16: The open door (6th June 2026)

### Have the AI orient itself in your folder before you ask it anything
*Workflow & skills*

Setting up a Claude Cowork project for a documentary filmmaker brand-new to the tool this week, the first prompt I typed wasn't about the work. It was to read the files and sub-folders and write itself a little set of instructions for future chats: a navigation guide. Claude spent a few minutes exploring, then saved itself three memory files: a project overview, a folder guide, and a profile of the user. Every later chat in that project started smarter, because it could re-read its own notes.

#### Prompt: The navigation guide
```
Read every file and sub-folder in this project. Don't do any work yet.

Write yourself three things, saved as files in this project so you can read them in future chats:

1. A project overview: what this body of work is, who it's for, and what the most important files are.
2. A navigation guide: which files you should always read at the start of a chat in this project, which are reference, and which are working drafts that change often.
3. A short profile of me: what you can infer about my role, what I'm trying to do here, and how I tend to work, based on what's in the folder.

Be honest about what you don't know. If something in the folder is ambiguous, name it as ambiguous rather than guessing.
```

#### Prompt: For a bigger folder
```
Before doing any work, explore this project. Then write me a one-page memo answering:

- What is this project about, based on the files?
- Which three to five files should any future chat in this project read first?
- What is missing from this folder that would help you help me? Be specific: a brief, an example, a deadline, a style sheet.

Save the memo as PROJECT-NOTES.md in the project root. We'll iterate on it.
```

### Don't say "always allow" on the verbs you can't undo
*Building*

In a coaching conversation this week about agent permissions, the pattern was familiar. Three prompts in, most people click "always allow" on everything just to stop the interruption. The discipline is to sort the verbs first. Reading, listing, searching: leave on auto. Deleting, sending, posting, spending: keep asking every time. Sorting the verbs first is what keeps one careless click from emptying a folder, sending an email you can't unsend, or running up a charge you didn't mean. It applies to any tool that asks for permission as it works.

#### Prompt: Let the agent name its own destructive verbs
```
You're an agent with permission to act on my files, my email, and the web on my behalf.

List every distinct kind of action you can take. Group them into three buckets:

1. Safe to always allow: read-only, listing, searching, fetching public information. Nothing here can cause loss I can't recover from.
2. Ask every time, no exceptions: anything destructive, irreversible, public-facing, or that costs money. Deleting, overwriting, sending email, posting to social, paying for an API, calling an external service that takes an action in the real world.
3. Borderline: actions that are reversible but annoying, or that touch shared state. Recommend a default for each and explain your reasoning.

For each bucket, give me the exact setting name in this tool's permissions UI, so I can configure it correctly in under five minutes.
```

### Talk longer on the call, so the AI can work for hours after
*Workflow & skills*

On a client call this week, the brief changed mid-conversation. The plan we'd opened with wasn't the plan we were leaving with. I deliberately used more words than I otherwise would, narrating the bridge between the old direction and the new one. The over-explaining was really for the AI: context I was laying down for it to pick up later, once the transcript was in the project. The transcript plus "go" did the work. The next time you're on a call that's being transcribed, elaborate a little more than you otherwise would and narrate the why, not just the what.

#### Prompt: Turn a transcript into the brief
```
Attached is the transcript of a call I had today with [who, and their role].

The call started with us aligned on [old direction], and ended with us aligned on [new direction]. Most of the transcript is me talking through the bridge between the two: what changed, why, what's still uncertain, what we agreed.

Do three things:

1. Write a one-page brief capturing the new direction, the reasoning behind the shift, and any open questions. Save it to the project as BRIEF-[date].md.
2. List every concrete next step I or my team committed to, with who owns each. Save as ACTIONS-[date].md.
3. Tell me what's still ambiguous after reading the transcript. Don't invent answers; just name the questions I should resolve before any of this work starts.

Then stop and wait for me to review before doing any of the follow-on work.
```

#### Prompt: When the call was a working session
```
Attached is the transcript of today's working session on [project]. I've explained at length what I want the next pass of the work to do.

Read the transcript carefully. Then start the work. Don't summarise the transcript back to me first. Don't ask clarifying questions unless something is genuinely contradictory. Save your work into the project folder and tell me what you did and where to find it when you're done.
```

## Edition 15: How We Got Here (30th May 2026)

### Ask the model what else it needs to know
*Workflow & skills*

The most productive sessions I see with senior leaders don't open with a clever prompt. They open with the user pasting context, their role, the situation, what they're trying to do, and then asking two questions. First: "what else do you need to know about me to help me well?" Second: "what could you do for me right now that I haven't asked for?" The first surfaces gaps the user wouldn't have spotted. The second produces use cases the user didn't bring. The blank-prompt paralysis dissolves.

#### Prompt: The two priming questions
```
[Paste your role, the situation, and what you're trying to do.]

Now, before we start, two questions:
1. What else do you need to know about me to help me well?
2. What could you do for me right now that I haven't asked for?
```

### Either AI challenges you at the start, or you challenge AI at the end
*Quality & verification*

A leader I sat with this week had let an AI output stand without pushing back. My diagnosis: two patterns work and one fails. You can challenge before the model starts: share your point of view and ask the model to challenge it, force it to surface the holes and the strongest counter-argument. Or you can challenge after the first draft: force a rewrite, name what's wrong, make it earn the second pass. The pattern that fails, and the one I see most, is read-and-accept. Pick one of the two postures and don't drift into the third.

#### Prompt: Challenge before it starts
```
Before you do this task, here is my point of view: [your take]. Challenge it. Surface the holes, the assumptions I'm making, and the strongest counter-argument against me. Then we'll do the work.
```

#### Prompt: Challenge after the first draft
```
That's a first draft. Don't defend it. Tell me what's weakest about it and why, then rewrite it to earn a second pass.
```

### Ramble into the microphone, let the machine find the structure
*Workflow & skills*

A managing director I coached this week outlined obsessively. Some 700 words of outline for a 1,500-word article. The cost of structuring before writing was eating his weekend. The fix was inverting the order. Pick up your phone, dictate the mess, paste the transcript into your model, ask it for the through-line. Structure becomes the cheap thing. Particularly powerful for the executives who think by talking, which is more common at the top than people admit.

#### Prompt: Find the through-line
```
Attached (or pasted below) is a raw, rambling transcript of me thinking out loud about [topic, or the piece I need to write].

Don't tidy my words. Find the through-line: the argument I'm actually circling, the order it should go in, and the two or three points I keep returning to that matter most. Give me a clean structure I can write into.
```

## Edition 14: Kids these days (23rd May 2026)

### When the output goes wrong, shrink the task
*Quality & verification*

Justin Skycak put it as a principle for skill acquisition this week: shrink the unit of practice until the mistake has nowhere to hide. The same rule applies to working with language models. Sprawling prompts produce sprawling failures you can't diagnose. Break the task into its smallest meaningful unit, run it, inspect the output, then rebuild. If you can't immediately see where it went wrong, your chunk is still too large.

#### Prompt: Option A - diagnose
```
The response above isn't quite right. Before I rewrite my prompt, help me decompose. Walk me through the task you just attempted as a sequence of the smallest possible sub-tasks. For each sub-task tell me (a) what specifically you did and (b) which sub-tasks you think are most likely to have caused the failure, with your reasoning. I'll then tell you which one we work on alone.
```

#### Prompt: Option B - pre-empt
```
Take the task above, break it into a series of individual prompts. I want to run them one by one next time so that I can more easily validate each step before moving on to the next. For each prompt, tell me what input I'll need to hand in and what output I should expect, so I can tell whether the step worked.
```

### Ask AI questions it can't possibly know the answer to
*Quality & verification*

A marketing lead at a global firm told me this week she's running a five-minute stress-test on every AI tool she's thinking of trusting. She uploads her own data, asks the model to use only that data, then asks it questions she knows the data can't answer. She's learned what its confident-but-wrong mode looks like before depending on it for an answer she can't independently check. Worth doing once on every tool you rely on.

#### Prompt: The impossible-questions stress-test
```
I'm going to stress-test you. Use ONLY the data and documents I've already shared with you in this conversation. Do not browse the web. Do not draw on your training data. Do not infer beyond what's explicitly in front of you.

I'll ask you three questions.

For each question, either give me the answer with the exact source location, or tell me explicitly that the materials don't contain the answer. Don't guess. Don't reach. Don't pad.

Question one: [your first question - answerable from the materials]
Question two: [your second question - answerable from the materials]
Question three: [your third question - NOT answerable from the materials]
```

### Run your day past AI before you start it
*Workflow & skills*

A senior leader described her commute habit to me this week. She opens Claude, asks it to review her calendar and her email, then asks it to surface what she needs to read before each meeting, what's carrying over from yesterday, and which emails in her inbox need replies before the day eats her. Five minutes on the train, and the day is scoped from outside her own head. \"Just a nice little daily habit,\" she said. Try it tomorrow.

#### Prompt: The morning prep prompt
```
Review my calendar for today and my email inbox for the last 48 hours. Then walk me through the day in three sections.

(1) Pre-reads. For each meeting on the calendar, what should I read or recall first, and what's the single most useful question I should arrive with? Pull context from any email threads tied to the meeting if you can see them.

(2) Carry-overs. Which open threads or commitments from yesterday's calendar and email are likely to collide with today's schedule? Anything I said I'd do that I haven't, and that today is the last clean window for?

(3) Email replies. Which unanswered emails in my inbox need replies before 11am, in what order, and what's the key point each reply needs to make?

Be specific. Time-box each item if you can. Flag any conflicts I should resolve before 9am.
```

## Edition 13: What boards accept (16th May 2026)

### Hand over the context, not just the question
*Workflow & skills*

Experienced leaders have context. They're short on time. AI tools convert context into time saved, but only if you hand the context over. Most don't. They type questions ("how should I structure a board paper on Q2?") and get general answers ("a clear narrative arc, three key insights, a risk slide"). Useful, but the leader still writes the paper. A leader I spoke with this week made the leap from asking to delegating. "Here are the Q2 numbers, last quarter's board paper, and the three things the board flagged. Draft it." Same model, same minute. Asking gets you an outline. Delegating gets you a draft.

#### Prompt: The "draft this thing for me" version
```
Here's everything you need:
- [Paste the data, numbers, source material]
- [Paste prior versions, last year's equivalent, or context the reader expects]
- [Paste the three things you know your audience will ask or care about]

Draft the [board paper / proposal / memo / email / one-pager] for me.
Match the tone of [the prior version / the audience's usual register].
Show me your draft first. Then I'll come back with corrections.
```

#### Prompt: The "do the analysis for me" version
```
Here's the data: [paste the spreadsheet, transcript, document, or context].

Do the analysis. Specifically:
1. Find the three most actionable patterns.
2. Tell me which one I should prioritise, and why.
3. Show your working: what you considered, what you ruled out, where your confidence is thin.

Don't ask me clarifying questions until you've given me your first answer. Then I'll come back.
```

### Build a personal skill, and add a rule to it every Sunday
*Workflow & skills*

A person I worked with this week reviews 100-page reports from their team on Sunday nights. Typos, inconsistent language, logic gaps. A simple review skill in Claude now catches all those. The compounding version is their own preferences layered on top: this market "is expected to grow" not "will grow"; never "dropping precipitously." Every time they catch a miss the model didn't, they open Claude and say "add this rule to my personal review skill." Whatever skill you build, the compounding habit is the same. Catch what the model missed. Add the rule. Trust the skill more next week.

#### Prompt: Starter review skill template
```
Role: Review the document I attach against my preferences below. Return a numbered list of suggested changes, by page number, with the recommended fix and the reason. Do NOT edit the document. The human keeps the pen.

Preferences:
- A market "is expected to grow," never "will grow."
- Avoid "dropping precipitously," "skyrocketing," "soaring."
- Cite percentages with a year and a source.
- Flag any sentence over 30 words.
- [add your own rules here as you go]

Output format:
Page N: [the issue] → [the suggested change]. [The reasoning, one sentence.]
```

#### Prompt: The compounding habit
```
Add this rule to my personal review skill: [paste the rule you just caught that the skill missed]. From now on, flag this whenever it appears in any document I send you.
```

### Schedule a daily AI briefing. The use cases will follow.
*Building*

AI tools sit closed until you open them. That's a real reason senior leaders bounce off: not bad prompts, but a tool that requires you to think of the use case first. Scheduled tasks invert this. Every morning at three, mine reads my inbox since the evening before, prepares one-paragraph briefings for every meeting on the day's calendar, and emails me a short summary that takes three minutes to read with breakfast. The tool changes from something you open to something that opens your day. Suggested time: 3am UK so the briefing is waiting when you wake. 10pm US East Coast for similar timing.

#### Prompt: The daily briefing schedule
```
Every weekday at 03:00 UK, do the following and email the result to me at [my address]:

1. Read everything in my inbox since yesterday at 18:00. Summarise the threads I'll most need to act on today, with thread links.
2. Read every meeting on my calendar for today. For each, prepare a one-paragraph briefing using:
   - The most recent email thread with the attendees (if any).
   - Any agenda or notes in the meeting description.
   - One paragraph of public news on the topic from the last 48 hours.
3. Write the whole thing as a single email I can scan in three minutes. Use bullet points sparingly.
```

## Edition 12: Choosing is the work (9th May 2026)

### Push it harder, then skillify, then iterate
*Workflow & skills*

The simplest workflow upgrade I've coached this year, and it stacks. <strong>Push it harder:</strong> when the model gives you a perfectly reasonable answer, tell it to do more searches and use credible sources. Three extra words. The next round does real research, cross-references government sources, and surfaces what the first pass skipped. <strong>Skillify it:</strong> when a session produces something useful, ask the AI to turn the exchange into a reusable skill, a folder with a description and a prompt any future session can pick up. <strong>Iterate:</strong> when the skill misbehaves, just tell it "change yourself so X." It rewrites itself in place. Works particularly well in <a href="https://claude.ai">Claude</a>, where skills are first-class.

#### Prompt: Push it harder
```
That's a draft. Now do the work properly. Run more searches. Use credible primary sources where you can find them, including government statistics, peer-reviewed papers, and reports from named firms. Cross-reference the claims that matter most. Show the sources alongside the conclusions and tell me which ones you'd trust if you had to act on this tomorrow.
```

#### Prompt: Skillify the session
```
Treat this session as raw material for a skill. Run a retrospective: what was I trying to do, what worked, what didn't, what shortcuts or guardrails would have produced a better answer faster. Then turn the retrospective into a skill: a short description that tells future sessions when to use it, and a prompt that captures the working approach. Where I made mistakes during the session that the final answer corrected for, encode those mistakes as guardrails in the prompt so the skill doesn't repeat them.
```

#### Prompt: Iterate by talking to the skill
```
Open the [skill name] skill. Ask me questions about how I'd like it to be different. Then proactively suggest ways it could be better, more reliable, bolder, or more effective, and carefully implement the ones I approve.
```

### Shadow your most AI-pilled employee for two days
*Leadership & adoption*

Most senior leaders consume AI through polished demos and vendor decks, then make strategy decisions with no felt sense of the technology's real constraints. The cheapest fix costs nothing.

<strong>Find the right person.</strong> Not the keenest, not the loudest, not the head of digital transformation. The "rabbit-holed" colleague. Signs they're the right person:
<ul><li>They use the chat tools every day, often the command-line ones</li><li>They have personal templates, skills, or context files they've built themselves</li><li>They've stopped asking AI to do the work and started asking it to check their work</li><li>They tell you specific things the model gets wrong, not general scepticism</li></ul>

<strong>Then do the same work yourself for a week.</strong> Shadowing alone is anthropology. The point is to use the tool the way they do, on your own work, for long enough that the muscle memory shifts.

#### Prompt: Questions to ask while you shadow
```
Walk me through the first thing you opened today and why.
Which AI tools and apps and settings are you using?
Show me the prompt you actually typed. Don't tidy it up.
What did the model get wrong on first pass, and how did you push back?
What did you stop doing manually three months ago that's still in my diary?
What do you wish other people would stop doing manually?
```

### Ask AI to build you an HTML slide deck instead of PowerPoint
*Building*

Just ask. "Build me a slide deck on [topic] in a single HTML file." Most chat tools can do this now. Why bother? PowerPoint output from AI is uneven, with broken chevrons, mis-rendered shapes, and two hours of touch-up. HTML slides come back closer to ready, are infinitely easier to edit (you just talk to the file), and unlock things PowerPoint can't do: an inline edit button, an AI-spoken narration, a presenter view that asks the model questions during Q and A.

The basic ask works on its own. The extras turn the deck into something people remember.

#### Prompt: The basic prompt
```
Build me a slide deck on [your topic] in a single HTML file. Sixteen-by-nine, big readable type, one idea per slide. Use Tailwind CSS via CDN for styling. Add tasteful keyboard navigation: arrow keys to advance, Esc for an overview grid, F for full screen. Include a small floating progress indicator. Serif headings, sans body, generous whitespace, no clutter. If a slide would normally have a chart, build it as inline SVG so it stays editable. End with a contents slide I can use as a hub.
```

#### Prompt: The richer prompt (with extras)
```
Same brief as above, plus:

(a) Add an "edit mode" toggle in the top right that turns every text element on the deck into a contenteditable. Changes persist in localStorage so I can refresh and keep them.

(b) Add a "speaker view" page at /speaker.html that shows the current slide, the next slide, my notes for the current slide, and a running timer. Hot keys to advance from there too.

(c) Build a "narrate" button per slide that reads the slide's notes aloud using the browser's built-in speech synthesis. Voice picker.

(d) Build a "Q and A" page that takes a typed question, looks at the deck content, and proposes an answer based only on what's in the deck. If the question is out of scope, say so honestly.

(e) Make every chart inline SVG with editable values in a small JSON block at the top of the file, so I can tweak numbers without touching the chart code.

(f) Use brand tokens in CSS variables at the top of the file. Make it trivial to recolour the deck by changing two or three values.
```

## Edition 11: The bill and the harness (2nd May 2026)

### Pick one tool, get good, then refine your harness
*Workflow & skills*

Pick one AI tool. Don't worry about which. Get fluent. Then spend the next month making it yours. That means skills, saved instructions, project context and tools it can reach. The model will keep improving on its own. The harness is your job.

A leader I spoke to has spent weeks running the same task through ChatGPT and Claude side by side, then asking each to review the other. Genuinely interesting and occasionally useful, but they can't decide which to use when. The advice from someone who has been at this longer: pick one, become very good with it, learn its quirks, then build the layer above it that reflects how you actually work. Most of the value is in fluency with one tool, not coverage across two.

#### Prompt: Build your harness
```
I use [tool name] for my work in [your field/role]. I've been using it for [time period]. Help me build the layer above the model that reflects how I actually work. Ask me:

1. What are the five tasks I do most often with AI?
2. For each, what do I wish it knew about my preferences without me telling it every time?
3. What does "good" look like for my most common output types?
4. What mistakes does the model keep making that I keep correcting?

Then write me a set of custom instructions, three reusable skill descriptions, and a project context file I can save. Make each one specific to my answers, not generic.
```

### Force yourself to change something on every AI output before you ship it
*Quality & verification*

Whatever the AI gives you, a paragraph, a slide, a summary, add something, remove something, or reorder something before it leaves your hands. Make it a rule, not a judgement call.

This came up at a senior training session, as the room debated when the "check, edit, own" model breaks down. Increasingly the edit feels optional because the output looks good. The rule of "always change something" is a forcing function. It keeps your fingerprints on the work, keeps you reading carefully enough to find the change worth making, and prevents the slow drift towards accepting output uncritically.

#### Prompt: The CEO checklist
```
Before I send this, run the CEO check (Check, Edit, Own):

1. CHECK: Read it as if a sceptical colleague wrote it. Flag any claim you can't verify, any number without a source, any assertion that sounds confident but vague.
2. EDIT: Suggest three specific changes I should make to put my fingerprints on this. Not cosmetic changes. Changes that improve the argument, sharpen the evidence, or remove something that doesn't earn its place.
3. OWN: If this went out under my name and someone challenged the weakest point, what would I say? If I can't answer that, flag it.
```

### Skip the slides, build the page
*Building*

Next time you'd reach for PowerPoint to walk a group through a framework, write the content as text and ask your model to turn it into a single HTML page instead.

In a senior strategy session this week, the most-praised artefact in the room was not a deck. It was a web page someone had built to walk teams through their thinking. Building it took a clear thought, a text file, and a small Claude skill they had set up once. Their harness paying off in front of the room.

#### Prompt: Turn a framework into a web page
```
I have a framework I want to walk a group through. Here it is:

[Paste your framework, outline, or key points]

Turn this into a single HTML page that tells the story step by step. Clean, readable design. One idea per screen section. Smooth scroll between sections. Use a serif font for headings and a sans font for body text. No clutter. If any section would benefit from a simple diagram or chart, build it as inline SVG. Make it something I'd be proud to screen-share in a meeting.
```

## Edition 10: Rise of the auditors (25th April 2026)

### Ask "is this the simplest version?" before accepting AI output
*Quality & verification*

Language models have no incentive to simplify. Work is free to them. Bryan Cantrill <a href="https://bcantrill.spicytakes.org/post/2026-04-12-the-peril-of-laziness-lost">calls it</a> the loss of "laziness": the human impulse to find the crisp abstraction rather than add another layer. When AI drafts something, check whether it found the simplest solution or the first solution. A three-step process wrapped in seven steps of hedging is worse than the three steps alone. The scarce resource now isn't production. It's restraint.

#### Prompt: The simplification test
```
Here's something I just produced with AI:

[Paste output]

Before I accept it, simplify it. Not summarise. Simplify. Find the core argument or solution buried inside it. Strip away: hedging, redundant steps, unnecessary qualifications, and anything that exists because production was free rather than because it was needed. Show me the simplest version that still does the job. Then tell me what you removed and why none of it was load-bearing.
```

### Audit cold
*Quality & verification*

When checking AI output, open a new chat with a different model. Upload the source materials and nothing else. Don't verify inside the same conversation that generated the work. That conversation will defend its own output. I've tested this repeatedly over the last month: the same model that produced a confident answer will find the errors when it reads the sources fresh, without its own prior reasoning in the context window. <a href="https://news.bloomberglaw.com/business-and-practice/sullivan-cromwell-apologizes-to-judge-for-ai-hallucinations">Sullivan and Cromwell filed hallucinated citations</a> in a multibillion-dollar bankruptcy case. This would have stopped it.

#### Prompt: The cold audit prompt
```
I need an independent review of this document. Important context: I did not write this and you did not write this. You have no stake in it being right. Read it cold.

Here are the source materials it should be based on:
[Paste sources]

Here is the document:
[Paste document]

For every factual claim: (1) is it supported by the sources? (2) does it overstate what the sources say? (3) are there gaps where the sources say something important that the document ignores? (4) are there any numbers, names, dates, or citations that don't match? Give me a numbered list of findings, ordered by severity.
```

### Save one reusable AI workflow this week
*Workflow & skills*

Google shipped Skills in Chrome this week: saved one-click AI prompt workflows that run on whatever page you're viewing. Pick a task you do weekly. Summarising a website, extracting action items from meeting notes, comparing options across open tabs. Save it as a named Skill. Whether you use Chrome, Claude, or something else, the principle is the same: if you've done it three times, encode it. Each saved workflow compounds. Each unsaved one gets reinvented from scratch.

#### Prompt: Capture a workflow as a reusable skill
```
I did [describe the task you did this week with AI]. It worked well. Help me turn it into a saved workflow I can reuse.

I need:
1. A name for it (something I'd recognise in a list)
2. A one-line description of when to use it
3. The steps as a numbered checklist
4. The prompt or prompts I should paste each time
5. Any context or inputs I need to gather before starting

Make it something I can hand to a colleague who's never done this task before.
```

## Edition 9: The proxy break (18th April 2026)

### When helping someone find AI use cases, ask what keeps them awake, not how AI can help
*Discovery & use cases*

One produces a polite, dull list. One produces a bold list of creative use cases. The difference is the question being asked. "How can AI help?" invites safe answers. "What keeps you awake at night?" surfaces real problems that happen to have AI solutions. Concrete, named, immediately applicable.

#### Prompt: Prepare a use-case discovery conversation
```
I'm about to have a one-on-one conversation with a senior leader about AI opportunities in their area. They work in [describe their role/department]. They've agreed to the meeting but I can tell they're sceptical.

Help me prepare:
1. Three opening questions that get them talking about their real frustrations at work without mentioning AI
2. A listening framework for spotting where AI maps onto what they describe
3. A way to bridge from their pain point to a concrete AI experiment they could try this week, framed as solving their problem, not as "adopting AI"
```

### Let the model research you before you write its instructions
*Workflow & skills*

I sat with a senior leader this week who is getting great results from AI despite not having filled in his custom instructions. Don't make this mistake. It helps every single response to be better for you. Rather than manually writing them, start a new chat and type the prompt below. Revisit it regularly. Most people write something generic and never look back.

#### Prompt: Self-research and write custom instructions
```
I am [your name]. I work at [your organisation] as [your role]. Search the web to learn about me, my work, my company, and my industry. Then write me a set of custom instructions I can save that would cause you to work well with me in future. Cover: my communication style preferences, the kind of work I do, the standards I hold, common tasks I'd bring to you, and any context that would make your responses more useful. Write it in second person ("You are working with..."). I'll edit it from there.
```

### Find out where your AI value actually sits
*Discovery & use cases*

Answer our <a href="https://steadman.ai/newsletters/david/ai-value-map.html">five questions</a> about where you think AI value is for your team or your organisation, then five about how much of that value you've captured so far. You get a chart showing you where the opportunities are. It's where I think most firms are: capturing about 16% of the value they can see, with almost everything still on the table.

#### Prompt: Prepare for the AI Value Map
```
Before I use the AI Value Map diagnostic, help me calibrate my thinking. I need to assess AI value across five phases for my [team/department/organisation] which does [describe work].

Ask me one question about each phase:
1. Individual productivity: the hundred small things
2. Team standards: from conversation to architecture
3. Process orchestration: "AI does the process"
4. Role and team redesign: different shape, not same people faster
5. New revenue: do different things, not the same things faster

After I answer, tell me where you think the biggest unrealised opportunity is and why. Then I'll take the full diagnostic at steadman.ai/newsletters/david/ai-value-map.html
```

## Edition 8: What a day can do (11th April 2026)

### Start with critique, not creation
*Leadership & adoption*

The brand voice skill built for a luxury goods team was deliberately limited to diagnosis: it reads copy and flags where it departs from seven writing rules. It doesn't rewrite anything yet. Teams fear the proofreader far less than the replacement. Once they trust the critique, generation follows naturally. If you're building AI tools for a team, don't start with "write this for me." Start with "tell me what's wrong with this." Nobody fights the spellchecker.

#### Prompt: Build a critique-first AI tool
```
I want to build an AI quality checker for my team's [type of work, e.g. marketing copy, client reports, proposals]. Instead of generating content, it should only critique existing work.

Help me define:
1. The 5-7 specific rules or standards our work should meet (ask me questions to surface these)
2. A prompt that reads a piece of work and flags every place it departs from these rules
3. A scoring system (e.g. how many rules are met)
4. A way to explain each flag so the person learns, not just corrects

The goal is a tool the team trusts before we ever ask it to write anything.
```

### Ask what keeps people up at night, not what they want AI to do
*Discovery & use cases*

During AI onboarding conversations, the first question ("what do you use AI for?") produces a predictable list. The second ("forget AI, what's harder than it should be?") produces the real use cases. The first question surveys existing habits. The second surfaces unmet needs. Almost nothing appears on both lists. Run them. Compare.

#### Prompt: Design a use-case discovery session
```
I'm running an AI use-case discovery session with [team/department]. I have [time available].

Help me design it:
1. Five opening questions that get people talking about what's genuinely hard about their work, without mentioning AI at all
2. Five follow-up probes that connect their pain points to AI capabilities without being leading
3. A template for capturing each use case: the problem, the current workaround, who it affects, and what "solved" would look like
4. A way to prioritise the use cases by impact and feasibility after the session
```

### Show your team how others use AI. That alone may double the impact
*Leadership & adoption*

An <a href="https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6513481">experiment with 515 startups</a> found that simply showing half of them case studies of how other startups use AI led to 44% more usage, 1.9x higher revenue, and 39% less capital needed. The friction isn't accessing the tools. It's discovering where AI creates value in your specific work. The researchers call it "the mapping problem." The intervention was cheap (case studies), the effect was large. If you manage a team, the most effective thing you might do this week isn't training. It's sharing three examples of how other teams in your industry are using AI.

#### Prompt: Create case studies for your team
```
I manage a team in [your industry/function]. I want to show them concrete examples of how other teams like ours are using AI.

Help me find and write up three case studies. For each, I need:
1. What the team does
2. What they tried with AI
3. What worked and what surprised them
4. One specific thing my team could try this week

Use real, named examples where possible. Search for recent cases. Make them specific enough to be credible, not generic "Company X increased productivity" claims.
```

## Edition 7: What is your organisation actually for? (4th April 2026)

### Before you build anything, have AI interview you first
*Discovery & use cases*

Don't describe what you want and ask AI to build it. Instead, ask the model to interview you: the prompt below. It probes edge cases, surfaces assumptions and tightens scope before a line of work begins. Many ideas aren't as clear or well thought through as you think they are. Better to discover that in a five-minute conversation than a five-hour build.

#### Prompt: The discovery interview
```
I want to build [describe your project or idea]. Before we start, interview me. Ask me every question you need answered before writing a single line of work. Cover: who this is for, what problem it solves, what "done" looks like, what constraints exist, what I've tried before, and what I'd consider a failure. Ask one question at a time. Don't start building until you've run out of questions.
```

### Before you analyse anything, ask AI what looks weird
*Discovery & use cases*

Next time someone sends you a spreadsheet, a report or a set of financials, upload it and ask AI what looks unusual. I coached a finance professional this week who receives portfolio company P&Ls regularly. Before she even opens the numbers now, AI flags the things worth checking: an unusually high margin, a budget assumption that changed between the original and revised forecast, a line item that doesn't match the pattern. Five or six flags in thirty seconds. She still does the analysis. But she starts it knowing where best to look.

#### Prompt: The anomaly scan
```
Here's a [spreadsheet/report/set of financials/dataset]:

[Paste or upload your data]

Before I start my analysis, read it and tell me what looks unusual. Flag: unexpected patterns, numbers that don't match, assumptions that seem wrong, anything that breaks from the trend, and anything you'd want to double-check if you were the person signing off on this. Give me 5-8 flags, ranked by how much they'd change the conclusions if they turned out to be wrong.
```

### Don't build an app. Let AI be the app
*Building*

I coached a person this week who wanted to build a web application for an investment screening workflow. The build was simpler than they expected: rebuild the process as a repeatable skill inside an AI tool instead of building it as a standalone app. The AI itself becomes the application. The advantage is resilience: if the input format is wrong or a step fails, the AI adapts on the fly. A standalone app just stops. If you have a multi-step workflow you keep wishing someone would build software for, try describing it to your AI tool and asking it to turn the process into something you can re-run with one command.

#### Prompt: Turn a workflow into a skill
```
I have a multi-step workflow I keep doing manually:

[Describe the workflow step by step]

Instead of building software for this, convert it into a set of instructions, decision rules, and output templates that I can invoke with a single phrase like "run the [name] workflow".

Include:
1. What inputs it needs from me each time
2. What decisions it makes automatically
3. Where it should pause and ask me
4. What the output format looks like
5. How to handle edge cases (wrong input format, missing data, ambiguous results)
```

## Edition 6: The system and the surrender (28th March 2026)

### Don't fact-check AI in the same conversation
*Quality & verification*

In a single chat, the model has its full reasoning chain in context and will tend to defend its conclusions when challenged. Start a fresh conversation, upload the same source materials, and prompt it to critique the output cold. I've started doing this for every high-stakes document. The independent perspective is materially more likely to find gaps. A false sense of verification is worse than no verification at all.

#### Prompt: The cold fact-check
```
I need you to fact-check this document. Important: I did NOT write this and you did NOT write this. Read it cold.

Here are the source materials it should be based on:
[Paste sources]

Here is the document:
[Paste document]

For every factual claim in the document: (1) verify it against the sources, (2) flag anything stated as fact that isn't in the sources, (3) flag any numbers that don't match, (4) flag any claims that go beyond what the sources support. Be suspicious. Your job is to find what's wrong, not confirm what's right.
```

### Give your AI reviewer a persona with skin in the game
*Quality & verification*

Asking a language model to "check this for errors" produces generic feedback. Assigning it a specific sceptical expert persona, someone with domain expertise and institutional incentives to be unimpressed, produces something qualitatively different. I ran a quality-control pipeline this week where six review agents were given a senior partner persona. All six independently converged on the same systematic error class that a neutral reviewer had missed. The persona defines what "good" looks like. A generic prompt doesn't.

#### Prompt: The persona review prompt
```
You are [name and role, e.g. "Sarah Chen, CFO of a FTSE 250 company"]. You have [describe their experience and what they care about]. You are known for [describe their reputation, e.g. "asking the question nobody wants to answer"]. You are reading this document because [reason].

Read it now and give your honest, unfiltered reaction:
1. What would you challenge in the next board meeting?
2. What would you praise?
3. What would make you worried?
4. What's missing that someone in your position would expect to see?

Write your response in first person, in character. Don't break character.
```

### After every good session, turn it into a reusable skill
*Workflow & skills*

When you've just completed a task you're pleased with, ask the model to turn it into a set of instructions, templates and process steps it can invoke next time with a single phrase. The law firm partner's 2,000-word prompt didn't happen in a flash of inspiration. It was built through iteration. Capturing what "good" looks like the moment you've achieved it, before the memory fades, turns a one-off win into a standing procedure. The output matters today. The instructions compound forever.

#### Prompt: The skill capture prompt
```
I just had a productive session. We did [describe what you accomplished]. The result was [describe the quality of the output].

Run a retrospective:
1. What was I actually trying to do?
2. What approach worked?
3. What went wrong or took too long?
4. What shortcuts or guardrails would have produced a better answer faster?

Then turn this into a reusable skill: a short description that tells future sessions when to use it, and a prompt that captures the working approach. Where I made mistakes during the session that the final answer corrected for, encode those mistakes as guardrails so the skill doesn't repeat them.
```

## Edition 5: Reckoning and slope (21st March 2026)

### Mine your own email archive
*Personal practice*

Before writing a strategy document this week, I pulled 31 emails between myself and a client from the past six months and asked Claude to compress them into a structured set of questions and insights. Scattered observations, early instincts, half-formed frameworks: they became a clear argument in minutes. The emails already contained all the thinking. They just needed synthesising. Pick a topic you've been emailing about for months. You'll find you've already done more thinking than you realised.

#### Prompt: Synthesise an email thread
```
Here are [number] emails between myself and [person/team] over the past [timeframe] about [topic]:

[Paste emails]

Don't summarise them chronologically. Instead:
1. What is the core question or problem that runs through all of these?
2. What positions or instincts appeared early that turned out to be right?
3. What assumptions shifted over the exchange?
4. What remains unresolved?
5. Compress the entire exchange into a structured brief: the question, the evidence, the options, and the recommended next step.
```

### End every AI session the way a developer commits code
*Workflow & skills*

Close each working session with one line: the prompt below. Without it, context evaporates and the next session starts from scratch. With it, the session becomes a self-contained unit of work that can be picked up, forked or handed off. It sounds small. The cost of not doing it only becomes visible the next time you open the conversation.

#### Prompt: The session commit
```
We're finishing this session. Before we close, document everything someone picking this up tomorrow would need:

1. What we were trying to do
2. What we decided
3. What we built or produced
4. What's still unfinished
5. What I should ask you to do first next time
6. Any files, links, or context that would be needed

Write it so a future session could resume this task without asking me to repeat anything.
```

### Use AI to teach you, not just to do things for you
*Personal practice*

Bloom's two-sigma result is the best-known finding in education research: one-to-one tutoring consistently moves students from the 50th to the 98th percentile. It's never been economically available except to the very wealthy. It now costs a monthly subscription. Pick one skill you want to add and spend twenty minutes a day asking AI to train you in it: run you through drills, quiz you, critique your answers. Most people use these tools to produce output. The people I know that impress me most are using them to produce understanding.

#### Prompt: Start a personal tutoring programme
```
I want to learn [skill]. I'm currently at [describe your level]. My goal is to be able to [describe what competence looks like].

Act as my tutor. Start with a diagnostic: ask me 5 questions to understand what I already know and where my gaps are. Then design a 20-minute daily drill I can do for the next two weeks. After each session, quiz me, critique my answers, and adjust the difficulty. Be demanding. I'd rather struggle and learn than coast and feel good.
```

## Edition 4: The power and the care (14th March 2026)

### Before you send AI work to anyone, simulate the toughest person who will read it
*Quality & verification*

An advisory team I work with creates AI versions of each board member, based on known priorities and past questions, and runs every document past these simulated reviewers before a human sees it. The virtual panel flags objections, tests assumptions and catches blind spots. The cost is an hour of AI time. The benefit is walking into the meeting having already rehearsed the hard questions.

#### Prompt: Simulate a tough reader
```
I'm about to send this document to [describe the audience, e.g. "our board", "a sceptical client", "a senior partner"].

Before I do, simulate the toughest person who'll read it. Their profile: [describe them, e.g. "a private equity partner who has seen hundreds of these, values brevity, hates jargon, and will immediately check the numbers"].

Read my document as that person. Give me:
1. The three questions they'll ask first
2. The two weakest claims they'll challenge
3. Anything they'll find patronising or obvious
4. The one thing that might genuinely impress them

Here's the document:
[Paste document]
```

### Delete the headline. Ask AI what it should be
*Quality & verification*

A manager at a training session showed me a quality check I hadn't seen before. He copies a colleague's slide, removes the headline and asks the language model what the headline should be based on the content alone. If the model's headline differs substantially from what the colleague wrote, it reveals a disconnect between what the slide says and what the person intended. A ten-second test that catches the gap between the message you're claiming and the evidence you're showing.

#### Prompt: The headline test
```
Here's a slide with the headline removed:

[Paste slide content without the headline]

Based only on the content, what should the headline be? Give me three options:
1. One that summarises the data
2. One that makes a recommendation
3. One that tells the audience what to do next

Then tell me: if the original headline was "[paste original headline]", does it match what the slide actually says? If not, what's the disconnect?
```

### Fix the instructions, not just the output
*Workflow & skills*

When AI produces a mistake, most people correct it and move on. The fix disappears with the conversation. After every session where the result misses the mark, update the instructions that generated it: the custom instructions, the project brief, the context files. Every failure becomes a permanent improvement. The output matters today. The instructions compound forever.

#### Prompt: Diagnose and fix the root cause
```
I just finished a session where the AI got [describe what went wrong]. The output I wanted was [describe]. The output I got was [describe].

Here are the instructions I gave it:
[Paste your custom instructions or project context]

Diagnose why the instructions produced the wrong output. Then rewrite the instructions so this specific failure can't happen again. Show me exactly what you changed and why.
```

## Edition 3: Extraction or expansion (7th March 2026)

### Run AI and a human on the same task, then focus on the disagreements
*Quality & verification*

A manager this week ran the same research brief through both AI and a human team. The overlap was 78%. But the value wasn't in the overlap. It was at the edges: the surprising findings that only one method surfaced. Where human and machine agreed, the team moved fast with confidence. Where they disagreed, they'd found the questions worth investigating. The delta between AI output and human output is where insight lives. Try it on your next research task, competitive scan, or document review.

#### Prompt: Run the comparison test
```
I'm running a comparison test. I gave the same research brief to both a human analyst and an AI tool.

Here is the human output:
[Paste human output]

Here is the AI output:
[Paste AI output]

Don't tell me which is better overall. Instead:
1. List every point where they agree
2. List every point where they disagree or one found something the other missed
3. For each disagreement, tell me which source is more likely to be right and why
4. Identify the three most valuable insights that only appeared in one output

Those disagreements are where I should focus my attention.
```

### Know where your organisation sits on the AI tools landscape
*Leadership & adoption*

I've put together a short page mapping what I think of as Generation 1 versus Generation 2 AI tools, and why the distinction matters for how you invest in your people. The short version: many organisations are still stuck on constrained, default tools and most don't have anyone on Agentic / Frontier Generation 2 tools. I see two strategies working in parallel. For the many: move less-engaged people from free, constrained tools to competent use of good general-purpose applications. For the best: accelerate your top people with agentic, frontier tools and let them build entire workflows that deliver outsized impact. <a href="https://steadman.ai/newsletters/david/gen1-vs-gen2.html">See the full explainer.</a>

## Edition 2: The hundred small things (28th February 2026)

### Run your day through AI at six in the evening
*Personal practice*

At the end of each day, take whatever you captured (meeting notes, voice recordings, emails) and ask Claude for a five-paragraph reflection. Not a summary. A reflection. I've been doing this daily for months. The output compounds. You start noticing patterns you'd never have seen without the habit. The raw material is irreducibly yours. AI helps you see the shape of it.

#### Prompt: The evening reflection
```
Here are my notes, voice recordings, and emails from today:

[Paste content]

Don't summarise them. Reflect on them. Write five paragraphs:
1. What the day was actually about (not what was scheduled)
2. What patterns you notice across the different activities
3. What I seem to be avoiding or postponing
4. What surprised you
5. One question I should sit with overnight
```

### Before you build training, check the settings menu
*Leadership & adoption*

Most people never change the default model on AI platforms. Before investing in an elaborate training programme, walk up to five people in your organisation and ask two questions: which AI model are you using, and have you changed anything in the settings? The answers will tell you more about your organisation's AI maturity than any survey. If your people haven't opened the settings menu, the barrier isn't skill. It's something simpler: nobody showed them it was there.

#### Prompt: The quick AI maturity audit
```
I'm about to design an AI training programme for my team of [number] people in [function/industry]. Before I do, help me build a quick audit.

Write me a 5-question survey I can ask face-to-face (not email). The questions should surface:
1. Which AI tools they use and which model
2. Whether they've changed any settings or written custom instructions
3. Whether they've saved any reusable workflows or skills
4. What their biggest frustration is with AI tools
5. One task they wish AI could do but haven't figured out how

Make the questions feel like a casual conversation, not an audit. Then tell me how to interpret the answers: what do the patterns reveal about where training should focus?
```

### Push record. Think aloud. Send it to AI
*Personal practice*

When someone has stories they want to capture but can't easily write, skip the blank page. Push record while doing actual work. Don't write, don't perform, just think aloud. Send the raw recording to a transcription tool, then run the transcript through Claude. The stories that would otherwise stay untold (because the effort of writing them was too high) get captured without friction. I've seen this work for client case studies, internal knowledge sharing, and personal reflection. The raw material is human. The refinement is machine. That's the order that works.

#### Prompt: Process a raw voice transcript
```
Here's a raw transcript of me thinking aloud about [topic]:

[Paste transcript]

This isn't polished. It's me working through ideas in real time.

1. Extract the core argument
2. Identify the three strongest points and the two weakest
3. Restructure it into something I could share with a colleague
4. Keep my voice. Don't make it sound like a report
5. Flag anything where I contradicted myself or where my reasoning has a gap I should fill
```

## Edition 1: The wonder and the weight (22nd February 2026)

### Find your misfits (and back them)
*Leadership & adoption*

Identify the one-in-ten people in your organisation who are already at the forefront of using AI. The ones who experiment on their own time, who volunteer for pilots, who can't stop showing colleagues what they've built. Free them from at least some of their existing reporting lines. Give them the best tools. Bring them together, give them a name, give them a mandate to have an impact beyond their old job description. Most training programmes spread investment evenly. I don't think that's right. Your top ten percent will generate eighty percent of the value. A power user with the right support can transform a team. A reluctant user with mandatory training may forget everything by Thursday.

#### Prompt: Identify your power users
```
I lead [describe your team/organisation] with [number] people. I want to identify the top 10% who are furthest ahead with AI: the ones who experiment on their own, volunteer for pilots, and can't stop showing colleagues what they've built.

Help me design a simple 5-question diagnostic I can use in a team meeting or 1:1 to surface who they are without making anyone feel singled out. Then suggest three concrete things I could do in the next two weeks to:
1. Free these people from at least some of their existing reporting lines
2. Give them the best available AI tools
3. Give them a mandate to have impact beyond their old job description
```

### Open Claude Code and build something
*Building*

Just build something. Pick a website you wish existed, or some data you wish was gathered across the web. Or an email scanning automation that summarises stuff for you on a schedule. Or an app that lets you do something you've been meaning to do. The only blocker is your imagination (plus a subscription to Claude, ten minutes of setup and 30 minutes of playing!). Claude will hold your hand through every single step. Just ask if you don't understand. Within 30 minutes you'll have something working and your perspective will have changed. There's a difference between knowing what's possible and doing it yourself. Go do it.

#### Prompt: Your first build
```
I've never built anything with code before. I work in [your field]. I want to build [describe the thing you wish existed: a website, a tool, an automation, a dashboard].

Walk me through every single step from scratch. Assume I know nothing about terminals, code, or deployment. Hold my hand. If I don't understand something, I'll ask. Start with what I need to install and set up.
```

### Measure outcomes, not logins
*Leadership & adoption*

Accenture now <a href="https://www.cnbc.com/2026/02/19/accenture-ai-orders-senior-staff-lose-out-promotions.html">tracks weekly AI tool logins</a> for senior staff and links them to promotion decisions. The internal reaction? Staff call the tools "broken slop generators." Measuring whether people opened the app tells you nothing about whether the work got better. If you're going to track AI adoption, track the outcomes: did quality improve? Did turnaround times fall? Did clients notice? Log-in counts measure compliance. It's easy but lazy. Measure capability, instead.

#### Prompt: Design an outcome-based measurement framework
```
My organisation currently tracks AI adoption by [how you measure it, e.g. licence usage, login counts, tool access rates]. I want to measure whether AI is actually making our work better, not just whether people are opening the app.

My team does [describe the work]. Propose 5 outcome metrics I could track monthly, each with:
1. What to measure
2. How to measure it (data source, method)
3. A one-sentence rationale for why it's better than a login count
4. What "good" looks like after 3 months

Keep it practical. I need things I can start measuring this week, not a six-month data infrastructure project.
```
