菜单
Bug 修复流水线。当用户报告 Bug 或想要修复已知问题时使用。调用时需附带 Bug 描述或复现步骤。自动串联：Bug 分析 → 创建 Worktree → 代码修复 → 集成测试 → E2E 测试 → 全量验证 → 合入 main。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/studyzy/tapd-ai-cli --skill fix-bug命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
基于 SOC 职业分类
| name | fix-bug |
| description | Bug 修复流水线。当用户报告 Bug 或想要修复已知问题时使用。调用时需附带 Bug 描述或复现步骤。自动串联：Bug 分析 → 创建 Worktree → 代码修复 → 集成测试 → E2E 测试 → 全量验证 → 合入 main。 |
| argument-hint | [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
完成
获取 Bug 信息
用户在调用此 SKILL 时应附带 Bug 描述。如果未提供，使用 AskUserQuestion tool 询问：
"请描述您遇到的 Bug，包括复现步骤、期望行为和实际行为。"
阅读项目上下文
阅读以下文件获取项目背景：
CODEBUDDY.md — 项目架构、构建命令、代码规范docs/requirement.md — 需求规格分析 Bug 根因
使用 Agent tool（subagent_type=Explore）深入分析 Bug：
cmd/tapd/（入口）、internal/cmd/（命令层）、internal/client/（API 客户端层）、internal/config/（配置层）、internal/output/（输出层）、internal/model/（数据模型层）提出修复方案并确认
使用 AskUserQuestion tool 向用户展示分析结果并确认修复方案：
等待用户确认修复方案后再继续。
确认当前分支状态
在创建 worktree 前，先检查当前分支状态：
git status
git branch --show-current
main 或 master），后续合入时使用。创建隔离 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/fix-<bug简述>（相对于项目根目录）创建成功后，使用 cd 切换到新的 worktree 目录中。后续所有代码修改和测试都在此工作区中进行。
创建任务列表
使用 TaskCreate tool 根据确认的修复方案创建详细的任务列表，将修复工作拆分为可跟踪的小任务。
实现代码修复
按照任务列表逐一修复代码：
CODEBUDDY.md 代码规范章节）：
switch 必须有 defaultpanic 和 gotointernal/cmd/）只做参数解析和输出格式化，禁止直接构造 HTTP 请求internal/client/）注意：
判断是否需要补充测试
如果 Bug 场景已有测试覆盖且测试本身无误，可跳过。否则必须补充。
编写单元测试
*_test.go 文件作为参考net/http/httptest 做 mock serverxxx_test.go，测试函数命名：TestXxx代码格式化和静态检查
make fmt
make lint
如果 lint 报错，修复后重新检查。
构建
make build
如果构建失败，分析错误并修复代码，然后重新构建。
运行全量测试
make test
如果测试失败，分析失败原因并修复代码/测试，然后重新运行。
检查测试覆盖率
make coverage
确保覆盖率 >= 60%。如果低于阈值，补充测试用例。
验证循环
如果步骤 11-14 中任何一步失败：
仅在阶段 5 的所有验证步骤全部通过后才执行此步骤。
在 Worktree 中提交变更
在当前 worktree 中提交所有修复代码：
git add <相关文件> # 不要添加无关文件
git commit -m "fix: <Bug 简述>
<详细描述修复内容和根因>"
合入主分支
使用 AskUserQuestion tool 询问用户是否将修复合入主分支：
"所有验证已通过并已提交。是否将修复合入主分支（<主分支名>）？"
如果用户确认：
a. 切回主工作区
cd <项目根目录> # 切回原来的主工作区
b. 合并修复分支到主分支
使用 fast-forward 优先的合并策略，避免无冲突时产生多余的 merge commit：
git merge <worktree分支名> --ff
c. 删除 Worktree 和修复分支
合并成功后，清理 worktree 目录和修复分支：
# 删除 worktree
PROJECT_ROOT=$(git rev-parse --show-toplevel)
git worktree remove "$(dirname "$PROJECT_ROOT")/worktree/fix-<bug简述>"
# 删除修复分支
git branch -d <worktree分支名>
推送到远程仓库（可选）
使用 AskUserQuestion tool 询问用户是否需要推送到远程仓库：
"修复已合入主分支。是否需要推送到远程仓库？"
如果用户确认，执行推送。
## Bug 修复完成
**Bug：** <Bug 简述>
**根因：** <根因分析>
**修复方案：** <方案简述>
### 修改的文件
- <文件列表及修改说明>
### 新增/修改的测试
- <测试文件及覆盖场景>
### 验证结果
- fmt/lint 通过
- 构建通过
- 全量测试通过
- 覆盖率 >= 60%
### Git 信息
- 修复分支：<分支名>
- 已合入：<主分支名>
- commit: <commit hash>
- worktree 已清理
Bug 修复全流程已完成。
../worktree/ 目录）中进行，不得直接在主工作区修改../worktree/ 下的 worktree 目录和修复分支，保持仓库整洁--ff 合并，能 fast-forward 时不产生 merge commit，保持提交历史简洁CODEBUDDY.md 中的代码规范和 Go 编码规范