Good morning.
When you subscribe to this newsletter, I ask you one question:
What's the one repetitive task eating your week? I read every answer, and lately they've been better than anything I could have picked on my own.
Today you get eleven of those jobs, in the words the people who do them used, each with a complete prompt that takes it off your desk. Steal whichever ones match your week.
— Sam
IN TODAY’S ISSUE 🤖
The job two readers named without being asked
Turning coworkers' PDFs into spreadsheet rows
Writing invoices when your software has no connector
Running the day from inbox and calendar
Meeting notes in your format, not the model's
Long files into a report you can send
Holding several client voices at once
Which of your own files you still use
Giving scattered data one place to live
Slides that come out built right
Checking a claim against its source
Where These Came From
Every question below is something a reader wrote to me, unprompted, about their own week.
I've kept their words rather than tidying them, because the phrasing is half the information. "Manually updating spreadsheets from information I receive from coworkers" tells you more about the job than any category label would.
A note on how to use the prompts. Each one is complete and runnable as written, and each has one or two bracketed fields where your own specifics go.
The reasoning underneath each is worth more than the text, so I've said why each is built the way it is. Change them to fit your work. That's the point.
Each of these could easily be turned into Skills and/or Plugins, too.
Chasing What's Waiting On A Reply
"One insanely repetitive task that I work with is tracking correspondence that needs a reply. Then one follow up just in case they missed the email then of still no reply escalate to executive team. I send a lot of these on a daily basis and tracking them takes a huge chunk of my day just to review and figure out if a response came in."
"Definitely keeping track of tasks that need action including follow up."
Two readers named this without knowing the other had. It's the most common job in my inbox and I've never written about it, which tells you something about how invisible it is.
The work isn't sending the follow-up. It's holding the open loops in your head and re-checking them, which is a job that expands to fill whatever attention you give it.
Read my sent messages from the last [14] days and my received messages over the same period. Build a list of every message I sent that asked for something (a reply, a decision, a document, an approval) and has not received a substantive response.
For each open item give me: who I asked, what I asked for, the date I asked, how many days have passed, and whether anything came back that partially answers it. Treat an out-of-office, a "will look at this" holding reply, or an acknowledgment with no answer as still open, and say which of those it was.
Sort by days elapsed. Then split the list into three groups using these thresholds: NUDGE for anything open past [4] days, SECOND ASK for anything past [8] days that I have already nudged once, and ESCALATE for anything past [14] days on the items I have marked as time-bound below.
For each item in NUDGE and SECOND ASK, draft the follow-up message. Keep it under four sentences, reference the original ask specifically enough that they don't have to search for it, and make it easy to answer in one line. Do not apologise for following up and do not add pressure.
Do not send anything. Output the list and the drafts for me to approve.
Time-bound items: [name the kinds of request where a delay costs you something: contract signatures, client approvals blocking delivery, anything with an external deadline]The thresholds are the part to tune. Mine are 4, 8 and 14 days, and they're wrong for a business where a two-day silence is a problem. Set them from what happens in your work, and revisit them once you've watched the list for a fortnight.
The instruction that saves the most time is the one about holding replies. "Will look at this tomorrow" reads as a response to most filters and it's exactly the item you'll lose.
Turning PDFs Into Spreadsheet Rows
"Manually updating spreadsheets from information I receive from coworkers. Usually in the form of PDFs"
A reader running a consulting business described the same job with a harder input: "Bill of Materials (BOM) to supplier parts and price lists, all manner of formats."
The failure here shows up late. A model reading a stack of PDFs will produce a clean-looking table with three values wrong, and a clean-looking table is exactly the thing nobody re-checks.
Read the attached documents and extract the following fields into a table, one row per [record type, e.g. line item, invoice, supplier quote]: [list your columns exactly as they appear in your spreadsheet, in the order they appear].
Rules for the extraction. Take values exactly as printed, including their units and currency, and do not convert, round or normalise anything. Where a document uses a different label for one of my columns, map it and tell me which label you mapped. Where a field is missing from a document, write MISSING rather than inferring it from the other rows or from a similar document.
Where a value is ambiguous, unreadable, or appears more than once with different values, write CHECK followed by the reason and the page number, and do not pick one.
After the table, give me three things: a count of rows extracted per source document, a list of every MISSING cell with its row and column, and a list of every CHECK with what made it ambiguous.
Output the table as CSV so I can paste it straight in.MISSING and CHECK are the whole build. Without them you get a full table and no way to tell which cells were read and which were guessed, and the guessing is invisible until a number is wrong in a meeting.
Run it on five documents you've already entered by hand and compare, before you trust it on fifty.
Writing Invoices Without An Integration
"My next thing is to come up with an automation or project to write invoices for my services, I hate doing that. Not all my software has MCPs so I'd need to give dates and service and customer, and make something branded, from a pricing table."
This reader named the constraint most people hit and few say out loud. Not everything you use has a connector, and the answer has to work anyway.
It does, because an invoice is a document assembled from a rate card and a list of what happened. Give the model both and it produces the document; you keep the sending.
Generate an invoice from the details below, using my rate card and my standard format.
Work performed: [paste dates, client, and what was delivered, in whatever rough form you have it. Bullet notes are fine.]
Rate card:
[paste your pricing table: service name, unit, rate, and any minimums or rounding rules]
Invoice format:
[paste your business name, address, payment terms, payment details, and invoice number scheme]
Build the invoice as a table with one line per billable item: description, quantity or hours, unit rate, line total. Apply my rounding and minimum rules exactly as written. Calculate the subtotal, any tax at [rate], and the total.
Where the work notes describe something my rate card doesn't cover, do not invent a price. List it separately under NEEDS A RATE with a note on what it appears to be, and leave it out of the total.
Where the work notes are too vague to bill from (no date, no clear deliverable), list it under NEEDS DETAIL rather than writing a line item that a client would query.
Output the invoice as markdown I can paste into my template, and give me the next invoice number in my scheme.Never let it price something the rate card doesn't cover. An invented line item on an invoice is worse than a missing one, because a client who queries a price they don't recognise starts checking the rest of the invoice.
Once the format holds for two or three rounds, save the rate card and the format block as a skill and the whole job becomes one line.
Running The Day From Inbox And Calendar
"I'm trying to line out a daily email and schedule manager."
Another reader wanted "an executive assistant of sorts," and a third wanted the model to "take what I give it and schedule everything with links and whatnot."
What most people build here is a summary, and a summary of your inbox is something you have to read on top of your inbox. The version worth having produces decisions rather than descriptions.
Read my calendar for today and tomorrow, and my unread and flagged mail from the last [24] hours. Produce my desk for the day in this order.
FIRST: anything that will go wrong today if I don't touch it. A meeting I have not prepared for, a deadline landing today, a message where someone is blocked waiting on me. Say what it is and what the specific next action is, in one line each.
SECOND: my meetings today, each with the one thing I need in hand before it starts, drawn from the thread or document it relates to. If I have nothing to prepare, say so rather than inventing preparation.
THIRD: messages that need a reply from me today, with a one-line draft response for each. Group anything that needs a decision rather than a reply separately, and state the decision.
FOURTH: what I can safely ignore until [tomorrow / this week], listed in one line as a group rather than itemised.
Rules. Do not summarise my inbox; sort it. Anything you cannot resolve from what you can read, put under NEEDS ME with the specific question. Keep the whole thing under one screen. If today is light, say so and keep it short rather than padding it to look thorough.The fourth section is the one people cut and the one that does the most work. A list of what you're allowed to not think about today is the difference between a briefing and a to-do list that grows.
If you're burning through your plan on a run like this, it's reading too much. Narrow the window to unread and flagged rather than everything, and cut the lookback to a day.
Meeting Notes In Your Own Format
"Making Meeting Notes (the way I like them)."
That parenthesis is the entire problem. Every tool makes meeting notes. None of them makes yours, and the gap between a generic summary and your format is a rewrite that costs about as much as taking the notes did.
The fix is to stop describing the format and show it.
Turn the transcript below into meeting notes matching my format exactly.
Here is an example of notes I wrote myself, which is the format to match:
[paste one full set of notes you made by hand, from a real meeting. One is enough. Two is better.]
Match its structure, its section order, its level of detail, and the kinds of thing it records against the kinds it leaves out. Match how it writes decisions and how it writes actions, including whether it names people and how it handles dates.
Where the transcript contains something my example format has no place for, leave it out rather than adding a section.
Where an action item has no named owner or no date in the transcript, write it with OWNER? or DATE? rather than assigning one.
Transcript:
[paste]One real example beats a page of description, because your format carries decisions you've never articulated: whether you record who said what, whether you keep the argument or only the conclusion, how much context a future reader gets. You can't specify those. You can show them.
The OWNER? and DATE? markers exist because a model asked for action items will invent an owner, and a wrong owner in circulated notes creates work rather than saving it.
Long Files Into A Report You Can Send
A reader who writes assessment reports from long case files told me the analysis is the bottleneck: "I would like to write the reports faster and have the [case] file analyzed much much more quickly."
The general job is common: a thick pile of source material, a report with a fixed shape, and questions that have to be answered from what's in the pile and nothing else.
Read the attached file and draft a report answering the questions listed below, in my standard report structure.
Report structure:
[paste your section headings in order, with a line on what belongs in each]
Questions the report must answer:
[list them, numbered, exactly as they are put to you]
Rules. Answer only from the attached material. For every factual claim, cite the page or section it came from. Where the material does not contain what a question needs, write NOT IN FILE under that question and state what would be needed to answer it, rather than reasoning toward a likely answer.
Where the material contains a contradiction, present both, cite both, and do not resolve it.
Mark anything that is your inference rather than a statement in the file with INFERRED at the start of the sentence, so I can check those first.
Draft in my structure, at the length the material supports rather than a target length.The INFERRED marker is what makes this usable in work where being wrong matters. A report where the reasoning and the sourced facts look identical has to be checked line by line, which costs what the draft saved.
Anything involving confidential files needs a look at where your model runs and what its data terms are before this leaves an experiment.
Holding Several Client Voices At Once
"I could take on more clients if I had a system to automate each business' voice. I want to be able to sit down and come up with ideas and write because I have each person's information in a skill that I can go to when I need to get work done."
"I have multiple clients and can't spend dozens of hours of training and testing."
Writing in one voice that isn't yours is a solved problem. Writing in six is a filing problem, and it's the one that caps how many clients you can carry.
The answer is one file per client, in a fixed shape, so the setup cost falls with each one you add.
Build a voice profile for this client from the material below, in exactly the structure given, so I can store it and load it whenever I write for them.
Client material:
[paste 3 to 5 pieces they have published or approved: emails, posts, pages, anything in their real voice]
Produce the profile with these four sections and nothing else.
MECHANICS: sentence length and variation, paragraph length, punctuation habits, formatting habits, how they handle lists and emphasis. Be specific enough that following it changes what I write.
LEXICON: words and phrases they use often, with examples. Then words they never use, inferred from what is conspicuously absent given their subject.
STANCE: what they are confident about, what they hedge, who they position themselves against, what they refuse to claim.
BANNED: anything in the material suggesting they would never say it. If the material does not support a banned list, write NONE OBSERVED rather than guessing at one.
Keep the whole profile under one page. Where the material is too thin to support a section, say which section and what else you would need.Save each as voice-[client].md. Then writing is that file plus a brief.
The one-page cap matters more than it looks. A four-page voice profile stops being loaded, and a profile nobody loads is a profile that doesn't exist.
Knowing Which Of Your Files You Still Use
"Keeping track of knowledge documents, system instructions etc so that I know what I'm using and what's effective."
Two other readers described the same drift: "Uploading all the right knowledge files" and building context files "that make up a knowledge base that is workable for most AI flavors."
Anybody past their third or fourth skill has this. You accumulate context files, project instructions and saved prompts faster than you retire them, and after a few months you can't say which are load-bearing.
Read every file in [folder / project] and produce an inventory.
For each file give me: its name, what job it does in one line, what it would be loaded alongside, and when it was last changed.
Then group them. ACTIVE for files that a workflow I run regularly depends on. STALE for files that describe a tool, price, process or person that has changed since the file was written, naming what has changed. DUPLICATE for files that overlap another by more than about half, naming the pair and which is more current. ORPHAN for files nothing appears to load.
For every STALE and DUPLICATE, tell me the specific edit or merge, not just that one is needed.
Where you cannot tell whether a file is used, say so and put it under UNKNOWN rather than guessing. Do not delete or edit anything.Run it quarterly. The ORPHAN group is usually the surprise, and it's usually where the failed experiments live.
Giving Scattered Data One Place To Live
"having tons of programs/touch points that are not connected such as acuity having appointment information and stripe having payment but no CRM having all the data."
This reader has diagnosed it precisely. The data exists, it's accurate, and there's nowhere that holds it together, so every question spanning two systems becomes a manual reconciliation.
Building the missing system is a project. Answering the question is an afternoon, and it's worth knowing which one you need.
I need to answer questions that span two systems that don't talk to each other.
System A holds: [what it is, and the fields you can export]
System B holds: [same]
They can be matched on: [the field that appears in both: email, name, order ID]
Build me a single reconciled table joining them on that field, and tell me the join quality first: how many records matched, how many exist in A only, how many in B only, and what the most common reason for a non-match looks like.
Do not drop unmatched records. Keep them with the missing columns empty so I can see what fell out.
Then answer these questions from the reconciled table: [list the two or three questions you keep needing to answer manually]
For each answer, state how many records it rests on and whether unmatched records could change it.Look at the join quality before the answers. A 60% match rate produces answers that read as confident and describe a fraction of your business, and the match rate is the first thing a spreadsheet hides.
If you find yourself running this monthly, that's the signal that the missing system is worth building.
Slides That Come Out Built Right
"I've learned it can create PowerPoint Files, but I'm having trouble getting it to set up each slide correctly."
A second reader wanted to "quickly create proposals based on what we discussed" and a solid deck from the same material.
Decks come out wrong because a deck is two jobs, and asking for both at once gets you neither. Separate the argument from the layout and both improve.
FIRST PASS, no slides yet.
From the material below, give me the argument of this deck as a numbered list of claims, in the order a [audience] needs to hear them. One line each. For each claim, name the single piece of evidence from the material that supports it, and flag any claim the material does not support.
Material:
[paste]
Stop there. Do not produce slides.Then, once the argument holds:
SECOND PASS. Build the deck from the approved claim list.
One slide per claim. Each slide gets: a headline that states the claim as a full sentence rather than a topic label, at most three supporting lines, and a note naming the one visual that would carry it.
Where a claim needs two slides, split it and say why. Where two claims belong on one slide, merge them and say why.
Do not write a slide for anything not on the approved list, and do not add an agenda, a thank-you, or a questions slide.The headline rule does more than anything else in either prompt. "Q3 Results" is a topic and the reader waits for you to explain it. "Q3 margin recovered on pricing, not volume" is a claim and the slide already worked.
Checking A Claim Against Its Source
"Fact checking"
"I use GPT to research topics for my email newsletter and to verify data. It starts as a quick 5 minute prompt more often than not ends up in a 30+ minute back and forth."
The spiral this reader describes comes from asking one question that contains three. Is the claim true, does the source say what I think, and is the source any good.
Check the claims in the text below, one at a time.
Text:
[paste]
First, list every checkable factual claim it makes. A checkable claim states something verifiable: a number, a date, an attribution, an event, a causal statement. Opinions, predictions and value judgments are not checkable, so list those separately and leave them alone.
Then, for each checkable claim, tell me four things. What the claim says, precisely. Whether the cited source (if any) supports it, contradicts it, or says something adjacent that has been stretched. What the original source is, if the text is citing something that cites something else. And how confident you are, with the reason.
Where you cannot verify a claim, say UNVERIFIED and name what would settle it. Do not fill the gap with what is likely true.
Flag separately any claim that is technically accurate and misleading in context, and say what context is missing.
Do not rewrite the text. I want the check, not a corrected version.The last line stops the spiral. Ask for a check and a fix in one go and you get a rewritten passage with the errors corrected in place and no record of what was wrong, which means you learn nothing and can't verify the corrections either.
The "adjacent but stretched" category catches the most common failure in anything researched quickly, which is a real source cited for a claim slightly bigger than it makes.
The Answer I Didn't Write
The most common thing readers named isn't in this issue, and it should be said rather than left out.
Eleven of you described some version of content creation and posting across channels. Turning one piece into a week of them, getting the brand voice right, filling several platforms without it eating the week.
I've written that three times and the honest answer is that I don't have a fourth angle worth your attention. The prompts in those issues still work and nothing has changed enough to justify a rerun. If a fourth version turns up in your inbox from me, it'll be because something moved, not because it's the thing most people asked for.
That's the arrangement I'd want from a newsletter I read, so it's the one I'll keep.
Last Byte
The two readers who described the follow-up job had no idea the other existed, and neither of them called it a system problem.
They both called it something they were good at, which is what a job becomes when you've absorbed it for long enough to stop noticing the cost.
The one to look for in your own week is the task you're proud of handling well, rather than the one you complain about.
Hit reply and tell me what's eating your week. I read every one, and it's where the next issue like this comes from.
Talk soon,
Sam Woods
The Editor
