summarize-changes

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Summarize Changes

代码变更汇总

Goal

目标

Produce accurate, audience-specific summaries of code changes from a selected scope.

针对选定范围内的代码变更，生成精准且符合目标受众的汇总内容。

When to use

使用场景

Use this skill when the user asks for change summaries such as:

"summarize what changed"
"summarize staged/unstaged changes"
"summarize all uncommitted work"
"summarize this branch/PR"
"write this summary as an engineer/PM"

当用户提出以下变更汇总类需求时，可使用本技能：

"汇总已变更内容"
"汇总暂存/未暂存的变更"
"汇总所有未提交的工作内容"
"汇总当前分支/PR的变更"
"以工程师/产品经理的视角撰写该汇总"

Invocation syntax

调用语法

Preferred invocation:

text

$summarize-changes <author-type> <scope>

No-args invocation is allowed:

text

$summarize-changes

Examples:

text

$Summarize Changes engineer PR
$summarize-changes engineer branch
$summarize-changes product-manager all-uncommitted
$summarize-changes

Normalization rules:

Treat skill trigger as case-insensitive (
```
$Summarize Changes
```
and
```
$summarize-changes
```
are both valid).
Normalize author aliases before execution:
- ```
product
```
  ->
```
product-manager
```
- ```
pm
```
  ->
```
product-manager
```

Normalize scope aliases before execution:

```
PR
```
,
```
pr
```
,
```
pr-wide
```
->
```
pr-wide
```
```
branch
```
,
```
branch-wide
```
->
```
branch-wide
```
```
unstaged
```
->
```
unstaged
```
```
staged
```
->
```
staged
```

all-uncommitted

uncommitted

all-uncommitted

```
last-message
```
,
```
last
```
->
```
last-message
```

If scope token is unknown, ask one short clarification question.
If author and/or scope is missing, ask one short clarification question with choices; if unanswered, default to
```
product
```
+
```
PR
```
.

推荐调用格式：

text

$summarize-changes <角色类型> <范围>

允许无参数调用：

text

$summarize-changes

示例：

text

$Summarize Changes engineer PR
$summarize-changes engineer branch
$summarize-changes product-manager all-uncommitted
$summarize-changes

标准化规则：

技能触发词不区分大小写（
```
$Summarize Changes
```
和
```
$summarize-changes
```
均有效）。
执行前需标准化角色别名：
- ```
product
```
  ->
```
product-manager
```
- ```
pm
```
  ->
```
product-manager
```

执行前需标准化范围别名：

```
PR
```
,
```
pr
```
,
```
pr-wide
```
->
```
pr-wide
```
```
branch
```
,
```
branch-wide
```
->
```
branch-wide
```
```
unstaged
```
->
```
unstaged
```
```
staged
```
->
```
staged
```

all-uncommitted

uncommitted

all-uncommitted

```
last-message
```
,
```
last
```
->
```
last-message
```

若范围参数未知，需提出一个简短的澄清问题。
若角色和/或范围缺失，需提出一个带选项的简短澄清问题；若未得到回复，则默认使用
```
product
```
+
```
PR
```
。

Scope modes

范围模式

Choose exactly one scope mode unless the user asks for multiple.

```
last-message
```

Summarize only changes referenced in the latest user/assistant implementation message.
Validate references against actual git diff before reporting.

```
unstaged
```

Use:
```
git diff
```
Include untracked files separately via
```
git status --porcelain
```
.

```
staged
```

Use:
```
git diff --cached
```

```
all-uncommitted
```

Combine:
- unstaged diff (
```
git diff
```
  )
- staged diff (
```
git diff --cached
```
  )
- untracked files (
```
git status --porcelain
```
  )

```
branch-wide
```

Use:
```
git diff <base>...HEAD
```
If base is not provided, infer from upstream (for example
```
origin/main
```
) and state assumption.
Alias support:
```
branch
```
,
```
branch-wide
```

```
pr-wide
```

Prefer GitHub CLI when available:

gh pr view --json baseRefName,headRefName,number,title

```
gh pr diff
```

If PR metadata is unavailable, fall back to
```
branch-wide
```
and state fallback.
Alias support:
```
PR
```
,
```
pr
```
,
```
pr-wide
```

除非用户明确要求，否则仅选择一种范围模式。

```
last-message
```

仅汇总最新用户/助手实现消息中提及的变更。
报告前需对照实际git diff验证提及的内容。

```
unstaged
```

使用命令：
```
git diff
```
通过
```
git status --porcelain
```
单独列出未追踪文件。

```
staged
```

使用命令：
```
git diff --cached
```

```
all-uncommitted
```

合并以下内容：
- 未暂存的差异（
```
git diff
```
  ）
- 已暂存的差异（
```
git diff --cached
```
  ）
- 未追踪文件（
```
git status --porcelain
```
  ）

```
branch-wide
```

使用命令：
```
git diff <base>...HEAD
```
若未提供基准分支，则从上游分支（例如
```
origin/main
```
）推断，并说明该假设。
别名支持：
```
branch
```
,
```
branch-wide
```

```
pr-wide
```

若GitHub CLI（gh）可用，优先使用：

gh pr view --json baseRefName,headRefName,number,title

```
gh pr diff
```

若无法获取PR元数据，则回退到
```
branch-wide
```
模式，并说明回退情况。
别名支持：
```
PR
```
,
```
pr
```
,
```
pr-wide
```

Author personas

角色 persona

Pick one primary persona. Optional secondary persona is allowed if user asks.

```
engineer
```

Focus: technical implementation details, files, APIs, data model, migrations, tests, risk.
Include concrete file-level notes and verification commands/results when available.

```
product-manager
```

Focus: user-visible features, UX changes, workflow impact, release notes framing.
Avoid low-value internal details unless they change behavior or risk.

```
designer
```

Focus: UI/UX behavior, interaction flow, visual hierarchy, accessibility-relevant changes.

```
qa
```

Focus: test impact, risk areas, regression vectors, what to test manually and automatically.

```
security
```

Focus: authn/authz changes, data access boundaries, secrets/config, attack surface delta.

```
executive
```

Focus: concise impact summary, delivery status, risks, and next steps.

选择一个主角色。若用户要求，可额外选择一个次要角色。

```
engineer
```

重点：技术实现细节、文件、API、数据模型、迁移、测试、风险。
若有可用信息，需包含具体的文件级说明和验证命令/结果。

```
product-manager
```

重点：用户可见功能、UX变更、工作流影响、发布说明框架。
除非会改变行为或带来风险，否则避免纳入低价值的内部细节。

```
designer
```

重点：UI/UX行为、交互流程、视觉层级、与无障碍相关的变更。

```
qa
```

重点：测试影响、风险区域、回归点、需手动和自动测试的内容。

```
security
```

重点：身份认证/授权变更、数据访问边界、密钥/配置、攻击面变化。

```
executive
```

重点：简洁的影响汇总、交付状态、风险和下一步计划。

Workflow

工作流程

Resolve scope and persona

If user did not specify, default to:
- scope:
```
PR
```
  (normalized to
```
pr-wide
```
  )
- persona:
```
product
```
  (normalized to
```
product-manager
```
  )

Normalize aliases first (

PR

pr-wide

branch

branch-wide

product

product-manager

Ask at most one question only if required to avoid wrong scope.

Collect evidence

Run scope-appropriate git/PR commands.
Build file list grouped by area (backend, frontend, db, tests, docs, infra).

Classify changes

Identify:
- added/changed/removed files
- behavioral vs refactor-only changes
- data/model/API/test/documentation deltas

Draft persona-specific summary

Apply persona focus rules.
Keep statements evidence-based (from diff/logs/PR metadata).

Add risks and unknowns

List material risks, assumptions, and missing validation.

确定范围和角色

若用户未指定，默认使用：
- 范围：
```
PR
```
  （标准化为
```
pr-wide
```
  ）
- 角色：
```
product
```
  （标准化为
```
product-manager
```
  ）

先标准化别名（

PR

pr-wide

branch

branch-wide

product

product-manager

）。

仅在必要时提出最多一个问题，以避免错误的范围选择。

收集证据

运行与范围匹配的git/PR命令。
按领域（后端、前端、数据库、测试、文档、基础设施）分组构建文件列表。

分类变更

识别：
- 新增/修改/删除的文件
- 行为变更与仅重构的变更
- 数据/模型/API/测试/文档的差异

撰写符合角色的汇总

应用角色重点规则。
确保陈述基于证据（来自diff/日志/PR元数据）。

添加风险和未知项

列出重大风险、假设和未验证的内容。

Required sections

必填章节

Every summary must include:

```
Scope
```
: explicit mode and command basis
```
Audience
```
: selected persona
```
What changed
```
: concise bullets
```
Files touched
```
: grouped list or highlights
```
Risks / follow-ups
```
: only material items

每个汇总必须包含以下部分：

```
Scope
```
：明确的模式和命令依据
```
Audience
```
：选定的角色
```
What changed
```
：简洁的项目符号列表
```
Files touched
```
：分组列表或重点内容
```
Risks / follow-ups
```
：仅包含重大事项

Output templates

输出模板

Template: Engineer

模板：工程师视角

markdown

Scope: `<scope-mode>`
Audience: `engineer`

What changed:
- <technical change>
- <technical change>

Files touched:
- `<path>`: <what changed and why>
- `<path>`: <what changed and why>

Verification status:
- `<command>` -> `<result>`
- `<command>` -> `<result>`

Risks / follow-ups:
- <risk or gap>
- <next action>

markdown

Scope: `<scope-mode>`
Audience: `engineer`

What changed:
- <technical change>
- <technical change>

Files touched:
- `<path>`: <what changed and why>
- `<path>`: <what changed and why>

Verification status:
- `<command>` -> `<result>`
- `<command>` -> `<result>`

Risks / follow-ups:
- <risk or gap>
- <next action>

Template: Product Manager

模板：产品经理视角

markdown

Scope: `<scope-mode>`
Audience: `product-manager`

Feature/UX impact:
- <user-visible capability or behavior change>
- <user-visible capability or behavior change>

Experience changes by area:
- `<route/page/feature>`: <what changed for users>
- `<route/page/feature>`: <what changed for users>

Release notes draft:
- <customer-facing summary line>
- <customer-facing summary line>

Risks / rollout notes:
- <known risk, edge case, or migration note>
- <recommended mitigation or follow-up>

markdown

Scope: `<scope-mode>`
Audience: `product-manager`

Feature/UX impact:
- <user-visible capability or behavior change>
- <user-visible capability or behavior change>

Experience changes by area:
- `<route/page/feature>`: <what changed for users>
- `<route/page/feature>`: <what changed for users>

Release notes draft:
- <customer-facing summary line>
- <customer-facing summary line>

Risks / rollout notes:
- <known risk, edge case, or migration note>
- <recommended mitigation or follow-up>

Template: QA

模板：QA视角

markdown

Scope: `<scope-mode>`
Audience: `qa`

Change inventory:
- <high-risk code path changed>
- <high-risk code path changed>

Regression focus:
- <what can break and where>
- <what can break and where>

Test plan updates:
- Automated: <tests to add/update/run>
- Manual: <critical user flows to verify>

Known gaps / blockers:
- <missing test coverage or environment blocker>

markdown

Scope: `<scope-mode>`
Audience: `qa`

Change inventory:
- <high-risk code path changed>
- <high-risk code path changed>

Regression focus:
- <what can break and where>
- <what can break and where>

Test plan updates:
- Automated: <tests to add/update/run>
- Manual: <critical user flows to verify>

Known gaps / blockers:
- <missing test coverage or environment blocker>

Guardrails

约束规则

Do not invent behavior that is not present in diffs/PR evidence.
Do not mix scopes unless explicitly requested.
Call out assumptions (for example inferred base branch).
Prefer concrete file references over vague statements.
If no changes are found for the selected scope, state that explicitly.

不得编造diff/PR证据中不存在的行为。
除非用户明确要求，否则不得混合多种范围。
需说明假设（例如推断的基准分支）。
优先使用具体的文件引用，而非模糊陈述。
若在选定范围内未发现任何变更，需明确说明。

Useful commands

实用命令

bash

undefined

bash

undefined

unstaged

git diff

staged

git diff --cached

all uncommitted

git diff && git diff --cached && git status --porcelain

branch-wide

git diff origin/main...HEAD

PR-wide (if gh is available)

gh pr view --json baseRefName,headRefName,number,title gh pr diff

undefined

gh pr view --json baseRefName,headRefName,number,title gh pr diff

undefined