name: fix description: 用于bug调查和解决的元技能工作流程编排器。根据范围路由到调试、实施、测试和提交。 allowed-tools: [Bash, Read, Grep, Write, Edit, Task]
Fix
用于bug调查和解决的工作流程编排器。基于问题范围链式调用专业技能。
用法
/fix <范围> [选项] [描述]
问题流程（无参数）
如果用户只输入/fix没有或部分参数，通过此问题流程引导他们。为每个阶段使用AskUserQuestion。
阶段0：工作流程选择
question: "您想修复什么？"
header: "修复类型"
options:
- label: "帮我选择（推荐）"
description: "我会提问以选择正确的修复工作流程"
- label: "Bug - 某些功能损坏"
description: "链式：调查 → 诊断 → 实施 → 测试 → 提交"
- label: "Hook - Claude Code hook问题"
description: "链式：debug-hooks → hook-developer → 实施 → 测试"
- label: "依赖项 - 导入/包错误"
description: "链式：preflight → 研究 → 计划 → 实施 → qlty-check"
- label: "PR评论 - 处理审阅者反馈"
description: "链式：github-search → 研究 → 计划 → 实施 → 提交"
映射：
- “帮我选择” → 继续到阶段1-4问题
- “Bug” → 设置scope=bug，跳到阶段2（问题详情）
- “Hook” → 设置scope=hook，跳到阶段2（问题详情）
- “依赖项” → 设置scope=deps，跳到阶段2（问题详情）
- “PR评论” → 设置scope=pr-comments，跳到阶段2（问题详情）
如果答案不明确（通过"其他"）：
question: "我想了解您需要哪种修复。您指的是..."
header: "澄清"
options:
- label: "帮我选择"
description: "不确定 - 引导我通过问题"
- label: "Bug - 某些功能损坏"
description: "代码未按预期工作"
- label: "Hook - Claude Code hook问题"
description: "Hooks未触发或输出错误"
- label: "都不是 - 让我以不同方式解释"
description: "我将描述我的问题"
阶段1：问题类型
question: "您在处理哪种问题？"
header: "问题类型"
options:
- label: "某些功能损坏/不工作"
description: "代码中的bug"
- label: "Claude Code hook未触发"
description: "Hook特定调试"
- label: "导入/依赖项错误"
description: "包或模块问题"
- label: "需要处理PR反馈"
description: "审阅者评论修复"
映射：
- “某些功能损坏” → bug范围
- “Hook未触发” → hook范围
- “导入错误” → deps范围
- “PR反馈” → pr-comments范围
阶段2：问题详情
question: "您能描述问题吗？"
header: "详情"
options: [] # 自由文本 - 用户描述问题
捕获错误消息、意外行为或PR链接。
阶段3：调查深度
question: "我应该如何调查？"
header: "调查"
options:
- label: "诊断并修复"
description: "找到问题并实施修复"
- label: "仅诊断（干运行）"
description: "只告诉我问题，不修改代码"
- label: "快速修复"
description: "我知道问题，快速修复"
映射：
- “仅诊断” → --dry-run
- “快速修复” → 跳过调查，直接转到spark代理
阶段4：测试与提交
question: "修复后，我应该..."
header: "修复后"
multiSelect: true
options:
- label: "编写回归测试"
description: "防止此bug复发"
- label: "提交修复"
description: "创建git提交"
- label: "仅修复，无其他"
description: "我将处理测试和git"
映射：
- 无"回归测试" → --no-test
- 无"提交" → --no-commit
执行前总结
根据您的回答，我将运行：
**范围：** bug
**问题：** "登录按钮在Safari上无响应"
**链式：** sleuth（调查）→ spark（修复）→ arbiter（测试）→ commit
**选项：** （无）
继续？ [是 / 调整设置]
范围
| 范围 | 链式 | 描述 |
|---|---|---|
bug |
debug -> implement_task -> test-driven-development -> commit | 通用bug修复工作流程 |
hook |
debug-hooks -> hook-developer -> implement_task -> test hook | Hook特定调试 |
deps |
dependency-preflight -> oracle -> plan-agent -> implement_plan -> qlty-check | 依赖项问题 |
pr-comments |
github-search -> research-codebase -> plan-agent -> implement_plan -> commit | 处理PR反馈 |
选项
| 选项 | 效果 |
|---|---|
--no-test |
跳过回归测试创建 |
--dry-run |
仅诊断，不实施修复 |
--no-commit |
不自动提交修复 |
工作流程
阶段1：解析参数
# 解析范围和选项
SCOPE="${1:-bug}"
NO_TEST=false
DRY_RUN=false
NO_COMMIT=false
for arg in "$@"; do
case $arg in
--no-test) NO_TEST=true ;;
--dry-run) DRY_RUN=true ;;
--no-commit) NO_COMMIT=true ;;
esac
done
阶段2：调查（并行）
生成sleuth代理进行并行调查：
Task(
subagent_type="sleuth",
prompt="""
并行调查此问题：
1. **日志：** 检查最近日志中的错误
- 应用日志
- 系统日志（如果相关）
- 构建/测试输出
2. **数据库状态**（如果适用）：
- 检查卡住/无效记录
- 验证模式匹配预期
3. **Git状态：**
- 可能相关的最近提交
- 未提交的更改
- 当前分支上下文
4. **运行时状态：**
- 运行进程
- 端口冲突
- 环境变量
问题描述：{user_description}
返回结构化发现与证据。
"""
)
阶段3：诊断报告
向用户展示发现：
## 诊断报告
### 范围：{scope}
### 发现的证据
**日志：**
- [带有时间戳/行引用的发现]
**数据库：**
- [带有表/查询引用的发现]
**Git状态：**
- [最近相关提交]
- [未提交的更改]
**运行时：**
- [进程/端口发现]
### 根本原因分析
**主要假设：** [基于证据的最可能原因]
**支持证据：**
1. [证据1]
2. [证据2]
**替代假设：**
- [替代1]: [为何可能性较低]
### 建议的修复
**方法：** [如何修复]
**要修改的文件：**
- `path/to/file.ts:123` - [更改描述]
**风险评估：** [低/中/高] - [原因]
---
**继续修复？** (是/否/修改方法)
阶段4：人工检查点（诊断）
必需： 等待用户确认后再实施。
AskUserQuestion(
question="继续建议的修复？",
options=["是", "否", "修改"]
)
如果用户说"修改"，收集新需求并更新方法。
如果用户说"否"，创建诊断交接并退出。
如果--dry-run，在此创建诊断交接并退出。
阶段4.5：风险评估（事前分析）
诊断批准后，实施前：
对建议的修复进行快速事前分析以捕捉风险：
/premortem quick
事前分析上下文：
premortem:
mode: quick
context: "Bug修复用于{diagnosis.root_cause}"
check_for:
- 此修复是否会破坏其他功能？
- 如果修复导致问题，是否可以回滚？
- 是否有未覆盖的相关边缘情况？
- 修复是否符合代码库模式？
- 是否影响任何外部依赖项？
风险决策：
- 无高风险： 继续到实施
- 发现高风险： 向用户展示选项：
- 接受风险并继续
- 修改方法以处理风险
- 先研究缓解策略
AskUserQuestion(
question="事前分析发现建议修复中有{n}个风险。继续？",
options=[
"接受风险并实施",
"修改修复方法",
"先研究缓解策略"
]
)
如果"先研究缓解策略"，为每个风险并行生成scout + oracle，然后重新展示选项。
阶段5：实施
基于范围路由到适当的实施技能：
bug范围：
Task(
subagent_type="kraken",
prompt="""
使用TDD方法实施修复。
根本原因：{diagnosis.root_cause}
文件：{diagnosis.files_to_modify}
方法：{diagnosis.approach}
遵循implement_task工作流程：
1. 编写重现bug的失败测试
2. 实施最小修复以通过测试
3. 如果需要，重构
4. 运行完整测试套件
"""
)
hook范围：
Task(
subagent_type="kraken",
prompt="""
修复hook问题。
根本原因：{diagnosis.root_cause}
遵循hook-developer模式：
1. 检查settings.json中的hook注册
2. 验证shell包装器存在且可执行
3. 使用模拟输入手动测试hook
4. 如果修改了TypeScript源代码，重新构建
5. 验证hook正确触发
"""
)
deps范围：
Task(
subagent_type="kraken",
prompt="""
修复依赖项问题。
根本原因：{diagnosis.root_cause}
遵循plan-agent工作流程：
1. 研究正确的依赖项版本
2. 创建实施计划
3. 更新锁文件
4. 运行dependency-preflight
5. 运行qlty-check
"""
)
pr-comments范围：
Task(
subagent_type="kraken",
prompt="""
处理PR反馈。
评论：{diagnosis.pr_comments}
遵循plan-agent工作流程：
1. 研究代码库以获取上下文
2. 为每个评论创建实施计划
3. 实施更改
4. 提交并引用评论
"""
)
阶段6：回归测试（除非–no-test）
Task(
subagent_type="kraken",
prompt="""
为修复创建回归测试。
Bug：{original_issue}
修复：{implementation_summary}
遵循test-driven-development：
1. 编写能捕获此bug的测试
2. 验证测试针对修复前代码失败（在思想上）
3. 验证测试针对修复后代码通过
4. 测试应最小化且集中
"""
)
阶段7：人工检查点（验证）
AskUserQuestion(
question="修复已实施。请验证并确认。",
options=["看起来好", "需要调整", "回滚"]
)
如果"需要调整"，收集反馈并返回到阶段5。 如果"回滚"，运行回滚命令并退出。
阶段8：提交（除非–no-commit）
Task(
subagent_type="general-purpose",
prompt="""
遵循提交技能：
1. 使用git diff审阅更改
2. 创建描述性提交消息
3. 引用问题/工单（如果适用）
4. 展示计划并等待确认
5. 执行提交
"""
)
按范围的链式详情
bug
sleuth（调查）
|
v
[人工检查点：诊断]
|
v
[事前分析：快速风险检查]
|
v
kraken（implement_task + TDD）
|
v
kraken（回归测试）
|
v
[人工检查点：验证]
|
v
commit
hook
debug-hooks（结构化调查）
|
v
[人工检查点：诊断]
|
v
[事前分析：快速风险检查]
|
v
kraken（implement_task + hook-developer模式）
|
v
test hook手动
|
v
[人工检查点：验证]
|
v
commit
deps
dependency-preflight（检查当前状态）
|
v
oracle（查找正确版本/替代方案）
|
v
plan-agent（创建修复计划）
|
v
[人工检查点：诊断 + 计划审阅]
|
v
[事前分析：快速风险检查]
|
v
kraken（implement_plan）
|
v
qlty-check
|
v
[人工检查点：验证]
|
v
commit
pr-comments
github-search（获取PR上下文）
|
v
research-codebase（理解上下文）
|
v
plan-agent（为每个评论计划）
|
v
[人工检查点：计划审阅]
|
v
[事前分析：快速风险检查]
|
v
kraken（implement_plan）
|
v
[人工检查点：验证]
|
v
commit（引用PR评论）
交接创建
始终创建交接，即使使用--dry-run：
---
session: fix-{scope}-{short-description}
ts: {ISO时间戳}
commit: {git提交哈希}
branch: {git分支}
status: {complete|partial|blocked|diagnosis-only}
---
scope: {bug|hook|deps|pr-comments}
options: {使用的标志}
issue:
description: {原始用户描述}
evidence: {调查中的关键发现}
diagnosis:
root_cause: {识别的原因}
hypothesis: {为何我们认为此}
files: [{受影响文件}]
fix:
approach: {做了什么}
files_modified: [{更改的文件}]
test_added: {如果创建了测试文件}
verification:
test_command: {验证命令}
human_confirmed: {true|false}
next:
- {任何后续需要}
位置： thoughts/shared/handoffs/fix/{scope}/{timestamp}_{description}.yaml
示例
基本Bug修复
/fix bug
# -> 调查、诊断、实施、测试、提交
仅诊断
/fix bug --dry-run
# -> 调查、创建诊断交接、停止
修复无自动提交
/fix hook --no-commit
# -> 完整修复工作流程但在提交前停止
快速修复（无回归测试）
/fix bug --no-test
# -> 实施修复、提交、无回归测试
处理PR评论
/fix pr-comments
# -> 获取PR、创建计划、实施、提交
错误处理
| 错误 | 动作 |
|---|---|
| 调查未发现任何内容 | 询问用户更多上下文 |
| 用户拒绝诊断 | 使用用户输入优化假设 |
| 修复破坏其他测试 | 回滚、优化方法 |
| 用户拒绝验证 | 提供回滚或调整 |
| 提交失败 | 展示错误、提供重试 |
与其他技能的集成
此技能编排：
debug/debug-hooks：初始调查sleuth：并行调查代理kraken：TDD实施代理implement_task：单任务实施test-driven-development：测试创建plan-agent：复杂修复计划dependency-preflight：依赖项检查oracle/research-codebase：上下文收集github-search：PR上下文获取qlty-check：质量验证premortem：实施前风险评估commit：Git提交工作流程create_handoff：会话交接
检查点总结
| 检查点 | 目的 | 跳过条件 |
|---|---|---|
| 诊断后 | 确认根本原因 | 从不跳过 |
| 事前分析后 | 接受或缓解风险 | 无高风险 |
| 修复后 | 验证解决方案 | 从不跳过 |
| 提交前 | 审阅更改 | --no-commit |
人工检查点至关重要，因为：
- 防止实施错误的修复
- 确保用户理解更改内容
- 捕获只有人类能注意到的边缘情况