Turn Tracker Activity into a Status Report That Tells the Truth

Workflow area: Delivery & Reporting · Tier: Foundation · Hands-on time: ~25 minutes

Status reporting is the most automatable-looking task in a leader's week, which is exactly why it goes wrong. A model fed a week of ticket activity produces something status-shaped immediately: fluent, organized, and subtly false — it reads "closed 23 tickets" as progress when 19 were cleanup, calls a project green because nothing in the tracker says otherwise, and misses that the week's most important event was a conversation that never touched a ticket. The draft is real leverage. The correction pass is the report.

When to use — and when not to

• Use it for the weekly up-and-out reportthe recurring artifact where drafting friction causes late, thin, or skipped updates that erode leadership's picture of your team.
• Use it when you run multiple workstreamsthe model's genuine advantage is holding six streams of activity in view at once while you hold the meaning.
• Use the activity summary as your own mirrorthe gap between what the tracker shows and what you believed was happening is itself a finding about your visibility.
• Skip it if your tracker hygiene is fictionstale tickets and phantom epics produce confident summaries of a project that doesn't exist; fix hygiene first or the pipeline launders it into narrative.
• Skip auto-sending on a schedulean uncorrected activity summary mailed to execs is worse than no report; it teaches them to read your tracker's noise as your voice.
• Skip it for crisis reportingan incident or escalation update follows pb-06's verified-claims discipline, not a weekly digest format.

The recipe

1. 1.

   Export the week's signals. Pull the week's activity from Jira/Linear: completed and started issues, blocked items and their age, comments flagged as blockers, scope added mid-week. Add your context notes — five bullet points, typed from memory before you look at any AI output: what actually mattered this week, what you're worried about, what changed. Writing these first, unanchored, is deliberate.

2. 2.

   Generate the draft.

   Copy

   Draft a weekly status report for [AUDIENCE — e.g. "my director
   and peer leads"] from tracker activity plus my context notes.
   
   TRACKER ACTIVITY (facts about what moved):
   [PASTE EXPORT / SUMMARY]
   
   MY CONTEXT NOTES (meaning — these override activity where they
   conflict):
   [PASTE YOUR 5 BULLETS]
   
   Format:
   1. HEADLINE — one sentence: the week's single most important
      true thing.
   2. PROGRESS — 3-5 bullets, each tied to an outcome, not a
      ticket count. Mark any bullet supported only by tracker
      activity, without context-note confirmation, with [ACTIVITY
      ONLY] so I review it.
   3. RISKS & BLOCKERS — with age, owner, and what I need from
      the reader, if anything.
   4. STATUS CALLS — per workstream: green/amber/red WITH the
      one-line evidence. If evidence is thin, write "insufficient
      signal" — do not default to green.
   
   Rules: no adjectives doing the work of facts ("great
   progress"). No ticket IDs without a plain-language outcome.
   Nothing invented beyond the two inputs.
   

3. 3.

   Run the correction pass — meaning over activity. Good draft output looks like:

   Copy

   HEADLINE: Billing migration is code-complete but the launch
   date is at risk on partner-side testing.
   PROGRESS:
   - Migration behind flag in staging; 2 of 3 test suites green.
   - [ACTIVITY ONLY] 23 issues closed in checkout-web — mostly
     backlog cleanup per labels; excluded from progress claims.
   STATUS CALLS:
   - Payments: AMBER — partner test env unavailable 4 days.
   

   Now correct: every [ACTIVITY ONLY] bullet gets confirmed, reframed, or cut. Every status call gets your judgment — the tracker cannot see the client's mood, the engineer about to resign, or the dependency conversation that went badly. Add what no ticket recorded. This pass is ten minutes and it is the actual report.

4. 4.

   Check the ask. The most common failure of leader status reports is having no ask. If a risk needs a decision, a nudge, or air cover, the report says so explicitly, with a name and a date. If the model wrote "no support needed this week" and that's false, this is where you fix it.

5. 5.

   Send it as yours, and keep the receipts. File the tracker export and draft alongside the sent report. When a status call is challenged in three weeks — "you said green on the 12th" — you want the evidence trail of what was known when.

Make it yours

• Multiple teams rolling up: have each lead run this recipe, then run a second synthesis pass across their corrected reports — never across raw tracker data — so meaning is added at the level where it exists and the roll-up inherits corrected narrative, not aggregated noise.
• Client-facing delivery (services/GCC): produce a second variant for the client from the same corrected facts with internal detail removed — one source of truth, two framings — and never let the client version claim anything the internal version hedges.
• Linear/Jira automation-mature orgs: schedule the export and draft generation so Friday 3pm presents you a draft automatically — but wire the delivery to require your edit-and-send, keeping the human gate structural rather than habitual.

Quality check

• Every [ACTIVITY ONLY] item was resolved by a humancount them; a sent report still containing one means the correction pass was skipped.
• Status calls carry evidencea green without a reason is a hope; verify with the team before the report claims it, because they know which green is real.
• Ticket counts never masquerade as outcomes"closed 23 tickets" is activity; "checkout latency work done, p95 down 40%" is progress; the report contains only the second kind.
• The worry made it incompare the sent report to your pre-draft context notes; if your top concern got smoothed out by fluent prose, the model wrote your report after all.
• Consistency across weeks holdsa project that flips green-amber-green with no narrative explanation signals reporting noise; reread last week's report before sending this one.