Turn scattered project notes into a weekly brief
Keep the change, the evidence and the unanswered decision. Leave out the confident story your notes cannot support.
This fictional example shows a text-only drafting workflow. The sample brief is an editorial example, not a report of an AgReady execution or a customer result.
One week, one audience, one cutoff
A weekly update is not a transcript. Its reader needs to know what changed, what remains blocked and which decision needs attention. The difficult part is preserving those distinctions while shortening the source material.
For this example, the audience is a project sponsor. The reporting window is October 19–23, 2026, with a cutoff of Friday at 17:00 UTC. The project is a small help-center refresh. We will draft a brief, not send it or update a project system.
The source packet
Give each note an ID before asking for a summary. Keep dates and the meaning of any counts. Remove confidential information that is not needed for the draft.
[N1] Monday, Oct 19, 09:00 UTC — planning Help-center refresh: 12 articles in scope. Six drafts ready for review. Priya owns the content. Friday is a target for a preview, not public launch. [N2] Wednesday, Oct 21, 14:00 UTC — content check Nine of the same 12 articles now have drafts ready for review. Two of those nine still need product review. None is approved to publish. [N3] Thursday, Oct 22, 11:00 UTC — preview test The preview build is available to the internal reviewers. Mobile navigation has a broken link. Leo will investigate; no fix date yet. [N4] Friday, Oct 23, 16:00 UTC — review update Product review completed for the two articles mentioned in N2. Publication approval is still pending for all articles. The navigation issue is still open. The sponsor must decide whether Monday's wider preview may proceed with the known issue. [N5] Friday, Oct 23, 18:30 UTC — late message Leo reports a navigation fix. Verification is scheduled for Monday.
N5 is outside the cutoff. It may be relevant later, but quietly folding it into Friday's status would change what the brief means. Also, “draft ready,” “product reviewed” and “approved to publish” are different states.
A prompt you can reuse
Copy the prompt below together with the source packet. For your own project, replace the audience, window and notes; keep the boundaries that matter.
Draft a weekly project brief for the sponsor using only notes N1–N5. Reporting window: October 19–23, 2026; cutoff: Oct 23 at 17:00 UTC. Do not browse, edit source notes, update systems or send the brief. Write at most 220 words, excluding the title, in these sections: - Progress: changes supported by notes within the reporting window. - Open risk: what remains unresolved at the cutoff. - Decision needed: the specific question for the sponsor. - After cutoff: relevant later information, clearly separate. Attach note IDs to factual statements. Show arithmetic for any change in counts. Keep draft readiness, product review and publication approval separate. Do not assign a status color, invent a deadline, or turn a reported fix into a verified fix. If the notes do not establish an owner or outcome, say so rather than filling the gap. Return a draft for human review, not a claim that it has been sent.
Example brief
Progress. Drafts ready for review increased from 6 to 9 of the same 12 articles: 9 − 6 = 3 additional drafts. [N1, N2] Product review finished for the two articles flagged on Wednesday; publication approval remains pending for all articles. [N2, N4] The internal preview build is available. [N3]
Open risk. At the 17:00 UTC cutoff, the mobile navigation issue remained open. Leo owns the investigation; the notes do not establish a fix deadline. [N3, N4]
Decision needed. May Monday's wider preview proceed with the known navigation issue? The sponsor's decision is not recorded. [N4]
After cutoff. At 18:30 UTC, Leo reported a fix, with verification scheduled for Monday. This is not a verified resolution and does not change the cutoff status above. [N5]
Notice what is absent: no “75% complete,” no launch announcement and no “issue resolved.” Nine ready drafts out of twelve is a draft-readiness count, not a measure of the whole project's completion.
Review before sharing
- Trace the nouns and numbers. Check every note ID. Confirm the denominator is still the same twelve articles before accepting the increase of three.
- Check the clock. N5 must remain after the cutoff. If you move the cutoff, regenerate the brief and label the new reporting time.
- Check the state transitions. Product review is not publication approval. A reported fix is not a verified resolution.
- Check the decision. The brief should ask about the wider preview, not silently approve it or invent the sponsor's answer.
- Check the audience. Remove unnecessary personal or sensitive details, confirm the intended recipients, and approve the final wording before sharing it yourself.
If a sentence fails, give a targeted correction: “Keep the late fix in After cutoff and do not call it verified.” You do not need to rewrite the entire prompt.
Use the brief as a draft, not a new source of truth
Keep the source packet beside the reviewed brief. If someone corrects a fact, update or add the underlying note before producing another version. Otherwise, the next summary may repeat a polished mistake.
For the general task-briefing method, read Give an agent a task you can actually verify. To prepare an AgReady instance and a bounded first task, follow Get started. This example needs only supplied text; it does not assume access to your project tools.