retro

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Retro

回顾

Generate a personal or team engineering retrospective from One Horizon.

基于One Horizon生成个人或团队工程回顾。

Instructions

使用说明

1. Pick scope and window

1. 选择范围和时间窗口

Default to the last
```
7d
```
.
Accept
```
24h
```
,
```
7d
```
,
```
14d
```
, and
```
30d
```
.
Accept
```
compare
```
to compare the current window against the immediately prior same-length window.
Default to team scope.
If the user asks about "team", "engineering", "sprint", or "what did we ship", use team scope.
If the user explicitly asks for a personal retro, use personal scope.
If team scope is needed and the team is not explicit, resolve it from
```
list-my-teams
```
.
If
```
list-my-teams
```
returns exactly one team, use it.
If multiple teams are available and the request does not identify one, ask the user which team the retro should cover before continuing.
Always report exact start and end dates in the user's local timezone.

默认选择最近
```
7d
```
的数据。
支持
```
24h
```
、
```
7d
```
、
```
14d
```
、
```
30d
```
几种时间窗口。
支持
```
compare
```
参数，用于将当前窗口数据与上一个同等长度的窗口数据做对比。
默认使用团队范围。
如果用户提问包含「团队」、「工程」、「sprint」或「我们交付了什么」，使用团队范围。
如果用户明确要求个人回顾，使用个人范围。
如果需要使用团队范围但未明确指定团队，通过
```
list-my-teams
```
接口解析团队。
如果
```
list-my-teams
```
仅返回一个团队，直接使用该团队。
如果存在多个可选团队且请求未指定具体团队，先询问用户本次回顾覆盖的团队再继续处理。
始终以用户本地时区展示准确的起止日期。

2. Gather source data from One Horizon

2. 从One Horizon拉取源数据

Use One Horizon as the source of truth. Do not fall back to git unless the user explicitly asks for repository-level metrics too.

For personal scope, fetch:

json

my-work-recap({
  "startDate": "<iso-start>",
  "endDate": "<iso-end>"
})

json

list-completed-work({
  "startDate": "<iso-start>",
  "endDate": "<iso-end>"
})

json

list-planned-work()

json

list-blockers()

For team scope:

Resolve the team with
```
list-my-teams
```
or
```
find-team-member
```
if the user named a person.
Fetch:

json

team-work-recap({
  "teamId": "<teamId>",
  "startDate": "<iso-start>",
  "endDate": "<iso-end>"
})

json

list-completed-work({
  "teamId": "<teamId>",
  "startDate": "<iso-start>",
  "endDate": "<iso-end>"
})

json

list-planned-work({ "teamId": "<teamId>" })

json

list-blockers({ "teamId": "<teamId>" })

For per-person analysis, use the team member list from

list-my-teams

, then fetch member-level work only for contributors active in the window or people called out by the user:

json

list-completed-work({
  "teamId": "<teamId>",
  "userId": "<userId>",
  "startDate": "<iso-start>",
  "endDate": "<iso-end>"
})

json

list-planned-work({
  "teamId": "<teamId>",
  "userId": "<userId>"
})

json

list-blockers({
  "teamId": "<teamId>",
  "userId": "<userId>"
})

Use

get-task-details

only for the biggest ships, ambiguous task titles, or to extract richer

Products

Goals

, components, and labels for hotspot analysis.

以One Horizon作为唯一数据源，除非用户明确要求同时提供仓库级别指标，否则不要回退使用git数据。

个人范围下需要拉取：

json

my-work-recap({
  "startDate": "<iso-start>",
  "endDate": "<iso-end>"
})

json

list-completed-work({
  "startDate": "<iso-start>",
  "endDate": "<iso-end>"
})

json

list-planned-work()

json

list-blockers()

团队范围下：

如果用户指定了具体人员，通过
```
list-my-teams
```
或
```
find-team-member
```
解析对应团队。
拉取以下数据：

json

team-work-recap({
  "teamId": "<teamId>",
  "startDate": "<iso-start>",
  "endDate": "<iso-end>"
})

json

list-completed-work({
  "teamId": "<teamId>",
  "startDate": "<iso-start>",
  "endDate": "<iso-end>"
})

json

list-planned-work({ "teamId": "<teamId>" })

json

list-blockers({ "teamId": "<teamId>" })

如果需要做人员维度分析，使用

list-my-teams

返回的团队成员列表，仅拉取时间窗口内活跃的贡献者或用户指定人员的个人维度工作数据：

json

list-completed-work({
  "teamId": "<teamId>",
  "userId": "<userId>",
  "startDate": "<iso-start>",
  "endDate": "<iso-end>"
})

json

list-planned-work({
  "teamId": "<teamId>",
  "userId": "<userId>"
})

json

list-blockers({
  "teamId": "<teamId>",
  "userId": "<userId>"
})

仅当需要查看核心交付项、模糊任务标题详情，或提取更丰富的「产品」、「目标」、组件、标签用于热点分析时，才调用

get-task-details

接口。

3. Compute retro metrics

3. 计算回顾指标

Build a summary table with the strongest available One Horizon signals:

Metric	Meaning
Completed items	Total completed work in the window
Contributors	Distinct people with completed work
Initiatives advanced	Completed items linked to initiatives or initiative work surfaced in recap
Bugs fixed	Bug tasks or work explicitly marked `isBugFix`
Planned still open	Current planned work not finished yet
Current blockers	Open blocked items now
Active days	Distinct completion dates in the window
Throughput/day	Completed items divided by active days
Interrupt ratio	Bug fixes or reactive work divided by completed items
Quality investment ratio	Test, refactor, docs, or hardening work divided by completed items

For code-quality metrics, prefer explicit booleans such as

isBugFix

isTest

isDocumentation

isRefactor

, and

isNewFeature

when present. If they are missing, infer conservatively from task type, title, and labels, and say the metric is inferred.

Also derive:

Delivery mix: feature vs bug vs refactor/test/docs/chore work.
Plan completion: completed work vs still-open planned work.
Hot areas: most common products, components, or goals from task labels/details.
Carryover: planned or blocked items that are still open at the end of the window.
Biggest ships: 1-3 highest-impact completed items by scope, size of description, linked initiative importance, or repeated mentions across recap data.

基于One Horizon提供的最可靠信号构建汇总表：

指标	含义
完成项	时间窗口内完成的总工作项
贡献者	有完成工作的不同人员数量
推进的项目	关联到业务initiative或在工作recap中展示的initiative相关完成项
修复的Bug	Bug任务或明确标记为 `isBugFix` 的工作
未完成的计划项	当前仍未完成的计划内工作
当前阻塞项	目前处于阻塞状态的未完结项
活跃天数	时间窗口内有工作交付的不同天数
日吞吐量	完成项总数除以活跃天数
中断占比	Bug修复或响应式工作占完成项的比例
质量投入占比	测试、重构、文档或加固类工作占完成项的比例

代码质量相关指标优先使用明确的布尔标记，比如存在

isBugFix

、

isTest

、

isDocumentation

、

isRefactor

、

isNewFeature

标记时直接使用。如果缺少这些标记，从任务类型、标题、标签保守推断，并明确标注该指标为推断值。

同时需要推导以下内容：

交付结构：功能开发、Bug修复、重构/测试/文档/杂项工作的占比分布。
计划完成率：已完成工作对比仍未完结的计划内工作。
热点领域：任务标签/详情中出现频次最高的产品、组件或目标。
遗留项：时间窗口结束时仍未完结的计划内或阻塞项。
核心交付：按范围、描述篇幅、关联initiative重要性或recap数据中重复提及程度筛选出的1-3个最高影响力完成项。

4. Build team-aware analysis

4. 构建适配团队的分析

For each active contributor, compute:

Completed count
Bugs fixed
Initiative-related work
Quality investment share
Top areas from products/components/goals
Biggest ship in the window

Write 2-4 sentences per person:

```
What they shipped
```
: concrete summary of their work and focus areas.
```
Praise
```
: 1-2 specific strengths anchored in actual completed items.
```
Growth area
```
: 1 concrete investment suggestion anchored in the data, framed as leveling up rather than criticism.

If only one person contributed, skip the team breakdown and write a deeper personal section instead.

为每个活跃贡献者计算：

完成项数量
修复的Bug数量
关联initiative的工作占比
质量投入占比
负责的核心领域（产品/组件/目标维度）
时间窗口内的核心交付

为每个人撰写2-4句话的分析：

```
交付内容
```
：具体总结其工作内容和聚焦领域。
```
亮点
```
：基于实际完成项总结1-2个具体优势。
```
成长方向
```
：基于数据给出1个具体的提升建议，表述为能力升级而非批评。

如果只有1个贡献者，跳过团队拆分部分，改为撰写更深度的个人分析章节。

5. Track history

5. 跟踪历史数据

Persist retro history in the current workspace under

.context/retros/

Load the newest prior snapshot that matches the same scope and window.
Compare current metrics to the prior snapshot when one exists.
Save the new snapshot as
```
.context/retros/YYYY-MM-DD-N.json
```
.

Use a compact schema like:

json

{
  "date": "2026-04-01",
  "scope": "team",
  "teamId": "team_123",
  "teamName": "Platform",
  "window": "7d",
  "startDate": "2026-03-25T00:00:00+01:00",
  "endDate": "2026-04-01T23:59:59+02:00",
  "metrics": {
    "completed": 18,
    "contributors": 4,
    "initiativesAdvanced": 6,
    "bugsFixed": 5,
    "plannedStillOpen": 7,
    "blockers": 2,
    "activeDays": 5,
    "throughputPerDay": 3.6,
    "interruptRatio": 0.28,
    "qualityInvestmentRatio": 0.33
  },
  "people": {
    "Alex": {
      "completed": 7,
      "bugsFixed": 1,
      "topAreas": ["checkout", "crm"]
    }
  },
  "tweetable": "Week of Mar 25: 18 items shipped, 4 contributors, 6 initiative moves, 5 bug fixes, quality investment 33%"
}

If no prior retro exists, say that it is the first recorded retro for that scope and window.

将回顾历史存储在当前工作区的

.context/retros/

目录下。

加载与本次回顾范围、时间窗口匹配的最新历史快照。
如果存在历史快照，将当前指标与历史快照做对比。
将新快照保存为
```
.context/retros/YYYY-MM-DD-N.json
```
。

使用简洁的schema，示例如下：

json

{
  "date": "2026-04-01",
  "scope": "team",
  "teamId": "team_123",
  "teamName": "Platform",
  "window": "7d",
  "startDate": "2026-03-25T00:00:00+01:00",
  "endDate": "2026-04-01T23:59:59+02:00",
  "metrics": {
    "completed": 18,
    "contributors": 4,
    "initiativesAdvanced": 6,
    "bugsFixed": 5,
    "plannedStillOpen": 7,
    "blockers": 2,
    "activeDays": 5,
    "throughputPerDay": 3.6,
    "interruptRatio": 0.28,
    "qualityInvestmentRatio": 0.33
  },
  "people": {
    "Alex": {
      "completed": 7,
      "bugsFixed": 1,
      "topAreas": ["checkout", "crm"]
    }
  },
  "tweetable": "Week of Mar 25: 18 items shipped, 4 contributors, 6 initiative moves, 5 bug fixes, quality investment 33%"
}

如果不存在历史回顾，说明这是对应范围和时间窗口的首次记录回顾。

6. Output format

6. 输出格式

Structure the response in this order:

Short TLDR paragraph
```
## Engineering Retro: <date range>
```
Summary table
Trends vs last retro, if history exists
Delivery mix and quality signals
Work patterns
Scope-aware highlights:
- For personal scope:
```
## Your week
```
- For team scope:
```
## Team highlights
```
Wins
Friction and follow-through
Next-week focus

Formatting rules:

Start with a short paragraph, not bullets, for the TLDR.
The TLDR should cover:
- scope and date window
- main delivery signal
- main constraint or source of drag
- the most important next-step theme
Do not force a "tweetable summary" heading.
Use
```
##
```
for the main sections.
Use bullets only when the content is naturally list-shaped.

Default to 2-4 bullets for

Wins

Friction and follow-through

, and

Next-week focus

Do not force exactly 3 items in those sections if the data does not support it.
Keep the section titles stable, but let the content flex to the data.
If one section would be thin or repetitive, merge it into the adjacent section instead of padding.
Do not emit empty headings.
Prefer short paragraphs for analysis sections and bullets for concrete examples or actions.

Section intent:

```
Summary table
```
: the compact factual snapshot.
```
Trends vs last retro
```
: only include meaningful deltas, not every metric.
```
Delivery mix and quality signals
```
: explain what kind of work dominated and whether the team invested in quality.
```
Work patterns
```
: call out timing, clustering, carryover, or interruption patterns.
```
Your week
```
or
```
Team highlights
```
: explain the concrete work that mattered most.
```
Wins
```
: specific shipped outcomes, not generic praise.
```
Friction and follow-through
```
: blockers, churn, carryover, or process debt that deserves attention.
```
Next-week focus
```
: the 2-4 most important follow-through items or habits.

Scope rules:

For personal scope, use
```
## Your week
```
and do not include a team breakdown.
For team scope with only one active contributor, also use
```
## Your week
```
.
For team scope with multiple active contributors, use
```
## Team highlights
```
and include a short per-person subsection only when it adds signal.
Do not force per-person writeups for inactive contributors or people with trivial activity.

Thin-data rules:

If there is no prior retro, omit
```
Trends vs last retro
```
entirely and mention first-run status in the TLDR or closing line.
If there are no blockers, fold that into
```
Friction and follow-through
```
as a short sentence instead of a padded list.
If the window has very little completed work, shorten the retro and bias toward carryover, blockers, and next-step focus.

For work-pattern analysis, use completion timestamps if the data includes them:

Show active days and busiest days.
Show end-of-week clustering or crunch if it is obvious.
If timestamps include times, call out peak completion hours; otherwise stay at day granularity and say why.

按以下顺序组织返回内容：

简短的核心摘要（TLDR）段落
```
## 工程回顾：<日期范围>
```
汇总表
与上一次回顾的趋势对比（如果存在历史数据）
交付结构与质量信号
工作模式
适配范围的亮点：
- 个人范围：
```
## 你的一周
```
- 团队范围：
```
## 团队亮点
```
成果
问题与后续跟进
下周重点

格式规则：

核心摘要使用短段落开头，不要用列表。
核心摘要需要覆盖：
- 范围和时间窗口
- 核心交付信号
- 主要约束或拖慢进度的原因
- 最重要的下一步主题
不要强制添加「可发推摘要」标题。
主章节使用
```
##
```
标记。
仅当内容天然适合列表时使用项目符号。
「成果」、「问题与后续跟进」、「下周重点」部分默认使用2-4个项目符号。
如果数据支撑不足，不要强制凑够3项。
保持章节标题稳定，内容可根据数据灵活调整。
如果某个章节内容太少或重复，合并到相邻章节，不要凑内容。
不要输出空标题。
分析章节优先使用短段落，具体示例或行动项使用项目符号。

章节用途说明：

```
汇总表
```
：简洁的事实快照。
```
与上一次回顾的趋势对比
```
：仅包含有意义的变化，不需要列出所有指标。
```
交付结构与质量信号
```
：说明主导的工作类型，以及团队是否在质量上做了投入。
```
工作模式
```
：指出时间分布、扎堆交付、遗留项或中断模式。
```
你的一周
```
或
```
团队亮点
```
：说明最重要的具体工作内容。
```
成果
```
：具体的交付结果，不是泛泛的表扬。
```
问题与后续跟进
```
：需要关注的阻塞、重复工作、遗留项或流程负债。
```
下周重点
```
：2-4个最重要的跟进项或习惯优化点。

范围规则：

个人范围下使用
```
## 你的一周
```
，不要包含团队拆分内容。
团队范围但只有1个活跃贡献者时，同样使用
```
## 你的一周
```
。
团队范围且有多个活跃贡献者时，使用
```
## 团队亮点
```
，仅当有价值时添加简短的个人子章节。
不要为不活跃贡献者或贡献极少的人员强制生成个人分析。

数据不足规则：

如果没有历史回顾，完全省略「与上一次回顾的趋势对比」章节，在核心摘要或结尾说明是首次运行。
如果没有阻塞项，用短句把相关内容合并到「问题与后续跟进」，不要凑列表。
如果时间窗口内完成的工作极少，简化回顾内容，重点放在遗留项、阻塞项和下一步重点上。

如果数据包含完成时间戳，可用于工作模式分析：

展示活跃天数和最忙的日期。
如果存在明显的周尾扎堆交付或赶工情况，明确指出。
如果时间戳包含具体时刻，指出交付高峰时段；否则只保留天粒度并说明原因。

7. Tone and guardrails

7. 语气与边界

Be specific and anchored in actual tasks, labels, and linked initiatives.
Make clear when a metric is inferred rather than explicit in One Horizon.
Do not compare teammates against each other negatively.
If the window has no completed work, say so plainly and suggest a longer window.
Keep the narrative candid and useful, not celebratory filler.

表述要具体，基于实际任务、标签和关联的initiative。
当指标是推断而非One Horizon明确给出时，要明确说明。
不要做负面的团队成员对比。
如果时间窗口内没有完成工作，如实说明并建议选择更长的时间窗口。
保持叙述坦诚有用，不要写空洞的表扬内容。