create-stakeholder-update

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Create Stakeholder Update

生成利益相关者更新文档

Overview

概述

Generate a stakeholder update using the BLUF (Bottom Line Up Front) communication pattern. The update leads with the most important information, uses traffic light status indicators per workstream, and clearly separates FYI items from items that need a decision. Reads project context from docs, git activity, and existing artifacts to ground the update in facts.

采用BLUF（Bottom Line Up Front，开门见山）沟通模式生成利益相关者更新文档。更新内容将最重要的信息放在最前面，为每个工作流使用交通灯状态指示器，并清晰区分仅供参考（FYI）的事项和需要决策的事项。通过读取文档、Git活动记录和现有工件来获取项目上下文，确保更新内容基于事实。

Workflow

工作流程

Read project context — Scan available sources for current state:
- ```
.chalk/docs/product/
```
  for PRDs, roadmaps, stakeholder updates, and retros
- ```
.chalk/docs/engineering/
```
  for architecture docs, incident reports, and postmortems
- ```
.chalk/docs/ai/
```
  for any analysis or research documents
- Check for a product profile (
```
0_product_profile.md
```
  ) to understand project scope
- If previous stakeholder updates exist, read the most recent one for continuity
Check recent activity — Use
```
Bash
```
to review recent git log for commits, merged PRs, and release tags within the update period. This grounds the "Key Accomplishments" section in actual work, not aspirations.
Parse the update scope — From
```
$ARGUMENTS
```
, identify the project, time period, and intended audience. If the audience is unclear, default to executive stakeholders (concise, outcome-focused, no jargon).
Write the BLUF summary — Draft 2-3 sentences that answer: "What does the reader need to know RIGHT NOW?" This is the most important section. A stakeholder who reads nothing else should understand the project status from these sentences alone.
Assign traffic light status — For each workstream or major initiative:
- Green: On track, no blockers, progressing as planned
- Yellow: At risk, minor blockers or delays, needs monitoring
- Red: Off track, major blockers, needs immediate attention or decision Each status must include a one-line explanation. Never use green for everything unless genuinely warranted.
Separate risks into FYI and Needs Decision — Every risk or blocker must be categorized:
- FYI: Stakeholders should be aware, but no action is needed from them
- Needs Decision: A specific decision is required, with a clear question and a recommended option
Include metrics — If a metrics framework exists in the docs, include a metrics snapshot showing current values against targets. If no framework exists, note that metrics tracking is not yet established.
Determine the next file number — List files in
```
.chalk/docs/product/
```
to find the highest numbered file. Increment by 1.

Write the file — Save to

.chalk/docs/product/<n>_stakeholder_update_<date>.md

Confirm — Present the update with the BLUF summary and any items that need decisions highlighted.

读取项目上下文 — 扫描可用资源以了解当前状态：
- ```
.chalk/docs/product/
```
  目录下的PRD、路线图、利益相关者更新文档和回顾文档
- ```
.chalk/docs/engineering/
```
  目录下的架构文档、事件报告和事后分析文档
- ```
.chalk/docs/ai/
```
  目录下的任何分析或研究文档
- 查找产品配置文件（
```
0_product_profile.md
```
  ）以了解项目范围
- 如果存在过往的利益相关者更新文档，读取最新的一份以保持内容连贯性
检查近期活动 — 使用
```
Bash
```
查看更新周期内的近期Git日志，包括提交记录、已合并的PR和发布标签。这能让“关键成果”部分基于实际工作，而非预期目标。
解析更新范围 — 从
```
$ARGUMENTS
```
中确定项目、时间周期和目标受众。如果受众不明确，默认面向高管利益相关者（内容简洁、聚焦成果、无专业术语）。
撰写BLUF摘要 — 起草2-3句话，回答：“读者现在需要知道什么？”这是最重要的部分。即使读者只看这部分，也应该能从这些句子中了解项目状态。
分配交通灯状态 — 为每个工作流或重大举措分配状态：
- 绿色：按计划推进，无阻碍，进展符合预期
- 黄色：存在风险，有轻微阻碍或延迟，需要监控
- 红色：偏离计划，存在重大阻碍，需要立即关注或决策每个状态必须包含一行说明。除非确实所有事项都进展顺利，否则不要全部标记为绿色。
将风险分为仅供参考和需要决策两类 — 所有风险或阻碍必须分类：
- 仅供参考（FYI）：利益相关者需要知晓，但无需采取行动
- 需要决策：需要做出具体决策，包含明确的问题和推荐选项
包含指标数据 — 如果文档中存在指标框架，包含显示当前值与目标值对比的指标快照。如果没有指标框架，需注明尚未建立指标跟踪机制。
确定下一个文件编号 — 列出
```
.chalk/docs/product/
```
目录下的文件，找到编号最高的文件，将编号加1。

写入文件 — 保存至

.chalk/docs/product/<n>_stakeholder_update_<date>.md

。

确认 — 展示更新文档，突出显示BLUF摘要和所有需要决策的事项。

Update Structure

更新文档结构

markdown

undefined

markdown

undefined

Stakeholder Update: <Project/Team Name>

Period: <start date> to <end date> Date: <YYYY-MM-DD> Author: <role>

BLUF (Bottom Line Up Front)

<2-3 sentences. What does the reader need to know RIGHT NOW? Lead with the most critical information. If there is a decision needed, state it here.>

Status Overview

Workstream	Status	Summary
<workstream 1>	:green_circle: Green	<one-line explanation>
<workstream 2>	:yellow_circle: Yellow	<one-line explanation>
<workstream 3>	:red_circle: Red	<one-line explanation>

Workstream	Status	Summary
<workstream 1>	:green_circle: Green	<one-line explanation>
<workstream 2>	:yellow_circle: Yellow	<one-line explanation>
<workstream 3>	:red_circle: Red	<one-line explanation>

Key Accomplishments (Past Period)

<Accomplishment with concrete outcome, not just activity>
<Accomplishment tied to a deliverable, metric, or milestone>

<Accomplishment with concrete outcome, not just activity>
<Accomplishment tied to a deliverable, metric, or milestone>

Upcoming Milestones (Next Period)

Milestone	Target Date	Confidence	Notes
<milestone>	<YYYY-MM-DD>	High / Medium / Low	<context>

Milestone	Target Date	Confidence	Notes
<milestone>	<YYYY-MM-DD>	High / Medium / Low	<context>

Risks & Blockers

FYI (Awareness Only)

<Risk or issue the stakeholder should know about, but no action is required from them>

<Risk or issue the stakeholder should know about, but no action is required from them>

Needs Decision

Decision Needed	Options	Recommendation	Deadline
<specific question>	<Option A / Option B>	<recommended option with rationale>	<by when>

Decision Needed	Options	Recommendation	Deadline
<specific question>	<Option A / Option B>	<recommended option with rationale>	<by when>

Metrics Snapshot

Metric	Previous	Current	Target	Trend
<metric>	<value>	<value>	<target>	Improving / Stable / Declining

undefined

Metric	Previous	Current	Target	Trend
<metric>	<value>	<value>	<target>	Improving / Stable / Declining

undefined

Output

反模式（需避免的做法）

File:

.chalk/docs/product/<n>_stakeholder_update_<date>.md

Format: Plain markdown, no YAML frontmatter

First line:

# Stakeholder Update: <Project/Team Name>

隐藏关键信息 — 如果项目偏离轨道或需要决策，该信息必须出现在前两句话中，而不是埋在末尾的“风险”部分。利益相关者通常只会浏览内容。BLUF模式的存在就是为了确保他们不会错过关键信息。
无交通灯状态 — 仅列出更新内容而无明确的状态指示器，会迫使读者自行判断情况好坏。每个工作流都必须标记为绿色、黄色或红色。无例外，不存在“视情况而定”。
仅含仅供参考内容、无决策事项的更新 — 如果每次更新都只是“一切顺利，仅告知”，利益相关者会停止阅读。如果确实无需决策，需包含前瞻性风险或即将到来的决策点。
无指标的进展报告 — “我们在后端取得了很大进展”是无法验证的。“后端API覆盖了计划端点的85%（目标：3月15日前达到100%）”则是具体的。需将成果与可衡量的结果挂钩。
全绿色状态 — 当存在已知风险或延迟时，仍将所有工作流报告为绿色，会损害信任。利益相关者更看重诚实。带有缓解计划的黄色状态，远好于之后突然变成红色的绿色状态。
报告活动而非成果 — “我们开了15次会议，审核了30个PR”描述的是活动。“发布了认证模块，将登录延迟降低了40%”描述的是成果。利益相关者关心的是成果。
与过往更新无连贯性 — 每次更新应隐含参考上一次更新：之前列出的即将到来的里程碑现在应作为成果出现（如果未达成，需解释原因）。利益相关者会注意到那些突然消失的事项。

Anti-patterns

—

Burying the lead — If the project is off track or needs a decision, that information must be in the first two sentences, not buried in a "Risks" section at the bottom. Stakeholders skim. The BLUF exists so they cannot miss the critical information.
No traffic light status — Listing updates without a clear status indicator forces the reader to interpret whether things are good or bad. Every workstream gets a Green, Yellow, or Red. No exceptions, no "it depends."
FYI-only updates with no decisions — If every update is "everything is fine, just keeping you informed," stakeholders stop reading. If there are genuinely no decisions needed, include forward-looking risks or upcoming decision points.
Progress without metrics — "We made great progress on the backend" is unverifiable. "Backend API coverage reached 85% of planned endpoints (target: 100% by March 15)" is concrete. Tie accomplishments to measurable outcomes.
All-green status — Reporting all workstreams as green when there are known risks or delays erodes trust. Stakeholders respect honesty. A yellow with a mitigation plan is far better than a green that becomes a surprise red next period.
Activity reporting instead of outcomes — "We had 15 meetings and reviewed 30 PRs" describes activity. "Shipped the authentication module and reduced login latency by 40%" describes outcomes. Stakeholders care about outcomes.
No continuity with previous updates — Each update should reference the previous one implicitly: milestones that were upcoming should now appear as accomplishments (or be explained if missed). Stakeholders notice when items silently disappear.

—