mcpField
S
summarize-changes

summarize-changes

github.com/oimiragieo开发4466 次安装17 周前更新
代码仓库

关于 summarize-changes

用于整理非简单代码变更、支持评审和项目记录的技能。它将影响范围、验证步骤、兼容性变更和 Conventional Commit 建议组织成摘要及 PR 内容。

主要功能

  1. 01生成结构化变更摘要
  2. 02识别受影响组件和依赖
  3. 03整理验证清单
  4. 04记录兼容性变更
  5. 05建议 Conventional Commit 信息
  6. 06起草 PR 描述

适用场景

  1. 01提交前总结代码变更
  2. 02准备 Pull Request 描述
  3. 03为评审者提供变更及验证背景

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/oimiragieo/agent-studio --skill summarize-changes

安装后在 Claude Code 中输入/summarize-changes确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

commands/
summarize-changes.md
hooks/
post-execute.cjs
pre-execute.cjs
references/
research-requirements.md
rules/
summarize-changes.md
schemas/
input.schema.json
output.schema.json
scripts/
main.cjs
templates/
implementation-template.md

详细介绍

变更摘要专家 - 为文档和评审创建清晰、结构化的代码变更摘要。 - 生成结构化的变更摘要 - 识别受影响的组件和依赖项 - 创建验证清单 - 记录破坏性变更 - 撰写提交消息建议 - 生成 PR 描述内容

适用场景

在以下情况下调用此技能:

  • 完成任何非平凡的编码任务后
  • 提交变更前
  • 准备 PR 描述时
  • think-about-whether-you-are-done 确认任务完成后

变更摘要工作流

第 1 步:收集变更信息

收集有关变更的以下信息:

  1. 已修改文件:列出所有变更过的文件
  2. 变更类型:对变更进行分类(新增、修改、删除、重命名)
  3. 范围:识别受影响的组件/模块
# If using git, gather diff summary
git status
git diff --stat
第 2 步:分析变更影响

对于每项重要变更,记录:

  1. 变更内容:具体进行了哪些修改
  2. 变更原因:变更的原因/动机
  3. 影响:受影响的方面(功能、性能、API)
第 3 步:生成摘要

使用以下模板:

## Changes Summary

### Overview

[1-2 sentence high-level description of what was accomplished]

### Changes Made

#### New Files

| File              | Purpose                            |
| ----------------- | ---------------------------------- |
| `path/to/file.ts` | Description of what this file does |

#### Modified Files

| File                  | Changes                  |
| --------------------- | ------------------------ |
| `path/to/existing.ts` | What was changed and why |

#### Deleted Files

| File             | Reason                    |
| ---------------- | ------------------------- |
| `path/to/old.ts` | Why this file was removed |

### Technical Details

**Key Implementation Decisions**:

- Decision 1 and rationale
- Decision 2 and rationale

**Dependencies Added/Removed**:

- Added: `package-name@version` - reason
- Removed: `old-package` - reason

### Breaking Changes

[List any breaking changes or "None"]

### Migration Required

[Any steps needed to adopt these changes or "None"]

### Verification Checklist

- [ ] Unit tests pass
- [ ] Integration tests pass
- [ ] Manual testing performed
- [ ] Documentation updated
- [ ] No console errors
- [ ] Performance acceptable

### Related Issues/Tasks

- Fixes #123
- Related to #456
第 4 步:提交消息建议

生成一条符合约定式提交规范的消息:

<type>(<scope>): <description>

<body - what and why>

<footer - breaking changes, issues>

类型:

  • feat:新增功能
  • fix:修复缺陷
  • refactor:重构代码
  • docs:仅修改文档
  • test:添加测试
  • chore:维护任务

示例:

fix(auth): resolve login timeout error

Increased timeout from 5s to 30s for login requests.
The previous timeout was insufficient for users on slow connections.

Fixes #123
第 5 步:PR 描述(如适用)

如果变更用于 PR,请扩展摘要:

## Summary

[Brief description of what this PR does]

## Changes

[List of key changes]

## Testing

[How this was tested]

## Screenshots

[If UI changes]

## Checklist

- [ ] Tests added/updated
- [ ] Documentation updated
- [ ] No breaking changes (or documented)
**修复缺陷后**:
## Changes Summary

### Overview

Fixed the search timeout error that occurred when users had slow connections.

### Changes Made

#### Modified Files

| File                     | Changes                          |
| ------------------------ | -------------------------------- |
| `src/api/search.ts`      | Increased timeout from 5s to 30s |
| `src/api/search.test.ts` | Added test for timeout handling  |

### Technical Details

**Key Implementation Decisions**:

- Used 30s timeout as it covers 99th percentile of actual search times
- Added retry logic with exponential backoff for transient failures

**Dependencies Added/Removed**:

- None

### Breaking Changes

None

### Verification Checklist

- [x] Unit tests pass
- [x] Integration tests pass
- [x] Manual testing performed
- [x] No console errors

### Commit Message

fix(search): increase timeout to handle slow connections

Increased search API timeout from 5s to 30s and added retry logic. Users on slow connections were experiencing frequent timeout errors.

Fixes #456

</usage_example>

<usage_example> 新增功能后:

## Changes Summary

### Overview

Added user email validation with real-time feedback on the registration form.

### Changes Made

#### New Files

| File                               | Purpose                    |
| ---------------------------------- | -------------------------- |
| `src/utils/emailValidator.ts`      | Email validation utilities |
| `src/utils/emailValidator.test.ts` | Tests for email validation |

#### Modified Files

| File                                  | Changes                         |
| ------------------------------------- | ------------------------------- |
| `src/components/RegistrationForm.tsx` | Added validation to email field |
| `src/i18n/en.json`                    | Added validation error messages |

### Technical Details

**Key Implementation Decisions**:

- Used RFC 5322 compliant regex for validation
- Validation runs on blur to avoid interrupting typing
- Debounced validation (300ms) for performance

**Dependencies Added/Removed**:

- None (used built-in regex)

### Breaking Changes

None - additive change only

### Verification Checklist

- [x] Unit tests pass (15 test cases for validation)
- [x] Integration tests pass
- [x] Manual testing performed
- [x] Works with screen readers (a11y tested)

### Commit Message

feat(registration): add email validation with real-time feedback

Added RFC 5322 compliant email validation to registration form. Validation runs on blur with debouncing for smooth UX.

Closes #789

</usage_example>

**相关技能**: - `thinking-tools` - 摘要前使用,以确认任务已完成 - `git-expert` - 用于提交和 PR 工作流 - `commit-message-guidelines` - 用于遵循约定式提交规范

铁律

  1. 绝不只列出文件而不说明每项变更的内容和原因
  2. 务必包含验证清单,以便评审者确认质量
  3. 绝不省略破坏性变更部分——始终明确列出,即使内容为“无”
  4. 务必在摘要附带的提交消息中使用约定式提交格式
  5. 绝不跳过非平凡编码任务后的摘要步骤——这是必需步骤

反模式

反模式失败原因正确做法
只列出文件名未说明变更内容或原因说明每项修改的内容及原因
缺少验证清单评审者不知道要测试什么始终提供待验证事项清单
省略破坏性变更部分用户会因兼容性中断而感到意外没有破坏性变更时,明确写出“破坏性变更:无”
提交消息含糊(“Updates”)提交历史失去可追溯性使用包含类型、范围和原因的约定式提交格式
时间紧迫时跳过摘要缺少上下文会导致评审过程中返工非平凡任务后始终生成摘要
## 记忆协议(必须遵守)

开始前: 阅读 .claude/context/memory/learnings.md

完成后:

  • 发现新模式 -> .claude/context/memory/learnings.md
  • 遇到问题 -> .claude/context/memory/issues.md
  • 做出决定 -> .claude/context/memory/decisions.md

假设任务会被中断:如果没有记录在记忆中,就等于没发生。

评论

支持 Markdown