agile-retro

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Retrospective

回顾会议

Use this skill to conduct a retrospective that transforms reflection into concrete improvement actions.

Initial context received via slash: $ARGUMENTS

$ARGUMENTS

is filled, use as reference (e.g., period, sprint, initiative, delivery). If empty, ask which period or delivery will be analyzed.

使用该Skill开展回顾会议，将反思转化为具体的改进行动。

通过斜杠命令接收的初始上下文：$ARGUMENTS

若

$ARGUMENTS

已填写，则将其作为参考信息（例如周期、迭代、项目举措、交付内容）。若为空，则询问需要分析的周期或交付内容。

Language

语言要求

Write the artifact in the user's language. Apply correct grammar and any required diacritics or script-specific characters. If the user's language is unclear, ask before generating output. Templates are in English — translate headers and content to match.

以用户使用的语言生成文档，确保语法正确，包含必要的变音符号或特定脚本字符。若用户使用的语言不明确，需先询问再生成内容。模板为英文版本——需将标题和内容翻译为匹配的语言。

Project root

项目根目录

This skill writes artifacts at paths relative to the project root (the repo where the work happens), not the agent's current working directory.

If invoked from inside the project, use the relative paths shown in this skill.
If invoked from another directory (e.g., a sibling repo, or when the project lives elsewhere), prepend
```
<project-root>/
```
to every artifact path.
When the project root is ambiguous, confirm with the user via the harness question tool before writing.

该Skill生成的文档路径为项目根目录（即工作所在的代码仓库）的相对路径，而非Agent当前的工作目录。

若从项目内部调用，使用本Skill中展示的相对路径。
若从其他目录调用（例如同级仓库，或项目位于其他位置），需在所有文档路径前添加
```
<project-root>/
```
。
若项目根目录不明确，需先通过harness问题工具与用户确认后再写入文档。

Prompting

提示规则

Follow the project-wide convention in

CLAUDE.md

AGENTS.md

("Skill Prompting Conventions"). Use the harness's structured-question tool —

AskUserQuestion

(Claude Code),

ask_user_question

(Codex), or

question

(OpenCode) — for the decision points below. Use free-form text only where a path/name/value cannot be enumerated.

Decision point	Why structured	Suggested options
Retro scope	Affects depth and template	Per-story · Per-sprint · Per-epic
Facilitation style	Shapes the prompts	Start-Stop-Continue · Mad-Sad-Glad · 4Ls · Free-form

Free-form prompts (no structured tool):

Participant notes
Improvement actions

No-pause mode: if the user has explicitly disabled mid-skill clarification, convert every structured prompt into an entry under Open questions (or equivalent) and proceed without blocking.

遵循

CLAUDE.md

AGENTS.md

中的项目级约定（"Skill Prompting Conventions"）。针对以下决策点，使用harness的结构化问题工具——Claude Code使用

AskUserQuestion

，Codex使用

ask_user_question

，OpenCode使用

question

。仅当路径/名称/值无法枚举时，才使用自由格式文本。

决策点	使用结构化工具的原因	建议选项
回顾范围	影响分析深度与模板选择	单故事 · 单迭代 · 史诗级需求
引导风格	决定提问方式	Start-Stop-Continue · Mad-Sad-Glad · 4Ls · 自由形式

自由格式提示（无需结构化工具）：

参会者笔记
改进行动

无暂停模式：若用户明确禁用Skill执行中的澄清环节，需将所有结构化提示转换为「开放式问题」（或等效条目）下的内容，无需等待反馈即可继续执行。

Objective

目标

Separate facts from opinions
Identify what worked and what didn't (and why)
Generate few clear actions with owner and deadline
Feed process improvement, not just historical memory
Reflect on delivery outcomes (what was planned vs what happened)

区分事实与观点
识别有效做法与问题（及原因）
生成少量清晰的、带有负责人与截止日期的行动项
推动流程改进，而非仅留存历史记录
反思交付成果（计划vs实际完成情况）

When to use

使用场景

A sprint or delivery cycle has ended
The team needs to reflect on what worked and what needs to change
Before starting the next sprint — retro feeds sprint planning
After closing a significant delivery (via
```
/agile-status
```
closure mode)
Per-delivery reflection (what the old
```
/post-impl
```
reflection covered)
Per-sprint reflection (standard retrospective)

迭代或交付周期结束后
团队需要反思有效做法与待改进事项时
下一个迭代开始前——回顾会议结果为迭代规划提供输入
重大交付完成后（通过
```
/agile-status
```
的关闭模式）
交付后反思（原
```
/post-impl
```
反思的覆盖内容）
迭代回顾（标准回顾会议）

When NOT to use

禁用场景

Mid-sprint status — use
```
/agile-status
```
(checkpoint mode) instead
Planning the next sprint — use
```
/agile-sprint
```
instead (but retro should feed into it)
Closing a delivery with verification — use
```
/agile-status
```
(closure mode) first, then retro
You need metrics/data — use
```
/agile-metrics
```
first, then retro

迭代中期状态更新——改用
```
/agile-status
```
（检查点模式）
规划下一个迭代——改用
```
/agile-sprint
```
（但回顾会议结果应作为输入）
带验证环节的交付关闭——先使用
```
/agile-status
```
（关闭模式），再开展回顾会议
需要指标/数据——先使用
```
/agile-metrics
```
，再开展回顾会议

Process

流程

1. Collect inputs

1. 收集输入信息

Consult:

Status closure reports from the period
Status checkpoints and consolidation reports
Sprint review (if it exists)
Sprint metrics (if it exists)
User or stakeholder feedback

参考：

当期的状态关闭报告
状态检查点与整合报告
迭代评审报告（若存在）
迭代指标（若存在）
用户或利益相关者反馈

2. Separate facts from opinions

2. 区分事实与观点

Facts: what happened (deliveries, blockers, deviations, metrics)
Perceptions: how the team/individual felt about the process

事实： 已发生的事件（交付内容、障碍、偏差、指标）
感知： 团队/个人对流程的感受

3. Analyze

3. 分析

What worked well: practices, tools, decisions that yielded results
What didn't work: what caused friction, delay, or rework
Why: root cause, not just symptom

有效做法： 产生成果的实践、工具、决策
问题点： 导致摩擦、延迟或返工的事项
原因： 根本原因，而非仅表面症状

4. Reflect on delivery outcomes

4. 反思交付成果

When running after a delivery closure:

What was planned vs what was delivered
Which decisions were right and which should change
What would you do differently next time
Technical debt or risks introduced

若在交付关闭后开展回顾会议：

计划交付vs实际交付的差异
正确的决策与需调整的决策
下次会采取的不同做法
引入的技术债务或风险

5. Define actions

5. 定义行动项

Limit to 2-3 actions per retro (focus > quantity)
Each action must have:
- Specific description
- Responsible owner
- Deadline
- How to verify the improvement happened

每次回顾会议限制2-3个行动项（聚焦优先于数量）
每个行动项必须包含：
- 具体描述
- 负责人
- 截止日期
- 验证改进效果的方式

6. Connect to next cycle

6. 关联下一个周期

How will these actions be observed in the next sprint/delivery?
Does any action become a backlog item?

这些行动项将如何体现在下一个迭代/交付中？
是否有行动项需要转化为待办事项？

Where to save

保存路径

```
planning/<initiative>/retro.md
```
if it's a retro for an initiative
```
planning/retros/retro-YYYY-MM-DD.md
```
if it's a sprint/period retro

若为项目举措的回顾会议：
```
planning/<initiative>/retro.md
```
若为迭代/周期的回顾会议：
```
planning/retros/retro-YYYY-MM-DD.md
```

Chaining

技能联动

If actions generate new tasks: suggest
```
/agile-story
```
or
```
/agile-epic
```
If actions change process or expose skill/template gaps: suggest
```
/agile-skill-feedback
```
If the cycle restarts: suggest
```
/agile-sprint
```

若行动项生成新任务：建议调用
```
/agile-story
```
或
```
/agile-epic
```
若行动项改变流程或暴露Skill/模板缺陷：建议调用
```
/agile-skill-feedback
```
若周期重启：建议调用
```
/agile-sprint
```

Reference template

参考模板

Use

templates/retro.md

from this skill as base.

以本Skill中的

templates/retro.md

为基础模板。

Rules

规则

Retro is not venting or meeting minutes. It's an improvement tool.
Actions must be specific and executable, not vague ("improve communication" is not an action).
Each action must have an owner. Action without owner won't happen.
Limit actions to 2-3 per retro. Many actions = none executed.
If the same action appears in consecutive retros, the problem is deeper — discuss root cause.

回顾会议不是发泄情绪或记录会议内容的工具，而是流程改进工具。
行动项必须具体可执行，不能模糊（例如“改进沟通”不属于有效行动项）。
每个行动项必须有负责人，无负责人的行动项无法落地。
每次回顾会议限制2-3个行动项，过多行动项会导致无法执行。
若同一行动项连续出现在多次回顾会议中，说明问题存在深层原因——需讨论根本原因。

Relationship with the flow

与工作流的关联

mermaid

flowchart LR
    A["/agile-status<br>(closure)"] --> B["/agile-retro"]
    B --> C[improvement actions]
    C --> D["/agile-sprint"]

This skill closes the feedback loop. For closing deliveries, use

/agile-status

(closure mode) first. For metrics data, use

/agile-metrics

first. The next cycle starts with

/agile-sprint

mermaid

flowchart LR
    A["/agile-status<br>(closure)"] --> B["/agile-retro"]
    B --> C[improvement actions]
    C --> D["/agile-sprint"]

该Skill闭环反馈流程。若要关闭交付，需先使用

/agile-status

（关闭模式）。若需要指标数据，需先使用

/agile-metrics

。下一个周期从

/agile-sprint

开始。