This guide gives you a reusable starting pattern. It is designed to help you see the work more clearly; it is not a substitute for judgment, source checking, or responsibility for the result.
Prepare the inputs before you ask for output.
The model only sees what you give it. Spend a few minutes naming the reader, desired result, and uncertain information. This makes a first draft easier to assess and reduces the need for decorative rewriting later.
Give the task a useful brief.
Create a factual weekly review from the work log below. Review period: [date range] Goal for the period: [goal] Completed work: [list with evidence or links] In progress: [list] Blocked or waiting: [list and stated dependency] New requests: [list] Produce four sections: completed, carryover, blockers, and next priority. For each carryover item, state why it remains open only when the log says why. Mark missing reasons as “Not stated.” Do not infer productivity, urgency, ownership, or completion. Finish with three questions a human owner should answer before setting next week’s priorities.
Replace every bracketed field with your real context. Read the output before reuse.
Four steps that keep the result usable.
- 1
Set the review period and intended outcome.
- 2
Separate completed, in-progress, blocked, and new work before summarizing.
- 3
Include evidence or links for completed work where available.
- 4
Choose next priorities only after a human reviews dependencies and capacity.
A review is not a performance story
A weekly review should help the next planning conversation, not make a task list sound better. Keep completed work tied to observable evidence and let unfinished work retain its real status. This makes the record useful even when the week did not go to plan.
Carryover needs a reason or an explicit gap
When a task moves forward, the next person needs to know whether it is blocked, deprioritized, waiting for input, or simply unfinished. If the work log does not say, label the reason as unknown rather than asking AI to fill it in.
Let dependencies shape next week
A review becomes a plan only after someone considers time, people, decisions, and external dependencies. Ask the model to surface those questions, then let the accountable person decide what deserves attention and what should leave the list.
A worked example: an operations week
A week with three completed fixes, two blocked tickets, and a new compliance request produces a short review: completed items tied to their ticket links, blockers with the named dependency — “waiting on security review since Monday” — and one next priority. The review keeps unfinished work visible instead of making the week sound cleaner than it was.
Make the review reusable
If the review is read again next week, it should still make sense. Keep dates, links, and dependency names in the text rather than assuming memory. A review that stands alone is easier to turn into next week’s starting list, and harder for anyone to misread as a claim of completion.
Run a human check.
- Can completed work be traced to a stated result or link?
- Are carryover reasons taken from the log rather than inferred?
- Are blocked items tied to an explicit dependency or marked as unknown?
- Does the review distinguish a summary from a new priority decision?
- Are next-week questions assigned to a human owner?
AI is strongest here when it makes missing information, structure, and options easier to see. The moment an output becomes a claim, commitment, or decision, bring a person back into the loop.