How to Prompt AI for a Weekly Status Report

Paste a week of commits, tickets and Slack threads into a model and prompt it for a weekly status report, and you will get one. It will be accurate, well organised, and nobody will read past the second bullet, because it is a list of everything that happened rather than a document that tells the reader what to do.

The fix is not a better tone instruction. It is telling the model what the report is for, which is a different thing from telling it what the report is about.

What a weekly status report is actually for

Summarisation compresses. It keeps the most frequently mentioned and most recent material and drops the rest. That is the wrong selection function for a status report, because the most important item of a week is often mentioned once, on Tuesday, in a single message: the thing that is now blocked.

A status report has three jobs. It tells the reader what changed in a way they can repeat to someone else, it surfaces anything that needs a decision from them, and it flags what is at risk while there is still time to act. Everything else is noise, and a summariser will faithfully preserve all of it.

The structure that works

Give the model the classification rules rather than an output format. Formats produce headings. Rules produce judgement.

You are writing the weekly status report for [project] for [audience,
e.g. the client's operations director, who is not technical and sees
this once a week].

Sort every item in the input into exactly one of four buckets:

1. SHIPPED. Finished and visible to a user this week. Describe the
   user-visible effect, not the implementation.
2. DECISION NEEDED. Blocked on something only the reader can resolve.
   State the decision, the options, your recommendation, and what
   happens if it is not answered by a date.
3. AT RISK. Not blocked yet, but will slip if something does not
   change. Say what would have to change.
4. DROP. Everything else: internal refactors, routine fixes, anything
   with no consequence for the reader.

Rules:
- Bucket 2 goes first, then 3, then 1. Never lead with SHIPPED.
- If bucket 2 is empty, say "No decisions needed this week" in one line.
  Do not invent one.
- Maximum five items per bucket. If there are more, merge the smallest.
- List the DROP bucket as a count only, like "11 routine fixes and
  internal changes."
- No adjectives about progress. Not "great progress", not "solid week".
  State what happened.

The DROP bucket does most of the work. Without it, the model treats exclusion as failure and stretches to include everything, because leaving material out looks like a mistake. Naming a bucket for the excluded material makes exclusion an assignment it can complete rather than a risk it avoids.

Putting decisions first is the second lever. A report that leads with accomplishments is read as a report about the team. A report that leads with what the reader must resolve is read as a report about the project, and that is the one people answer.

Feed it primary material, not a summary

The quality of the input decides the ceiling. In rough order of usefulness:

• Merged pull request titles and descriptions. The single best source, because they are written to explain a change to another person. If you already track delivery metrics such as the DORA four keys, those numbers give the report a spine that does not depend on anyone's recollection.

• Closed ticket titles with their status transitions. Shows what moved and what did not.

• Notes from the week's meetings, which is where blockers get spoken aloud and never written down. The technique in turning a voice memo into meeting notes is a cheap way to capture these.

• Last week's report, so the model can flag what was promised and did not happen.

That last input is the one people skip and it is the one that changes the output most. Supply it explicitly:

Here is last week's report. Any item that appeared in AT RISK or DECISION NEEDED last week and is still unresolved must appear again this week, marked as carried over with the number of weeks it has been open.

A blocker on its fourth consecutive appearance, labelled as such, escalates itself. The same item rewritten fresh each week never does, which is the single most common way a status report fails at the only job it has.

Give it one example rather than a description of the tone

Models match a sample faster than they follow an adjective. One before and after pair is usually enough.

Not this: "Made significant progress on the payments integration, with several improvements to the checkout flow."

>

This: "Checkout now accepts saved cards. Refunds still go through the old dashboard; moving them is next week's work."

The second is shorter, contains two facts, and can be repeated to a third party by someone who was not there. That is the test.

Where humans are still required

Three things you should not delegate.

Judging severity. A model can tell you a deployment was rolled back. It cannot tell you whether that matters to this particular reader, who was told last month it would not happen again. Severity is relationship context and it is not in the input.

Anything about people. Do not let a report generated from activity data characterise individuals. Commit counts and ticket throughput are not performance, and a sentence implying otherwise will outlive the week it was written in.

The forecast. If the report contains a date, you own that date. Models produce plausible timelines from insufficient information without signalling the uncertainty, which is why estimating a project timeline deserves its own careful prompt rather than a line in this one.

FAQ

Why do AI status reports read like a list of everything?

Because summarisation keeps what appears most often, and status reporting needs what matters most. Those are different selection functions. Giving the model an explicit bucket for material to exclude fixes it.

What should I feed the model?

Primary material: merged pull request descriptions, closed tickets with status changes, meeting notes, and last week's report. Avoid feeding it an existing summary, which compresses twice and loses the single-mention items.

How do I stop it inventing blockers?

Tell it what to do when a bucket is empty. "If there are no decisions needed, write 'No decisions needed this week' and move on" removes the pressure to fill the section. Related techniques for keeping models inside the source material are covered in summarising a long meeting transcript, writing a handover document and our wider prompt engineering guide.