A BETTER WAY TO SHARE THE WORK
Turn project notes into a weekly status report people can act on
Your team does not need another list of things that happened. Give them the changes that matter and the decisions that keep work moving.
New to creating with an agent? The request will guide it through the task. Bring your notes; you don’t need to write HTML.
How do I create a useful weekly status report with an AI agent?
Give your agent dated project notes, the previous update, and the decisions your audience owns. Ask it to separate completed work from expected work, show what changed, and name the next action for each risk. Review the evidence, then share one readable HTML briefing.
01 / SEE THE DIFFERENCE
A launch update with one clear decision
An illustrative team is preparing a customer portal launch. Its notes include finished interface work, an outstanding permission review, and two possible launch scopes.
Updated navigation. Fixed eight issues. Continued permission testing. Met with operations. Launch discussion ongoing.
- Position
- Core interface work is complete. Launch timing remains unconfirmed because permission testing is incomplete.
- Changed this week
- The navigation milestone is complete; the permission review remains open. These are separate outcomes, not one overall completion claim.
- Decision needed
- Choose whether to launch the core portal first or wait for the additional account roles.
- Next action
- The project lead will confirm the launch option after the security reviewer supplies the remaining test results.
- Watch next week
- Report the permission review result and the confirmed scope. Do not carry forward an unverified launch date.
Open a complete fictional HTML example, with its source notes →
Create my weekly update02 / MAKE IT YOURSELF
Start with the evidence. Shape the page around the reader.
Choose the reader's decision
Start with who needs this update and what they can do with it. A sponsor may need to approve a tradeoff; a delivery team may need a dependency resolved. Tell the agent that purpose before supplying notes. It gives the report a useful filter for deciding what deserves space.
Compare this week with last week
Ask for a short change summary before drafting the report. A ticket moving between internal stages may not matter to a sponsor; a milestone changing from likely to uncertain does. Require the agent to distinguish source-backed changes from its interpretation and flag any conflicting dates.
Turn blockers into actionable requests
For every material risk, include the consequence, owner, next action, and when help is needed. Keep an unresolved decision separate from a general concern. If an owner is absent from the notes, say that ownership needs confirming instead of assigning someone based on a guess.
For clients, report the promise—not the ticket list
Organize the update around agreed milestones: what was delivered, what evidence supports it, what still needs acceptance, and what the client needs to do. Fictional example: 'Checkout built; tests passed; sponsor review pending; launch date unconfirmed' becomes 'Checkout is ready for sponsor review. Technical tests passed, but client acceptance and launch timing remain unconfirmed.' Do not turn a finished build into an accepted milestone or claim customer impact without measured outcomes. Leave internal margins and private comments out of the shared page, while keeping material scope, cost, and schedule risks visible.
Build a short briefing with supporting detail
Lead with overall position, changes, and decisions. Put the work log beneath those sections for readers who want it. Ask for a static HTML page in your saved style, if available, then check the source facts and recipient access before publishing. Label the reporting period prominently.
Adapt this to your work
Keep the same approach. Change the inputs and review checks for the job you need.
A sprint review recap
Help stakeholders inspect the Sprint Goal, completed work and feedback after a working session. A reading page supports the review; it does not replace the conversation or turn suggestions into agreed backlog work.
Fictional source notes: Fictional Sprint 8 aimed to improve search. Search changes meet the team's supplied Definition of Done. Export work is incomplete. Stakeholders suggested checking keyboard access next; the team has not agreed that follow-up. No delivery date was agreed.
A clearer result: Lead with the search outcome against the Sprint Goal. Keep export explicitly incomplete. Label keyboard-access work as stakeholder feedback awaiting a team decision, not committed work. Keep the absent delivery date unresolved.
The matching instructions are included in the creation request below; your agent should use them only when relevant.
A one-page project summary
Treat one page as a request for a concise reading experience, not tiny typography or forced print pagination. Summarize current work here; use a project proposal when the reader must authorize work that has not been approved.
Fictional source notes: Fictional portal project: core navigation complete; permission testing incomplete; launch date unconfirmed. The sponsor must choose core-only scope or wait for extra account roles after receiving the remaining test results. The project tracker retains detailed tasks.
A clearer result: Use four short sections: purpose, present position, decision needed and evidence to check. Keep the incomplete permission review beside the launch question. Link to the authorized tracker rather than copying every task; no invented launch date or completion score.
The matching instructions are included in the creation request below; your agent should use them only when relevant.
03 / TRY THIS PROMPT
Copy this into your agent. Add your source material.
Use the conversation where you already did the work, or start one with your notes. Replace the placeholders and supply any missing context; only attach information you are allowed to share with your agent.
Get the ready-to-copy creation request for guided questions, this task, and a draft review before anything is published.
Using only the project materials I provide, create a weekly status briefing for [audience] covering [date range]. Compare with the previous update. Lead with the overall position, meaningful changes, and decisions needed. For each material risk, include its consequence, known owner, next action, and confirmed deadline; mark missing information explicitly. Separate completed work, planned work, estimates, and interpretation. For a client audience, organize by agreed milestones and distinguish delivery, client acceptance, and measured outcomes. Omit internal margins and private comments from the output, not material scope, cost, or schedule risks. Ask for missing acceptance evidence rather than treating silence as approval. Name the approval contact and deadline only when supplied; direct replies to the established email or project workflow, not a form in the artifact. Do not infer progress percentages or invent dates. Keep an optional work log below the main summary. Build readable static HTML without scripts, forms, or live-data claims. Use my saved artifact style if available, prioritizing clear headings and restrained color. Include only audience-safe source notes and links. Show me the draft and flag contradictions for review. Do not publish or change anyone's access without separate explicit approval. If this is a sprint review recap, preserve the Sprint Goal, supplied Definition of Done, done/not-done work, stakeholder feedback and proposed adaptations. Do not mark incomplete work Done or treat feedback as an agreed backlog commitment. The static recap does not replace the collaborative Sprint Review. If I ask for a one-page project summary, produce a concise responsive overview of purpose, current position, next decision and approved evidence links. Do not shrink text to force one printed page. For unapproved work, clarify whether I need a proposal instead; do not recast a proposal as approved progress.
04 / BEFORE YOU SEND
A polished page still needs your judgment.
- Does every completed claim mean completed in the source, rather than started or nearly done?
- Are milestones, reporting period, owners, and deadlines accurate and unambiguous?
- Can the intended reader identify the decision or next action without reading the work log?
- Have private ticket comments, customer details, and unsuitable internal links been removed?
- For client reports, is delivery separate from acceptance and measured impact, with material risks still visible?
When HTML fits
Use an HTML briefing when readers need a portable summary with readable sections and links to evidence. A dated snapshot can be shared without making everyone navigate the project tracker.
When another format fits better
Keep the tracker as the source of truth for task assignment and changing status. If its existing report already answers your client's questions, share that rather than maintain a second copy. Use the established email or project workflow for approval records. This HTML report is not a live dashboard, and publishing it does not automatically refresh its contents.
FROM DRAFT TO A LINK
Make it clear. Make it yours. Then share it.
Keep creating and revising in the agent you already use. With a compatible connection, share/artifacts publishes the reviewed HTML so you do not have to rebuild it in another editor. Ask your agent to use your saved artifact style for headings, color, and tone; review the result before sending it.
Choose who should be able to open the page and verify the returned link. For corrections to the same deliverable, update the existing artifact without changing its link. Publish a separate artifact when the old edition needs to remain available.
These are static pages, not live apps: no scripts, forms, or automatic data refresh. Source collection and scheduling depend on your agent and its available tools, not on share/artifacts.
Make this with my agentQuestions before you start
How do I adapt this into a client progress report?
Set the audience to your client and provide the agreed milestones, delivery evidence, and acceptance state. Lead with what changed for them and the response you need, not internal ticket activity. A delivered feature can still be awaiting client acceptance; neither proves a customer outcome. Verify sensitive details and evidence links before sharing. Keep approval replies in your existing email or project workflow—the page does not collect sign-off.
Should I include everything the team did?
Keep a detailed work log only if it helps the audience. The opening should explain material changes and needed actions. Effort can be important context, but a long activity list does not establish whether the project is on course.
Can I update the same report link each week?
You can update a published share/artifacts page at the same URL. Change its reporting period and review the replacement. If readers need a historical record, keep dated snapshots separately rather than overwriting the only copy of an earlier update.
What if the notes disagree about project status?
Ask the agent to list the disagreement and its sources. Confirm the correct status with an accountable person. Until then, label it unresolved; choosing the most optimistic note would hide precisely what a status report should make visible.