fix-bug

Bug 修复流水线

从 Bug 描述出发，自动完成：Bug 分析与定位 → 创建隔离 Worktree → 代码修复 → 补充测试 → 全量验证 → 合入主分支 → 清理 Worktree。

适用于 tapd-ai-cli 项目——一个纯 Go CLI 工具，无前端、无 E2E 测试。

---

流程总览

用户输入 Bug 描述
        |
        v
[阶段 1] Bug 分析与定位
        |
        v
  确认修复方案
        |
        v
[阶段 2] 创建 Worktree（隔离工作区）
        |
        v
[阶段 3] 代码修复
        |
        v
[阶段 4] 补充单元测试
        |
        v
[阶段 5] 全量验证（fmt / lint / build / test / coverage）
        |  ← 失败则修复代码并重新验证
        v
[阶段 6] 合入主分支并清理 Worktree
        |
        v
  完成

---

步骤

阶段 1：Bug 分析与定位

1. 获取 Bug 信息

   用户在调用此 SKILL 时应附带 Bug 描述。如果未提供，使用 AskUserQuestion tool 询问：

   "请描述您遇到的 Bug，包括复现步骤、期望行为和实际行为。"

2. 阅读项目上下文

   阅读以下文件获取项目背景：

   • CODEBUDDY.md — 项目架构、构建命令、代码规范
   • docs/requirement.md — 需求规格

3. 分析 Bug 根因

   使用 Agent tool（subagent_type=Explore）深入分析 Bug：

   • 根据 Bug 描述定位相关代码文件
   • 项目目录结构：cmd/tapd/（入口）、internal/cmd/（命令层）、internal/client/（API 客户端层）、internal/config/（配置层）、internal/output/（输出层）、internal/model/（数据模型层）
   • 追踪数据流：参数解析 → API 调用 → 响应转换 → 格式化输出
   • 分析可能的根因
   • 检查是否有相关的已有测试覆盖该场景

4. 提出修复方案并确认

   使用 AskUserQuestion tool 向用户展示分析结果并确认修复方案：

   • Bug 根因分析
   • 受影响的文件和模块
   • 修复方案（如有多种方案，列出各方案的优缺点）
   • 可能的影响范围

   等待用户确认修复方案后再继续。

阶段 2：创建 Worktree（隔离工作区）

1. 确认当前分支状态

   在创建 worktree 前，先检查当前分支状态：

   git status
   git branch --show-current
   

   • 如果当前有未提交的更改，使用 AskUserQuestion tool 提醒用户并询问是否继续（worktree 是独立的，不影响当前工作区的更改）。
   • 记录当前所在的主分支名称（通常是 main 或 master），后续合入时使用。

2. 创建隔离 Worktree

   使用 git 命令在项目父目录下创建 worktree，避免在项目内部产生额外目录：

   # 获取项目根目录的父目录路径
   PROJECT_ROOT=$(git rev-parse --show-toplevel)
   WORKTREE_DIR="$(dirname "$PROJECT_ROOT")/worktree/fix-<bug简述>"
   
   # 基于主分支创建新分支和 worktree
   git worktree add -b fix-<bug简述> "$WORKTREE_DIR" <主分支名>
   

   • 分支命名：使用 fix-<bug简述> 格式，例如 fix-auth-token-error
   • Worktree 路径：../worktree/fix-<bug简述>（相对于项目根目录）
   • 基于步骤 5 中记录的主分支创建

   创建成功后，使用 cd 切换到新的 worktree 目录中。后续所有代码修改和测试都在此工作区中进行。