Prompting Guide
How to Prompt Claude to Write a Weekly Status Update
The update isn't the hard part. Deciding what's worth saying is.
Anthropic's Claude can turn a messy pile of notes, tickets, and half-finished thoughts into a status update that reads like you sat down and thought it through. It can't do that from a one-line request, though, and a one-line request is what most people type: "write my status update" and then paste in whatever they have lying around. The gap between a vague prompt and a useful one is almost always the same four things, and once you see the pattern, a weekly status update takes about as long to prompt for as it takes to drink a cup of coffee.
To prompt Claude for a weekly status update, give it four things in one message: the context (what the project is and who's reading this), the task (write a status update, not a summary or a list), the format (sections like Done, In Progress, Blockers, Next, and a rough length), and what to check before you send it (did it flatten anything that still needs a decision, did it bury the one thing your manager actually needs to know). Paste your raw notes, tickets, or messages underneath, and ask Claude to draft from those instead of inventing specifics.
Published
Free lesson · no account neededMeet ClaudeWhy Claude?6 minStart the free lessonTry it with your own status updatePaste your notes in and get a structured draft back in seconds, free, no account needed.Try it freeKey Takeaways
- A status update prompt needs four parts: context (who reads this and why), task (status update, specifically), format (the sections and rough length you want), and checking (what you'll verify before sending).
- Paste your actual notes, ticket titles, or Slack messages into the prompt. Claude should organize what you did, not guess at what you might have done.
- Name the reader. "For my manager" and "for the whole team" produce different updates, and Claude can't tell which one you want unless you say.
- Ask Claude to flag anything it had to guess or infer, so a filled-in placeholder doesn't quietly become a false claim in the version you send.
- A first draft from Claude is a draft. Read it against your actual week before it goes out, especially anything about a blocker, a date, or a number.
Copy and Paste
Prompts You Can Use Today
A full weekly status update from raw notes
I need a weekly status update for my manager, covering the backend migration project. Here are my raw notes from the week: [paste your notes, tickets, or Slack messages here]. Write it in four sections: Done, In Progress, Blockers, and Next Week. Keep each section to 2-4 short bullet points, written in plain language, not jargon. If anything in my notes is ambiguous or you have to guess at a detail, mark it clearly instead of stating it as fact.
Replace the bracketed notes with whatever you actually have: a bullet list, copied ticket titles, or a few lines you jotted during the week.
A short version for a busy executive
Turn this status update into a 4-sentence version for an executive who has 30 seconds and only cares about risk and timeline: [paste your longer update or notes here]. Lead with whether the project is on track, behind, or ahead. Mention a blocker only if it could change the delivery date. Cut everything else.
Use this after you already have a fuller update, when the same week's news needs a shorter version for a different reader.
Turning a rough brain dump into Done / In Progress / Blockers
Here's an unsorted list of everything that happened this week on my project, in no particular order: [paste the list]. Sort it into Done, In Progress, and Blockers. If something could belong in more than one section, put it in the one that matters more to someone deciding whether to help me. Do not add anything I didn't mention.
Good for the week where you didn't track anything neatly and just have a jumble of half-sentences to work from.
Checking a draft before you send it
Read this status update draft and tell me: is there anything here that sounds more finished or more certain than it actually is, based on these raw notes: [paste your original notes]. Also tell me if there's a decision buried in here that a reader might miss because it's phrased as a status line instead of a question.
Run this on Claude's own draft, or on one you wrote yourself, before it goes to your manager.
A status update that leads with the one thing that matters
Before you write the full update, tell me in one sentence what the single most important thing is that my manager needs to know this week, based on these notes: [paste your notes]. Then write the full status update, but make sure that one thing is the first line, not buried in a bullet list further down.
Useful when one blocker or decision matters more than the rest of the week combined, and you want to make sure it doesn't get lost in formatting.
The Structure
The four parts of a prompt that actually produces a usable update
Every prompt that works, for a status update or almost anything else, is really these four things stacked on top of each other.
Context: what the project is and who's reading
Claude cannot read your calendar or your org chart. Say what the project is, and say who the update is for: your manager, your team, or someone three levels removed who only cares about risk. The same week of work reads differently depending on who's asking.
Task: a status update, not a summary of everything
"Summarize my week" and "write my status update" sound similar but aren't. A status update has an audience and a purpose: it tells a reader whether to worry, whether to help, or whether to move on. Say the word "status update" and Claude aims at that specific shape.
Format: sections, length, and tone
Name the sections you want (Done, In Progress, Blockers, Next are the standard four) and roughly how long each one should run. Without this, Claude has to guess your team's convention, and it will guess wrong at least as often as it guesses right.
Checking: what you'll verify before it goes out
Tell Claude to flag anything it had to infer or guess, rather than quietly fill a gap with something that sounds plausible. Then actually read the draft against your real week before you send it, especially any line about a blocker, a date, or a commitment.
Before And After
What changes when you add the four parts
Here's the prompt most people start with: "Write my weekly status update." Nothing else. Claude has no project, no audience, no notes, and no sense of what matters this week, so it either asks you a round of clarifying questions or, more often, writes something generic enough to apply to almost any project at almost any company. It reads fine. It says nothing.
Here's the same request with the four parts filled in: "I need a weekly status update for my manager, covering the backend migration project. Here are my raw notes from the week: [notes]. Write it in four sections: Done, In Progress, Blockers, and Next Week. Keep each section to 2-4 short bullet points. If anything in my notes is ambiguous, flag it instead of guessing." Same task, same five minutes of typing, a completely different outcome, because Claude now has a project, a reader, real material to work from, a shape to fill, and an instruction not to paper over the gaps.
The difference isn't that the second prompt is clever. It's that it answers the four questions Claude would otherwise have to guess at: what is this, who's it for, what should it look like, and what should I be careful about. Once you've written that pattern once, reusing it for next week's update is mostly copy, paste, and swap in new notes.
Common Mistakes
What makes Claude guess instead of report
These are the gaps that produce a status update that sounds confident and is quietly wrong.
Pasting nothing and expecting Claude to know your week
Claude has no access to your ticket system, your calendar, or your Slack history unless you paste it in. A prompt with no raw material produces a status update made of plausible-sounding filler, not an account of what actually happened.
Not naming the reader
A status update for your manager and one for the whole team carry different detail and different tone. Leave the reader unnamed and Claude has to split the difference, which usually means it's slightly wrong for both.
Never asking it to flag uncertainty
Left alone, a draft tends to smooth over gaps instead of marking them, because smooth prose reads better than a list of caveats. Ask it to flag what it had to guess, and you get a draft that tells you where to double check instead of one that hides it.
Sending the first draft unread
A status update is often the only signal your manager gets about a project that week. A line that quietly overstates progress, or buries a blocker in a bullet list instead of leading with it, is exactly the kind of mistake that a thirty-second read catches and a skipped read doesn't.
Sourced From Anthropic
The one thing Anthropic's own guidance says to do differently
Anthropic's own documentation on prompting Claude makes a point that applies directly to status updates: being specific about the task and giving Claude the material to work from produces a meaningfully better result than a short, vague instruction, even when the short version seems like it should be enough. A status update is a good test case for this, because the material (your actual week) is the part a vague prompt leaves out entirely.
In practice, that means the raw notes you paste into the prompt are doing more work than the instructions around them. A well-structured prompt with thin or missing notes still produces a thin update. A plain prompt with your actual tickets, messages, and half-written notes pasted in will usually out-perform it, because Claude has something real to organize instead of something to invent.
Before You Send It
What to check before a status update goes out
Read the Blockers section first, against your own memory of the week, not against the draft's phrasing. A blocker that Claude wrote cautiously can still read as resolved to a reader skimming quickly; if it's still open, say so plainly rather than trusting the draft's hedging to carry the weight.
Check any sentence with a date, a number, or a commitment in it specifically. These are the details most likely to have come from an inference rather than your actual notes, and they're also the details a reader is most likely to act on directly, so an error here costs more than an error in a general description of progress.
If you asked Claude to flag what it had to guess, read those flags before you read anything else. They're the fastest way to find the one or two lines in an otherwise solid draft that need a second look, rather than re-reading the whole thing line by line every week.
When This Isn't The Right Tool
When to write the update yourself instead
A status update that's really a difficult conversation in disguise, like telling a stakeholder a deadline has slipped for reasons that reflect badly on a decision someone made, is worth writing yourself first. The judgment about tone, what to lead with, and what to leave for a conversation instead of an email is not something a prompt should carry, even a well-written one.
If your week genuinely had almost nothing in it worth reporting, that's useful information for your manager too, and a prompt that pads a quiet week into four full sections can end up misleading a reader into thinking more happened than did. Sometimes the honest status update is three lines long, and no amount of prompting should talk Claude into stretching it.
Writing one good status update prompt is the easy part
The harder skill is knowing which details to pull out, which to leave out, and how to phrase a blocker so it gets read as urgent instead of routine. Nightschool AI's free lessons walk through real workplace writing tasks with Claude, not toy examples.
Frequently Asked Questions
What should I paste into the prompt when I ask Claude to write a status update?
Paste whatever raw material you actually have: ticket titles, Slack messages, meeting notes, or a rough bullet list from memory. The more real material Claude has to organize, the less it has to infer, and the more accurate the draft will be.
How do I stop Claude from making my status update sound more finished than it is?
Ask it directly to flag anything it had to guess or infer rather than stating it as settled fact. Then read those flagged lines first before you send the draft, since they're the most likely place for a quiet overstatement to hide.
Should I tell Claude who the status update is for?
Yes. An update for your direct manager and one for a skip-level executive need different detail and different emphasis, and Claude has no way to know which one you want unless the prompt says so explicitly.
What sections should a weekly status update have?
Done, In Progress, Blockers, and Next Week is a common default that covers most projects. Name your preferred sections in the prompt rather than relying on Claude's default, since teams vary in what they expect.
Can Claude write a status update without any notes from me?
It can produce something that reads like a status update, but without your real notes it has to fill the content with plausible-sounding generalities instead of an account of what actually happened. Paste in real material for a result worth sending.
How long should a weekly status update prompt be?
Long enough to cover the four parts: context, task, format, and what to check, plus your actual notes. That's usually a few sentences of instructions and then as much raw material as you have, which can be far longer than the instructions themselves.
What's the difference between asking for a summary and asking for a status update?
A summary just condenses what happened. A status update is written for a specific reader to make a specific decision, like whether to help, worry, or move on. Using the words "status update" and naming the reader points Claude at that purpose instead of a generic recap.
Should I edit the status update Claude writes, or send it as is?
Read it against your own memory of the week before sending, especially any line involving a date, a number, or a blocker. A first draft is a strong starting point, not a finished message, the same way a colleague's first pass at a document would be.
A clear status update takes five minutes with the right prompt
The prompt is reusable. The judgment about what to say is the part worth practicing.