/
DE

⚡ Promptolis Original · Coding & Development

📈 Linear Project Status Narrator

Reads your Linear project + active issues + recent activity, writes the weekly status update stakeholders actually want to read — risks named, decisions surfaced, and the explicit asks that unblock you.

⏱️ 3 min to set up 🤖 ~75 seconds in Claude 🗓️ Updated 2026-04-28

Why this is epic

Most weekly status updates are unreadable: 47 ticket titles in a list, no narrative, no risks named, no asks. Stakeholders skim them and miss the actual blockers. This Original turns Linear data into a 5-paragraph narrative anyone can read in 90 seconds.

Outputs the ACTUAL update text — not a template. Includes: this week's progress, what's at risk, decisions needed, key metrics, and explicit asks. Calibrated to YOUR audience (engineers vs execs vs cross-functional).

Surfaces what your team is too close to see: stalled tickets, scope creep signals, deadline drift, dependencies blocking other work. The 'what to flag this week' section is the value.

Calibrated to 2026 Linear features: project status, milestones, sub-issues, project updates, the API + GraphQL access. Knows what the data means.

The prompt

Promptolis Original · Copy-ready
<role> You are a project-narrator with 6+ years writing weekly engineering status updates for cross-functional teams, execs, and boards. You have written 500+ status updates that actually got read. You know what stakeholders skim past, what they zoom into, and which signals are leading vs lagging. You are direct. You will tell a writer their update is buried in tickets, that the lead doesn't name the risk, or that they're hiding scope creep. You refuse to write status updates that say 'on track' when the data shows drift. </role> <principles> 1. Lead with risks, not progress. Stakeholders skim; lead matters most. 2. Audience calibration: engineers / execs / cross-func / board need different content. 3. Decisions needed are explicit. 'Need answer on X by Friday.' 4. Quantify with Linear data: velocity, cycle time, % done, blocker count. 5. Each week adds net-new. If nothing changed, say so. 6. 1-2 concrete numbers per update. Anchors credibility. 7. Write in the voice of the sender, not the team. </principles> <input> <project-context>{Linear project name, brief description, what 'done' looks like}</project-context> <audience>{engineers / execs / cross-functional / board / 'recommend'}</audience> <sender>{who's sending this — eng manager, PM, tech lead, etc.}</sender> <cadence>{weekly / fortnightly / monthly}</cadence> <linear-snapshot>{paste the relevant Linear data: total issues, completed, in-progress, blocked, stalled (no activity 7+d). Project status. Milestone progress. Recent changes.}</linear-snapshot> <this-week-progress>{what shipped, what was decided, what changed}</this-week-progress> <active-blockers>{tickets stuck, dependencies missing, decisions pending}</active-blockers> <key-decisions-pending>{decisions needed from stakeholders, with desired-by dates}</key-decisions-pending> <risks>{anything that could derail the timeline or scope}</risks> <previous-update-summary>{1-paragraph summary of last week's update — for net-new check}</previous-update-summary> </input> <output-format> # [Project Name] — Weekly Update [Date Range] ## TL;DR (3 lines max) Lead-with-risk-or-decision summary. Not 'on track' unless it actually is. ## Where We Are 2-3 paragraphs. Progress, what shipped, what we know now that we didn't last week. ## What's at Risk Named risks with severity (low/medium/high) and the next action to address each. Even if 'no risks,' say so explicitly with reasoning. ## Decisions Needed Explicit list. Each: question, who can decide, desired-by date, why this date. ## Key Numbers 3-6 quantitative anchors: % complete, velocity, cycle time, blocker count, days-to-milestone, customer impact, etc. ## What Changed Since Last Update The 3-5 net-new things. If nothing changed: state explicitly + reason. ## Asks Concrete asks of the audience. Not 'let me know if you have questions.' — actual asks. ## What We're Doing Next Week 3-5 specific items. ## Tone Calibration Notes A brief check: is this update's tone right for the audience? If wrong, adjust. </output-format> <auto-intake> If input incomplete: ask for project context, audience, sender, cadence, Linear snapshot, this-week progress, blockers, decisions pending, risks, previous update summary. </auto-intake> Now, write the status update:
🚀 Open in ChatGPT ✨ Open in Claude 💎 Open in Gemini

Example: input → output

Here's how this prompt actually performs. Real input below, real output from Claude Opus 4.

📝 Input
<project-context>Linear project: 'Q2 Mobile App Launch.' We're rebuilding our React Native mobile app on Expo with new auth + new payments + offline mode. Done = mobile app submitted to Apple + Google stores, marketing landing page live, internal team using.</project-context>
<audience>Cross-functional: 4 engineers (writing the code), 2 designers (design system + screens), 1 PM (me, sender), 1 head of product, 1 CEO, 1 marketing lead</audience>
<sender>Me — PM</sender>
<cadence>Weekly, sent Friday afternoons</cadence>
<linear-snapshot>
Project status: At Risk
Issues total: 84
Issues completed: 41 (49%)
Issues in progress: 18
Issues blocked: 4
Issues stalled (no activity 7+d): 6
Milestones:
  - 'Internal alpha' (target: April 30) — 76% complete
  - 'Beta to 50 users' (target: May 15) — 22% complete
  - 'App store submission' (target: May 30) — 5% complete
  - 'Public launch' (target: June 7) — 0% complete
Blockers:
  - LIN-481: Waiting on Apple App Store account approval (blocked 12 days)
  - LIN-503: Stripe payment integration blocked on Stripe SDK incompatibility with new Expo version
  - LIN-512: Offline mode requires backend API endpoint — backend team unconfirmed delivery
  - LIN-525: Marketing landing page blocked on design approval
</linear-snapshot>
<this-week-progress>Shipped: auth flow (login/signup/logout/password reset). Closed 9 issues. Demoed alpha to internal team Wednesday — got positive feedback. Decided to NOT support Apple Sign-in for v1 (saving 1 week of work). Marketing wrote first draft of landing page copy.</this-week-progress>
<active-blockers>Apple App Store account approval (12 days waiting — escalating to Apple support). Stripe SDK incompatibility (engineer evaluating fork-the-SDK vs delay payments to v1.1). Backend offline API endpoint (need confirm by Monday).</active-blockers>
<key-decisions-pending>1. Should we delay payments to v1.1 to ship on time? Need answer Monday from CEO + head of product. 2. Marketing landing page copy needs final approval from CEO by Wednesday. 3. Should we add app analytics SDK in v1 or v1.1?</key-decisions-pending>
<risks>Apple account approval is taking too long; if not resolved by April 28, we miss internal alpha. Stripe blocker means payments may slip — need fallback plan. Beta-to-50-users milestone (May 15) is at-risk because we haven't started recruiting beta users.</risks>
<previous-update-summary>Last week: 'On track for internal alpha. Auth flow 80% done. No major risks. Apple account approval pending. Decided to drop Android tablet support for v1.'</previous-update-summary>
🤖 Output

Q2 Mobile App Launch — Weekly Update (Apr 21-25)

TL;DR

Project status: At Risk. Apple App Store account approval has been pending 12 days and now threatens our April 30 internal alpha. Stripe payment integration blocked on SDK incompatibility. Need decisions from CEO + Head of Product by Monday on whether to defer payments to v1.1.

Where We Are

We shipped auth this week — login, signup, logout, password reset all working end-to-end. The internal-team alpha demo on Wednesday went well; team feedback was positive on UX flow but flagged we need polish on error states (specifically wrong-password and account-locked screens). Auth was the longest critical-path item; this unblocks payments + offline-mode work to start in parallel.

We're at 41 of 84 issues done (49%). Velocity has been stable at ~10 issues/week; if that holds, we'd land at ~71 issues in the 4 weeks before app-store submission, which is short of the 84-target. Two paths exist: cut scope (defer payments to v1.1 — see Decisions Needed) or accept a 1-week slip on App Store submission.

A quiet positive: we cut Apple Sign-in from v1 (saved ~1 week) without measurable user impact in the alpha test.

What's at Risk

  • HIGH: Apple App Store account approval (12 days waiting). If not resolved by April 28, we miss the April 30 internal alpha milestone. Action: escalating to Apple Developer Support today; if no response by Monday EOD, we open a Twitter/X public escalation (last-resort tactic that has worked for other companies).
  • HIGH: Stripe SDK incompatibility with new Expo version. Engineer evaluating: (a) fork the Stripe SDK + maintain a patch (~1 week), (b) defer payments to v1.1 (~0 effort, ships on time), (c) downgrade Expo (~2 weeks rework + risk). Decision needed Monday.
  • MEDIUM: Beta-to-50-users milestone (May 15). We haven't started beta-user recruitment. Marketing has written copy but no recruitment funnel. Action: marketing to launch beta-signup form by Friday next week.
  • LOW: Offline mode backend endpoint. Backend team has not confirmed delivery date. Action: alignment meeting with backend lead Monday.
  • STALLED: 6 issues without activity 7+ days. Eng team to triage during Monday standup — clean up or refocus.

Decisions Needed

1. Defer payments to v1.1 to protect on-time launch? Decided by: CEO + Head of Product. Desired by: Monday April 28 EOD. Rationale: blocks downstream engineering planning. If yes → engineering pivots payment-engineer to other work; if no → we accept ~1-week slip.

2. Marketing landing page copy approval. Decided by: CEO. Desired by: Wednesday April 30. Rationale: design + dev needs 1 week to ship the page before public launch.

3. App analytics SDK in v1 or v1.1? Decided by: Head of Product + me. Desired by: Friday May 2. Rationale: 2 days of work; needs to be in v1 if we want launch-week data; can slip to v1.1 if scope-pressured.

Key Numbers

  • 49% of issues complete (41 of 84)
  • Velocity: ~10 issues/week, stable
  • Days until internal alpha (April 30): 5 days; 76% milestone progress
  • Days until public launch (June 7): 43 days
  • Active blockers: 4 (1 external, 3 internal)
  • Stalled issues (>7d no activity): 6 — needs Monday triage

What Changed Since Last Update

Last week we said 'on track, no major risks.' Three things changed:

1. Apple account approval went from 'pending' (acceptable) to 'pending 12 days' (now critical-path blocker).

2. Stripe SDK incompatibility surfaced this week — was not on last week's radar.

3. Beta-user recruitment has not started; this is a self-inflicted risk we should have started 2 weeks ago.

Project status moved from 'On Track' to 'At Risk' to reflect these changes.

Asks

  • CEO + Head of Product: Monday meeting (15 min) to decide on payments-defer question. I'll send invite.
  • CEO: Wednesday: review + approve marketing landing page copy. Marketing has draft ready in [link].
  • Marketing lead: by Friday next week, beta-signup funnel live so we can recruit during the week of May 5.
  • Backend lead: Monday alignment meeting — confirm offline-mode endpoint delivery date.
  • All: flag if you see anything in the [Linear project view] that doesn't match this update.

What We're Doing Next Week

1. Resolve Stripe SDK situation (fork-vs-defer decision Monday)

2. Resolve Apple account escalation (Twitter/X public escalation if needed by Tuesday)

3. Triage 6 stalled issues during Monday standup

4. Polish auth error states (wrong-password, account-locked screens) per alpha feedback

5. Begin offline-mode integration (assuming backend confirms Monday)

6. Finalize marketing landing page copy

Tone Calibration Notes

This update is calibrated for cross-functional audience (mix of eng/design/product/CEO/marketing). It's slightly heavier on technical detail than an exec-only update would be, but lighter than an eng-team update. Specifically:

  • Numbers and milestones lead (good for execs + product)
  • Stripe SDK detail kept brief (engineering knows the detail; others need just enough to weigh in on the decision)
  • Marketing implications surfaced (good for marketing lead)
  • Asks are addressed by name to specific people (better than general 'team needs to decide')

If I were sending only to engineers, I'd add Stripe SDK technical detail. If only to CEO, I'd cut to TL;DR + Decisions Needed only.

Common use cases

  • Eng manager writing weekly project updates to product + execs
  • PM writing fortnightly stakeholder updates that don't get ignored
  • Solo founder updating investors on engineering progress
  • Tech lead writing release-readiness updates to QA + ops + sales
  • Eng director writing portfolio-level status across multiple projects
  • Engineer writing async daily standup updates that surface real signal

Best AI model for this

Claude Sonnet 4.5 or Opus 4. Status writing is a synthesis task — Sonnet handles fluently; Opus polishes for high-stakes exec audiences.

Pro tips

  • Audience calibration changes everything. The same project gets different updates for engineers (technical detail) vs execs (timeline + risk) vs cross-functional (impact on their work).
  • Lead with risks, not progress. Stakeholders skim; risks at the top get seen. 'Project on track' as the lead tells them they can stop reading.
  • Name decisions needed explicitly. 'Need answer on X by Friday' beats 'pending decision on X.'
  • Quantify everything. '47 of 60 issues complete' beats 'mostly done.' Use Linear's velocity + cycle-time data when relevant.
  • Write the update in the voice of the person who'll send it, not the team. Stakeholders read the sender's POV.
  • Don't repeat last week's update. Each week should add net-new info. If nothing changed, say so explicitly.
  • Include 1-2 concrete numbers per update — velocity, cycle time, percent done, customer impact. Numbers anchor credibility.

Customization tips

  • Specify your audience precisely. 'Cross-functional' is too vague — list the specific roles. Updates calibrate to the most senior reader.
  • Paste your Linear data — at least: total issues, % complete, blocked, stalled, milestones with target dates. Without numbers, the update is opinion not data.
  • Always include last week's update summary. The 'what changed since last update' section is what stakeholders actually want to know.
  • List explicit asks with names + dates. 'Need feedback' is too vague; 'CEO to decide on X by Monday' is what gets done.
  • Don't soften risks. If something is 'high' risk, lead with it. Hidden risks become surprises that erode trust.
  • Use the Executive Audience Mode variant for CEO/board updates — it strips technical detail and emphasizes timeline + asks.

Variants

Engineering Audience Mode

For status updates to engineers — emphasizes technical risks, dependency chains, code/architecture decisions.

Executive Audience Mode

For exec/CEO updates — emphasizes timeline, business impact, asks. Strips technical detail unless decision-relevant.

Cross-Functional Mode

For Product+Design+Eng+QA stakeholders — emphasizes how progress affects each function's work.

Investor / Board Mode

For board updates — emphasizes runway-relevant signals, key milestones, hiring/scaling implications.

Frequently asked questions

How do I use the Linear Project Status Narrator prompt?

Open the prompt page, click 'Copy prompt', paste it into ChatGPT, Claude, or Gemini, and replace the placeholders in curly braces with your real input. The prompt is also launchable directly in each model with one click.

Which AI model works best with Linear Project Status Narrator?

Claude Sonnet 4.5 or Opus 4. Status writing is a synthesis task — Sonnet handles fluently; Opus polishes for high-stakes exec audiences.

Can I customize the Linear Project Status Narrator prompt for my use case?

Yes — every Promptolis Original is designed to be customized. Key levers: Audience calibration changes everything. The same project gets different updates for engineers (technical detail) vs execs (timeline + risk) vs cross-functional (impact on their work).; Lead with risks, not progress. Stakeholders skim; risks at the top get seen. 'Project on track' as the lead tells them they can stop reading.

Explore more Originals

Hand-crafted 2026-grade prompts that actually change how you work.

← All Promptolis Originals
P

Curated by

Every Promptolis Original is hand-crafted and reviewed before publishing — built from scratch for 2026-grade LLMs.

Last reviewed on · About Promptolis