name: patch-design description: 创建最小化的、有针对性的补丁计划，用于目标修复。当修复审查中的特定问题、创建聚焦的补丁或避免修复实现中的范围蔓延时使用。 allowed-tools: 读取, 搜索
补丁设计技能
创建最小化的、有针对性的补丁计划。
使用时机
- 修复审查中的特定问题
- 创建聚焦的bug修复
- 解决阻塞问题而不引入范围蔓延
- 进行有针对性的改进
核心原则
“这是一个补丁 - 保持范围最小化。只修复问题描述中提到的内容，别无其他。”
设计工作流
步骤 1: 理解特定问题
清晰解析问题：
- 什么被破坏了？（具体行为）
- 它应该如何工作？（预期行为）
- 存在什么证据？（截图、错误信息）
不要将范围扩大到报告的问题之外。
步骤 2: 分析当前状态
查看相关代码：
# 找到相关文件
git diff --stat
grep -r "related_function" src/
# 读取特定代码
cat src/component/file.ts
步骤 3: 确定最小修复
询问：“什么是修复这个问题的最小更改？”
| 方法 | 行数 | 风险 |
|---|---|---|
| 手术式修复 | 1-10 | 低 |
| 目标修复 | 10-50 | 中 |
| 重构 | 50+ | 高 |
对于补丁，始终优先选择手术式修复。
步骤 4: 创建补丁计划
记录精确的修复：
# 补丁：[简洁标题]
## 问题摘要
**问题**：[什么被破坏了]
**解决方案**：[最小修复]
## 要修改的文件
- `路径/到/文件.ts`：[具体更改]
## 实现步骤
### 步骤 1: [具体操作]
[精确代码更改]
### 步骤 2: [具体操作]
[精确代码更改]
## 验证
- [验证修复的命令]
- [如何确认成功]
## 补丁范围
- 代码行数：~X
- 风险级别：低
- 测试：[最小化/标准]
步骤 5: 定义验证
每个补丁都需要验证：
## 验证
1. 运行特定测试：`npm test 路径/到/测试`
2. 手动验证：[步骤]
3. 视觉检查：[如果适用]
补丁计划模板
# 补丁：[简要描述]
## 元数据
- 问题：[此补丁请求的来源]
- 严重性：[阻塞/技术债务]
## 问题摘要
**原始规范**：[如果可用，链接]
**问题**：[简要描述错误]
**解决方案**：[简要描述修复]
## 要修改的文件
[仅需要更改的文件 - 具体]
- `src/component/Button.tsx`：修复禁用状态
## 实现步骤
重要：按顺序执行每个步骤。
### 步骤 1: [具体更改]
<!-- markdownlint-disable MD033 -->
```jsx
// 之前
<button onClick={handleClick}>
// 之后
<button onClick={handleClick} disabled={isLoading}>
<!-- markdownlint-enable MD033 -->
步骤 2: [如果需要，下一个更改]
[详情]
验证
执行以确认补丁完成：
npm test src/component/Button.test.tsx- 手动：点击按钮，验证在加载期间禁用
补丁范围
- 更改行数：~5
- 风险级别：低
- 测试：运行组件测试
要避免的反模式
范围蔓延
# 错误：扩大范围
在修复按钮时，我注意到表单可以使用
重构，所以我还会更新验证逻辑，
改进错误消息，并添加加载状态到
所有其他按钮。
模糊更改
# 错误：模糊计划
## 实现
- 修复按钮问题
- 使其正确工作
- 测试以确认
无验证
# 错误：无验证
## 实现
1. 更改代码
2. 完成
最佳实践
- 一个问题，一个补丁：不要捆绑修复
- 最小范围：只更改所需内容
- 具体步骤：精确代码更改
- 清晰验证：如何验证成功
- 风险评估：更改行数，测试需求
与审查集成
补丁通常来自审查问题：
/审查 → 识别阻塞问题
↓
/补丁 → 创建手术式修复计划
↓
/实现 → 执行补丁
↓
/审查 → 验证修复（重新审查）
记忆参考
- @issue-severity-classification.md - 什么触发补丁
- @review-vs-test.md - 审查识别补丁需求
- @one-agent-one-purpose.md - 补丁本质上是聚焦的
版本历史
- v1.0.0 (2025-12-26)：初始发布
最后更新
日期： 2025-12-26 模型： claude-opus-4-5-20251101