Team coordination

Use a Claude Project to Turn Approved Updates into a Weekly Status Brief

Cihan's view: Put approved update notes and a reporting template in a Claude Project, then ask Claude to draft a status brief with a source tag on every statement.

Choose another work task →

What you will make

A weekly status brief for a fictional operations project. The brief will contain current facts, blocked items, next actions, and open questions. Every factual line will point back to one of the approved notes.

This is a documentation-based guide with fictional inputs and an illustrative output. Claude Projects provide a self-contained workspace with chats and a knowledge base. Anthropic’s Projects overview notes that project features and the newer beta experience are rolling out in stages, so your screen may differ.

Before you start

You need:

  • A Claude account with Projects available.
  • Three short, approved text files. Use the exact sample below, not confidential company updates.
  • A reporting template that tells Claude what counts as a fact, an open question, and an owner.

A Project is useful here because the same small set of source notes can support several weekly chats. It does not make the sources current automatically. Replace the notes when the reporting period changes.

Fictional practice pack

Create these files:

project-update-2026-10-05.txt
Project: Northstar onboarding
Week ending: 2026-10-05
The team approved the new account checklist on 2026-10-02.
The help-centre draft is waiting for security review.
The product owner is Mira.
project-update-2026-10-06.txt
Project: Northstar onboarding
Week ending: 2026-10-05
The support team reviewed the checklist and requested one change to the password-reset step.
Security review has not started.
project-update-2026-10-07.txt
Project: Northstar onboarding
Week ending: 2026-10-05
Mira will confirm the password-reset wording after security review.
No launch date has been approved.
status-template.txt
Write five sections: Summary, Completed, Blocked or waiting, Next actions, and Open questions. Put [source: filename] after every factual sentence. Use Not stated rather than guessing. Never turn a suggestion into an approved decision. Keep the report under 350 words.

Three steps

1. Create the project and add the sources

In Claude, create a new Project called Northstar onboarding. Add the three update files and the template to the project knowledge area. If your account shows the newer Projects beta, follow the current interface and confirm that the files appear in the project Library or knowledge area before continuing.

Do not add real employee, customer, or security-sensitive data for this exercise.

2. Ask for a source-tagged brief

Start a chat inside the project and paste:

Use only the files in this project. Prepare the weekly status brief using status-template.txt. Before writing, make a private evidence map: each proposed statement must point to one file and an exact supporting sentence. If two files disagree, report the conflict in Open questions instead of resolving it yourself. Keep facts separate from recommendations, include [source: filename] after factual sentences, show that the checklist change is a request and not an approved change, say that no launch date is approved, name Mira only where the source names Mira, and use Not stated for missing owners or dates. Return only the five report sections and a short Review before sharing list.

3. Run the acceptance pass

Paste this second prompt:

Audit the draft against every source file. Return a table with columns: statement, source file, exact support, result. Use PASS only when the statement is directly supported. Use CHECK when it is a recommendation, inference, or conflict. Then list any unsupported owner, date, status, or launch claim. Do not rewrite the brief yet.

Review the audit. If it passes, copy the brief into the team’s approved reporting location. Claude should draft the report. A person still decides whether it is accurate enough to share.

Illustrative output

Summary

The account checklist was approved on 2026-10-02. The support team requested a change to the password-reset step. Security review has not started. [source: project-update-2026-10-05.txt] [source: project-update-2026-10-06.txt]

Completed

  • The new account checklist was approved. [source: project-update-2026-10-05.txt]
  • The support team reviewed the checklist. [source: project-update-2026-10-06.txt]

Blocked or waiting

  • The help-centre draft is waiting for security review. [source: project-update-2026-10-05.txt]
  • Security review has not started. [source: project-update-2026-10-06.txt]

Next actions

  • Mira will confirm the password-reset wording after security review. [source: project-update-2026-10-07.txt]

Open questions

  • The requested password-reset change is not recorded as approved.
  • No launch date is approved. [source: project-update-2026-10-07.txt]
  • The date for security review is not stated.

This is an editor-written illustration, not a generated or measured result.

Acceptance checks

The brief is ready for human review when:

  • Each factual sentence has a source tag.
  • The checklist change remains a request, not a completed change.
  • No launch date appears as a fact.
  • Missing dates and owners are visible as Not stated or open questions.
  • The audit table can trace every claim to an exact sentence.
  • The report stays within the template limit.

If something goes wrong

  • Claude blends files from different weeks: include the reporting period in the prompt and ask for the evidence map before drafting.
  • A request becomes a completed action: label each source sentence as approved, requested, waiting, or unknown, then rerun the audit.
  • The project uses the wrong file set: check the project knowledge or Library before asking for a report. Remove stale practice files and add the current approved pack.
  • The interface does not show Projects as described: treat the surface as unavailable for this guide. Do not claim that a different workspace or beta screen is equivalent without checking current Anthropic documentation.

Limits and privacy

Project knowledge can contain sensitive material, so use approved files and the minimum necessary context. Team and Enterprise sharing permissions differ from private projects. Review current account controls before uploading internal information. A source tag helps a reviewer find evidence, but it does not prove the sentence is correct.

Next lesson

For a related source-checking workflow, read Claude Project using the wrong source? Build a claim check before you draft.

About Cihan

Creator and operator focused on practical AI for business professionals. Background and editorial approach →