How to Build a Weekly Product Status Report in Claude

Most product managers still assemble weekly status reports by hand. They open the project tracker, scan merged pull requests, search Slack for decisions, compare everything with the plan, and then try to compress it into something leaders will read.

Claude can do most of that work. The challenge is making the result consistent and trustworthy every week.

This guide shows you how to create a weekly status routine in Claude Code Desktop that:

Reviews one project across GitHub, Linear or Jira, and Slack
Separates completed, merged, deployed, and customer-visible work
Links every important claim to its source
Flags blockers, decisions, and emerging risks
Remembers what previous reports already covered
Runs automatically every Monday morning

The result should be a report you review for five minutes, not one you spend 90 minutes assembling.

What you will build

Every Monday at 7:00 a.m., Claude will review the previous seven days of activity for one project and produce a brief with five sections:

Shipped
In progress
Blocked
Decisions
Risks

Claude will verify the draft against the underlying sources, save the final report, and update a log so the next run does not repeat old information.

This is a product-management version of what Addy Osmani calls loop engineering: instead of prompting an agent from scratch each time, you create a repeatable system that finds the work, performs it, checks the result, and preserves enough state for the next run.

Before you begin

You need:

Claude Code Desktop
A local folder or repository for the reporting workflow
Read access to the relevant GitHub repository
Read access to the project in Linear or Jira
Access to the Slack channels where the project is discussed
A reliable source for deployment or release information, if you want Claude to report that work reached customers

That last requirement matters. A merged pull request proves that code was merged. It does not prove that the change was deployed, enabled, or available to customers.

Step 1: Create a working folder

Create a folder where Claude can store the reporting instructions and history:

project-status/
├── .claude/
│   └── skills/
│       └── weekly-product-status/
│           └── SKILL.md
├── reports/
└── status-log.md

The skill defines how your team interprets project activity. The status log gives the routine memory between runs. The reports folder holds each finished brief.

You can keep this inside the project repository if the report should be shared with the team, or in a separate private folder if it contains sensitive information.

Step 2: Connect the sources

Connect GitHub, Linear or Jira, and Slack to Claude. Anthropic’s current connector setup is available through the connectors directory, where you authenticate each source and control its permissions. Anthropic recommends testing each connection with a specific retrieval request before relying on it.

Keep the reporting boundary narrow:

One GitHub repository
One Linear or Jira project
Two or three relevant Slack channels
One product specification
One deployment or release source, if available

Complete evidence for a small scope is more useful than partial evidence from across the company.

Before continuing, ask Claude:

Confirm that you can read:

1. The GitHub repository [ORG/REPO]
2. The Linear or Jira project [PROJECT]
3. Slack channels #[PROJECT-CHANNEL] and #[TEAM-CHANNEL]
4. The product specification at [LINK]

For each source, return one recent example with a working link.
Do not make any changes.

Fix any missing permissions before scheduling the report.

Step 3: Create the reporting skill

Claude Code discovers project skills from .claude/skills/<skill-name>/SKILL.md. You can invoke the skill directly with /weekly-product-status, or Claude can load it when a request matches its description. Claude’s skill documentation explains the supported locations and format.

Save the following as:

.claude/skills/weekly-product-status/SKILL.md

---
name: weekly-product-status
description: Creates an evidence-backed weekly status brief for this project. Use for weekly summaries, project health checks, and leadership updates.
---

# Weekly product status

## Project

[PROJECT NAME] helps [CUSTOMER OR USER] accomplish [OUTCOME].

The current product specification is:
[SPEC LINK]

## Sources

- Tickets: Linear or Jira project "[PROJECT]"
- Code: GitHub repository [ORG/REPO]
- Discussion: Slack channels #[PROJECT-CHANNEL] and #[TEAM-CHANNEL]
- Specification: [SPEC LINK]
- Deployment or release evidence: [SOURCE OR "not connected"]

## Status definitions

- Completed in the tracker means the ticket is marked complete.
- Merged means the pull request was merged into the default branch.
- Deployed means there is explicit deployment evidence.
- Available to customers means there is explicit evidence that the change was enabled or released to customers.
- Blocked means progress cannot continue without a named decision, dependency, or external action.
- A decision only counts if it changed the scope, specification, priority, owner, or delivery plan.

Never use "shipped" when the available evidence proves only that work was completed or merged.

## Evidence rules

- Link every material claim to a pull request, ticket, document, deployment record, or Slack message.
- Confirm that the source supports the wording of the claim.
- Separate facts from hypotheses.
- If a source is unavailable, add a coverage warning at the top of the report.
- If sources disagree, describe the disagreement instead of choosing one silently.
- Flag work that contradicts the current specification.
- Do not infer customer availability from a merged pull request.

## Output

Keep the final report under 400 words.

Use these sections:

1. Summary
2. Shipped
3. In progress
4. Blocked
5. Decisions
6. Risks

If a section has no supported items, write "None."

The definitions are more important than clever prompting. Most inaccurate status reports begin with ambiguous words such as “done” or “shipped.”

Step 4: Test it manually

Before scheduling anything, run the skill manually:

/weekly-product-status

Review the last seven days for this project.

Before writing the report, list the sources you searched and identify any coverage gaps. Read status-log.md and do not repeat previously reported items unless their state changed.

Save the finished report to reports/YYYY-MM-DD-weekly-status.md.

Review the result carefully.

Check whether Claude:

Included working evidence links
Distinguished merged work from released work
Treated ordinary Slack conversation as a decision
Reported stale tickets as active
Missed work because it used the wrong project or channel
Presented an inference as a fact

When something is wrong, update the definitions or source boundaries in the skill. Avoid adding a growing list of corrections to the scheduled prompt. The skill should contain your team’s durable operating rules.

Step 5: Add a verification pass

The agent that wrote a report is often too generous when reviewing its own work. Add a second pass with a fresh context before accepting the result.

Include these instructions in the scheduled routine:

After drafting the report, start a fresh verification pass.

Check every material claim against its linked source. Flag:

- Links that do not support the claim
- Work described as shipped without release evidence
- Unsupported blockers or decisions
- Important activity that the draft missed
- Conflicts between tickets, code, Slack, and the specification

Correct the report before saving it.

Do not remove a coverage warning simply because no contradictory evidence was found.

This checker makes review faster. It does not eliminate the need for human judgment.

Step 6: Schedule the Monday routine

Claude Code Desktop supports persistent scheduled tasks. Open Routines in the sidebar, select New routine, and choose Local.

Configure it as follows:

Name: Weekly product status
Working folder: Your project-status folder
Schedule: Weekly, Monday at 7:00 a.m.
Permissions: Read access to connected sources and write access to the reporting folder
Instructions: Use the prompt below

Run /weekly-product-status for the previous seven days.

First, read status-log.md. Do not repeat an item from an earlier report unless its status, evidence, owner, risk, or customer availability changed.

Create a draft, then run the fresh verification pass defined in the skill.

Save the corrected report to:
reports/YYYY-MM-DD-weekly-status.md

Append a compact record of the reported items and their current states to status-log.md.

Do not post, send, or publish the report automatically.

If any required source is unavailable, continue with the available evidence but place a clear coverage warning at the top.

Keep the final report under 400 words.

A local routine runs while Claude Code Desktop is open and the computer is awake. Anthropic’s scheduled-task documentation provides the current setup details.

If the report must run while your computer is off, use a cloud routine. Cloud routines run on Anthropic-managed infrastructure, but you will need to configure their repositories, connectors, and persistence separately.

Step 7: Improve the first three reports

Expect the first report to over-report.

Claude may interpret stale tickets as active work, routine discussion as a decision, or a merged pull request as a customer release. Correct those problems by making the skill more precise.

By the second or third run, the workflow should settle into a useful pattern:

The scheduled prompt stays nearly unchanged.
The skill becomes a more accurate description of how your team works.
The status log prevents repetition.
Human review focuses on judgment instead of collection.

Where Devplan helps

This setup works well for one project with a small number of sources. The harder problem appears when every team, project, and agent has to reconstruct the same context independently.

One routine searches Slack. Another searches Linear. A third interprets GitHub history. Each has to rediscover which sources are current, how records relate, and which definition of “done” applies.

Devplan provides Connected Product Intelligence by maintaining those relationships across code, tickets, documents, conversations, meetings, projects, and decisions. Weaver keeps that context connected and evidence-backed, and Claude can access it through one MCP connection.

The weekly report still needs clear instructions and human review. The difference is that Claude begins with maintained product context instead of rebuilding the project’s history from disconnected searches every Monday.

That is what turns a useful automation into a dependable operating routine.