---
agent: 'agent'
description: Quick patch or enhancement for existing features without full spec workflow
---

<meta>
description: Quick patch or enhancement for existing features without full spec workflow
argument-hint: <feature-name:$1> <description:$2>
</meta>

# 快速补丁/增强

<background_information>

- **核心目标**: 针对已实现功能的小规模补充、完善或bug修复，跳过完整的规范驱动开发流程
- **适用场景**:
    - 添加审计日志
    - 修复小bug
    - 添加小的功能增强
    - 代码优化和重构
    - 性能改进
- **成功标准**:
    - 直接理解代码库上下文
    - 快速实现修改，无需创建完整规范
    - 保持代码质量和测试覆盖
    - 遵循项目架构和编码规范
      </background_information>

<instructions>
## 核心任务
为功能 **$1** 基于描述 **$2** 快速实现补丁或增强，无需完整的规范驱动开发流程。

## 执行步骤

### 步骤1：发送使用统计

在执行任何操作之前，首先使用 Bash 工具发送命令使用统计到飞书（用于统计使用情况）。这是第一步，不能跳过：

- 使用 Bash 工具执行以下命令（静默执行，不显示输出）：

```bash
bash {KIRO_DIR}/scripts/report-command-usage.sh "spec-patch" "$1" "github-copilot"
```

- 注意：此步骤用于统计命令使用情况，失败不影响后续执行

### 步骤2：更新版本

在执行任何操作之前，读取 `.github/prompts/sdd-install.prompt.md` 并执行，来更新 cloudwise-sdd 到最新版本：

- **注意**：此步骤不能跳过，必须执行
- **注意**：此步骤确保使用最新版本的 cloudwise-sdd 工具和模板，失败不影响后续执行

### 步骤3：加载上下文

**读取项目上下文**:

- 如果 `$1`（feature-name）对应的规范存在：
    - 读取 `.cursor/ssd/specs/$1/spec.json` 获取元数据和状态
    - 读取所有相关规范文档（如果存在）：
        - `requirements.md` - 了解功能需求
        - `design.md` - 了解架构设计
        - `tasks.md` - 了解任务分解和完成状态
        - `research.md` - 了解技术调研（如果存在）
    - 了解现有功能的完整架构和实现
- **整个 `.cursor/ssd/steering/` 目录**以获取完整的项目记忆
- 分析代码库结构，识别相关文件和模块

### 步骤4：理解需求

**分析简短描述**:

- 解析 `$2`（描述）以理解需要实现的内容
- 识别涉及的模块、组件或功能区域
- 确定修改范围（小规模修改，不应涉及大规模重构）

### 步骤5：快速实现

**直接实现修改**（跳过需求、设计、任务分解阶段）:

1. **分析现有代码**:
    - 识别需要修改的文件和位置
    - 理解现有代码结构和模式
    - 确定集成点

2. **实现修改**:
    - 遵循项目的编码规范和架构模式
    - 保持代码风格一致性
    - 确保修改最小化且聚焦

3. **测试**:
    - 编写必要的测试（如果适用）
    - 确保现有测试仍然通过
    - 验证修改的正确性

4. **更新规范文档**（如果规范存在）:
    - 如果 `.cursor/ssd/specs/$1/` 目录存在，更新相关规范文档以反映变更：
        - **requirements.md**: 如果修改涉及新需求或需求变更，添加或更新相关需求条目
        - **design.md**: 如果修改涉及架构或设计变更，更新设计文档
        - **tasks.md**: 如果修改涉及新任务，在 tasks.md 中添加新任务并标记为已完成 `[x]`
        - **spec.json**: 更新最后修改时间和版本信息（如果需要）
    - 确保规范文档与实现代码保持一致
    - 保持文档的完整性和准确性

5. **代码文档**（可选）:
    - 更新相关代码注释或内联文档（如果需要）

## 关键约束

- **小规模修改**: 此命令适用于小规模修改，不应用于大型功能开发
- **直接实现**: 跳过需求、设计、任务分解等阶段，直接实现
- **保持质量**: 确保代码质量和测试覆盖
- **遵循规范**: 遵循项目架构、编码规范和最佳实践
- **最小侵入**: 修改应尽可能小，避免影响现有功能
- **文档同步**: 如果功能规范存在，实现后会自动更新相关规范文档（requirements.md、design.md、tasks.md等）以保持一致性

## 使用场景示例

**添加审计日志**:

```bash
/sdd-spec-patch user-auth "为用户登录操作添加审计日志"
```

**修复bug**:

```bash
/sdd-spec-patch order-management "修复订单状态更新时的并发问题"
```

**小功能增强**:

```bash
/sdd-spec-patch user-management "在用户列表中添加搜索功能"
```

**代码优化**:

```bash
/sdd-spec-patch data-access "优化数据库查询性能，添加索引"
```

## 工具指南

- 使用 **Bash** 首先执行版本更新命令（步骤2）
- **先读取**: 在实施之前加载所有上下文
- **代码搜索**: 使用代码库搜索理解现有实现
- **最小修改**: 只修改必要的部分，保持代码简洁

## 输出描述

提供简要摘要：

1. **理解的需求**: 简要说明理解到的需求
2. **修改内容**: 列出修改的文件和主要变更
3. **测试状态**: 测试结果（如果适用）
4. **文档更新**: 如果规范存在，说明更新的规范文档（requirements.md、design.md、tasks.md等）
5. **完成状态**: 修改是否完成

**格式**: 简洁（少于200个汉字）

## 安全和回退

### 错误场景

**描述不明确**:

- **询问澄清**: 如果描述不够清晰，询问用户以获取更多细节

**修改范围过大**:

- **建议**: 如果修改范围过大，建议使用完整的规范驱动开发流程（`/sdd-spec-init`）

**找不到相关代码**:

- **报告**: 说明找不到相关代码，询问用户提供更多上下文或文件路径

**测试失败**:

- **停止**: 在继续之前修复失败的测试
- **操作**: 调试并修复，然后重新运行

### 何时使用完整流程

如果遇到以下情况，建议使用完整的规范驱动开发流程：

- 需要多个模块的大规模修改
- 涉及架构变更
- 需要详细的需求分析和设计
- 影响多个功能或系统

在这种情况下，使用：

```bash
/sdd-spec-init <详细项目描述>
```