standup-meeting

站会

当任务是将模糊的日常协作转化为一个坦诚的节奏决策、一份小型证据包和一条后续跟进路径时，使用此技能。

standup-meeting 负责：

• 日常协作节奏的真实情况
• 在有充分理由举行定期同步时选择站会模式
• 阻塞项 / 交接事项的可见性
• 简短的引导流程和更新模板
• 明确区分核心同步和后续小型讨论会
• 防止站会沦为形式主义的防护措施
• 在每日仪式缺乏合理性时，明确选择 less-frequent / no recurring standup

遇到特殊情况或请求开始偏离主题时，请先阅读以下参考资料：

• references/cadence-gates-and-exceptions.md
• references/facilitation-modes.md
• references/intake-packets-and-route-outs.md

何时使用此技能

• 用户要求提供每日站会、每日 Scrum、每日同步或异步签到的形式。
• 团队需要先决定每日实时同步是否仍有必要，再选择看板走查、阻塞项优先、异步、混合或经典三问式站会。
• 每日仪式耗时过长、偏离主题沦为状态汇报，或引发太多旁支讨论。
• 远程或混合办公团队需要一种更轻量的方式来协调阻塞项和交接事项。
• 发布 / 里程碑 / 紧急处理阶段可能需要临时采用每日节奏，即使平时更适合轻量方式。
• 最合适的后续产物是**《协作节奏简报》**，其中包含一个节奏决策、一种模式（如有）和一条升级路径。

何时不使用此技能

• 实际任务是拆解待办事项、准备 Sprint 或切分为可执行任务 → task-planning。
• 实际任务是评估规模、表达信心程度或处理产能分歧 → task-estimation。
• 实际任务是回顾流程、处理反复出现的仪式负担，或跟进交付后的行动项 → sprint-retrospective。
• 实际任务是停机事件指挥、发布战情室或事件分诊 → 调试 / 事件 / 发布专用技能。
• 用户主要想收集面向管理者的状态信息或进行绩效汇报。此技能用于平级协作，而非向上表演。

说明

步骤 1：先判断节奏，再在需要时选择一个主要模式

提出任何形式建议前，先规范化请求。

standup_intake:
  cadence_decision: live-daily | async-daily | hybrid-daily | less-frequent-sync | no-recurring-standup
  primary_mode: board-walk | blocker-first | async-check-in | hybrid-async-plus-live | classic-three-questions | none
  team_shape: colocated | hybrid | distributed | cross-functional | unknown
  work_source: jira | linear | github-projects | trello | docs | hacknplan | mixed | unknown
  main_problem:
    - blockers-hidden
    - too-long
    - status-theater
    - timezone-friction
    - board-stale
    - too-many-side-discussions
    - low-dependency-work
    - ritual-inertia
    - unclear
  current_signal: strong-board | weak-board | weak-updates | mixed | unknown
  delivery_risk: low | medium | high
  escalation_need: low | medium | high | unknown
  output_shape: coordination-cadence-brief | template-only | facilitation-reset | unknown

每次运行只能选择一个节奏决策：

• live-daily — 当前阻塞项 / 依赖压力足以证明每日实时同步有必要
• async-daily — 每日信息可见性仍然重要，但实时参会成本过高
• hybrid-daily — 每日书面更新；实时讨论仅用于特殊情况
• less-frequent-sync — 定期检查点仍有帮助，但每日同步没有必要
• no-recurring-standup — 相较于仪式化的每日同步，看板 / 文档可见性加临时升级处理更合适

只有在节奏仍包含定期站会形式时，才选择一个主要模式：

• board-walk — 对话应以看板为主线
• blocker-first — 今天的主要任务是尽快发现阻碍并协调帮助
• async-check-in — 默认采用书面更新，实时讨论为可选
• hybrid-async-plus-live — 先确保书面信息可见，再通过简短的实时讨论处理升级事项
• classic-three-questions — 仅适用于团队规模较小且这种形式仍能提供有用信息的情况
• none — 最佳选择为 no-recurring-standup 时使用

不要把多种节奏决策或模式混在一起，给出含糊不清的答案。

第 2 步：收集最小但可信的协调信息包

使用 references/intake-packets-and-route-outs.md。

最低限度的信息包：

• 当前看板／问题跟踪器／文档来源
• 正在进行和受阻的工作
• 近期交付目标或冲刺目标（如已知）
• 明显的交接或依赖关系
• 时区／混合办公限制（如相关）
• 看板是否可信、过时，或缺少关键工作

如果证据不足，应降低置信度，而不是凭空编造确定性结论。

第 3 步：判断是否有必要采用每日节奏，然后选择仍能发现风险的最轻量模式

默认节奏规则：

• 阻塞频繁、依赖关系密集，或面临发布／里程碑／事件压力 → live-daily
• 每日可见性很重要，但实时重叠成本较高 → async-daily
• 书面更新加上仅针对例外情况的短会最合适 → hybrid-daily
• 工作大多相互独立、周期跨多日，或已通过完善的产物充分展示 → less-frequent-sync
• 看板／文档维护良好，且阻塞应立即升级处理，而不是留到例行会议 → no-recurring-standup

如果节奏仍足以支持站会，则按以下规则选择模式：

• 看板可信 + 多项工作正在进行 → board-walk
• 受阻工作或依赖压力占主导 → blocker-first
• 时区分布或对专注时间的影响占主导 → async-check-in
• 团队希望通过书面方式保持可见性，并仅针对例外情况进行短会 → hybrid-async-plus-live
• 小型同地办公团队，仍能传递高信号，仪式感也没有偏移 → classic-three-questions

如果看板已过时，应将其列为诊断内容。站会无法长期弥补事实来源失效的问题。 如果团队只需暂时提高频率，应明确说明：在风险窗口内采用每日模式，然后复查是否应降低频率。

第 4 步：如果节奏仍包含同步会议，则控制核心会议时长

如果节奏为 live-daily、async-daily、hybrid-daily 或 less-frequent-sync：

• 如有实时核心会议，时长最多为 10-15 分钟
• 聚焦工作进展、阻塞、交接和近期交付风险
• 将深入的问题解决安排到仅邀请相关人员参加的后续小会
• 面向团队和工作交流，而不是向上级管理层汇报
• 如果看板、任务单维护或更新纪律本身就是阻塞，应明确指出

如果节奏为 no-recurring-standup：

• 说明由什么产物或频道取代例行会议
• 明确立即处理阻塞问题的升级触发条件
• 说明风险再次上升时何时重新评估节奏

第 5 步：生成一份协调节奏简报

返回一份精简的信息包，不要写成通用敏捷教程。

# Coordination Cadence Brief

## Recommended cadence
- Cadence:
- Why this cadence fits:
- Review trigger:

## Recommended mode
- Mode:
- Why this mode fits:

## Goal for this coordination loop
- ...

## Evidence used
- Work source:
- Strongest signals:
- Missing but important:

## Core facilitation flow or replacement path
1. ...
2. ...
3. ...

## What each person should report or update
- ...

## Blocker / handoff routing
- Keep in core sync:
- Escalate immediately when:
- Move to follow-up huddle:
- Who should stay after:

## Template
```text
...

应避免的反模式

• ...
• ...

相邻交接

• 在……时使用 task-planning
• 在……时使用 task-estimation
• 在……时使用 sprint-retrospective

### Step 6: Tailor the packet to the chosen mode or no-meeting outcome
Use [references/intake-packets-and-route-outs.md](references/intake-packets-and-route-outs.md) for stable packet shapes.

Mode reminders:
- **board-walk** — review blocked, aging, in-progress, and ready-for-review work before asking for personal diaries
- **blocker-first** — name owner, missing input, and next action quickly; do not solve the blocker in the room
- **async-check-in** — prefer prompts like “What moved?”, “What is stuck?”, and “What needs help today?” over ritualized filler
- **hybrid-async-plus-live** — treat written updates as the base layer and the live sync as escalation only
- **classic-three-questions** — keep only if it still stays short, lateral, and work-focused
- **none** — say which board/doc/channel replaces the ritual and exactly when the team should pull an ad hoc huddle

### Step 7: Route adjacent PM work explicitly
Before finalizing, say when the next job changed:
- use `task-planning` for backlog cleanup, sprint prep, or scope slicing
- use `task-estimation` for effort, confidence, or capacity disputes
- use `sprint-retrospective` when repeated daily-sync pain should become a process change
- do **not** turn this skill into roadmap planning, status theater, or incident command

## Output format
Always return a **Coordination Cadence Brief** with these qualities:
- exactly one cadence decision
- exactly one primary mode or `none`
- one small evidence packet
- explicit separation between core sync and follow-up huddle when a sync exists
- explicit replacement path when the answer is `no-recurring-standup`
- visible blocker / handoff routing
- short reusable template
- clear route-outs to the rest of the PM cluster when the job changes

## Examples

### Example 1: Overlong sprint standup
**Input**
> Tomorrow’s standup keeps running 25 minutes because everyone gives long updates. We have two blockers and one item waiting for review.

**Good output direction**
- cadence: `live-daily`
- mode: `board-walk` or `blocker-first`
- blocked and in-progress work comes first
- follow-up huddle only for the blocked items
- anti-pattern callout: no round-robin biographies

### Example 2: Distributed team
**Input**
> We have engineers in California, Europe, and Korea. Should our daily standup be async?

**Good output direction**
- cadence: `async-daily` or `hybrid-daily`
- mode: `async-check-in` or `hybrid-async-plus-live`
- written template centered on movement, blockers, and help needed
- explicit escalation path for urgent coordination

### Example 3: Manager-facing status theater
**Input**
> Our daily scrum feels like reporting to the manager. Fix it without changing our whole process.

**Good output direction**
- cadence may stay `live-daily`, but the answer must justify it rather than assume it
- mode: `board-walk` or `blocker-first`
- names status theater directly
- keeps the sync lateral and work-focused
- routes recurring ceremony pain to `sprint-retrospective`

### Example 4: Daily ritual no longer justified
**Input**
> Most of our work is independent and already tracked in Linear. The daily standup feels like obligation, not coordination. Should we keep it?

**Good output direction**
- cadence: `less-frequent-sync` or `no-recurring-standup`
- mode: `none` if the ritual should disappear
- replacement path uses board hygiene plus explicit blocker escalation
- review trigger says when the team should re-introduce temporary daily cadence

## Best practices
1. **Optimize for work movement, not recital** — the ritual should clarify today’s coordination job.
2. **Justify cadence before format** — first decide whether daily is warranted at all.
3. **Choose the lightest mode that still catches risk** — not every team needs the same ceremony weight.
4. **Triage blockers in the sync, solve them elsewhere** — follow-up huddles are a feature, not a failure.
5. **Protect maker time** — async or hybrid modes often beat default live meetings for distributed teams.
6. **Treat source-of-truth hygiene as a first-class issue** — stale boards and missing updates are real blockers.
7. **Route repeated pain outward** — planning, estimation, retrospectives, and incident work are different jobs.

## References
- Scrum Guide — https://scrumguides.org/scrum-guide.html
- Scrum.org, *What is a Daily Scrum?* — https://www.scrum.org/resources/what-is-a-daily-scrum
- Atlassian, *Standups for agile teams* — https://www.atlassian.com/agile/scrum/standups
- GitLab Handbook, *Asynchronous communication* — https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous/
- Martin Fowler / Jason Yip, *It’s Not Just Standing Up* — https://martinfowler.com/articles/itsNotJustStandingUp.html