fix

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Fix

修复

Workflow orchestrator for bug investigation and resolution. Chains specialized skills based on issue scope.

用于Bug排查与修复的工作流编排器，可根据问题范围串联各类专业技能。

Usage

使用方法

/fix <scope> [options] [description]

/fix <scope> [options] [description]

Question Flow (No Arguments)

提问流程（无参数时）

If the user types just

/fix

with no or partial arguments, guide them through this question flow. Use AskUserQuestion for each phase.

如果用户仅输入

/fix

而未提供参数或参数不全，将引导用户完成以下提问流程。每个阶段使用AskUserQuestion交互。

Phase 0: Workflow Selection

阶段0：工作流选择

yaml

question: "What would you like to fix?"
header: "Fix type"
options:
  - label: "Help me choose (Recommended)"
    description: "I'll ask questions to pick the right fix workflow"
  - label: "Bug - something is broken"
    description: "Chain: investigate → diagnose → implement → test → commit"
  - label: "Hook - Claude Code hook issue"
    description: "Chain: debug-hooks → hook-developer → implement → test"
  - label: "Dependencies - import/package errors"
    description: "Chain: preflight → research → plan → implement → qlty-check"
  - label: "PR Comments - address reviewer feedback"
    description: "Chain: github-search → research → plan → implement → commit"

Mapping:

"Help me choose" → Continue to Phase 1-4 questions
"Bug" → Set scope=bug, skip to Phase 2 (issue details)
"Hook" → Set scope=hook, skip to Phase 2 (issue details)
"Dependencies" → Set scope=deps, skip to Phase 2 (issue details)
"PR Comments" → Set scope=pr-comments, skip to Phase 2 (issue details)

If Answer is Unclear (via "Other"):

yaml

question: "I want to understand what kind of fix you need. Did you mean..."
header: "Clarify"
options:
  - label: "Help me choose"
    description: "Not sure - guide me through questions"
  - label: "Bug - something is broken"
    description: "Code isn't working as expected"
  - label: "Hook - Claude Code hook issue"
    description: "Hooks not firing or producing wrong output"
  - label: "Neither - let me explain differently"
    description: "I'll describe my issue"

yaml

question: "你想要修复什么问题？"
header: "修复类型"
options:
  - label: "帮我选择（推荐）"
    description: "我会通过提问帮你挑选合适的修复工作流"
  - label: "Bug - 功能异常"
    description: "流程：排查 → 诊断 → 实现 → 测试 → 提交"
  - label: "Hook - Claude Code钩子问题"
    description: "流程：调试钩子 → 钩子开发 → 实现 → 测试"
  - label: "Dependencies - 导入/包错误"
    description: "流程：预检 → 调研 → 规划 → 实现 → 质量检查"
  - label: "PR Comments - 处理评审反馈"
    description: "流程：GitHub搜索 → 调研 → 规划 → 实现 → 提交"

映射关系：

"帮我选择" → 继续执行阶段1-4的提问
"Bug" → 设置scope=bug，跳至阶段2（问题详情）
"Hook" → 设置scope=hook，跳至阶段2（问题详情）
"Dependencies" → 设置scope=deps，跳至阶段2（问题详情）
"PR Comments" → 设置scope=pr-comments，跳至阶段2（问题详情）

若答案不明确（选择“其他”）：

yaml

question: "我想了解你需要的修复类型。你是指..."
header: "确认需求"
options:
  - label: "帮我选择"
    description: "不确定 - 引导我完成提问"
  - label: "Bug - 功能异常"
    description: "代码未按预期运行"
  - label: "Hook - Claude Code钩子问题"
    description: "钩子未触发或输出错误结果"
  - label: "都不是 - 我换种方式说明"
    description: "我将描述具体问题"

Phase 1: Issue Type

阶段1：问题类型

yaml

question: "What kind of issue are you dealing with?"
header: "Issue type"
options:
  - label: "Something is broken/not working"
    description: "Bug in the code"
  - label: "Claude Code hook not firing"
    description: "Hook-specific debugging"
  - label: "Import/dependency errors"
    description: "Package or module issues"
  - label: "Need to address PR feedback"
    description: "Reviewer comments to fix"

Mapping:

"Something broken" → bug scope
"Hook not firing" → hook scope
"Import errors" → deps scope
"PR feedback" → pr-comments scope

yaml

question: "你遇到的是什么类型的问题？"
header: "问题类型"
options:
  - label: "功能异常/无法正常运行"
    description: "代码中的Bug"
  - label: "Claude Code钩子未触发"
    description: "钩子专属调试"
  - label: "导入/依赖错误"
    description: "包或模块问题"
  - label: "需要处理PR反馈"
    description: "修复评审提出的问题"

映射关系：

"功能异常" → bug范围
"钩子未触发" → hook范围
"导入错误" → deps范围
"PR反馈" → pr-comments范围

Phase 2: Issue Details

阶段2：问题详情

yaml

question: "Can you describe the issue?"
header: "Details"
options: []  # Free text - user describes the problem

Capture the error message, unexpected behavior, or PR link.

yaml

question: "能否描述具体问题？"
header: "详情"
options: []  # 自由文本 - 用户描述问题

捕获错误信息、异常行为或PR链接。

Phase 3: Investigation Depth

阶段3：排查深度

yaml

question: "How should I investigate?"
header: "Investigation"
options:
  - label: "Diagnose and fix"
    description: "Find the problem and implement a fix"
  - label: "Diagnose only (dry run)"
    description: "Just tell me what's wrong, don't change code"
  - label: "Quick fix"
    description: "I know the issue, just fix it fast"

Mapping:

"Diagnose only" → --dry-run
"Quick fix" → skip investigation, go straight to spark agent

yaml

question: "我应如何进行排查？"
header: "排查方式"
options:
  - label: "诊断并修复"
    description: "找出问题并实现修复"
  - label: "仅诊断（试运行）"
    description: "仅告知问题所在，不修改代码"
  - label: "快速修复"
    description: "我已知道问题，直接快速修复"

映射关系：

"仅诊断" → --dry-run
"快速修复" → 跳过排查，直接调用spark agent

Phase 4: Testing & Commit

阶段4：测试与提交

yaml

question: "After fixing, should I..."
header: "After fix"
multiSelect: true
options:
  - label: "Write a regression test"
    description: "Prevent this bug from recurring"
  - label: "Commit the fix"
    description: "Create a git commit"
  - label: "Just fix, nothing else"
    description: "I'll handle tests and git"

Mapping:

No "regression test" → --no-test
No "commit" → --no-commit

yaml

question: "修复完成后，是否需要..."
header: "修复后操作"
multiSelect: true
options:
  - label: "编写回归测试"
    description: "防止该Bug再次出现"
  - label: "提交修复"
    description: "创建Git提交"
  - label: "仅修复，不做其他"
    description: "我将自行处理测试与Git操作"

映射关系：

未选择"回归测试" → --no-test
未选择"提交" → --no-commit

Summary Before Execution

执行前汇总

Based on your answers, I'll run:

**Scope:** bug
**Issue:** "Login button not responding on Safari"
**Chain:** sleuth (investigate) → spark (fix) → arbiter (test) → commit
**Options:** (none)

Proceed? [Yes / Adjust settings]

根据你的回答，我将执行：

**范围：** bug
**问题：** "Safari浏览器中登录按钮无响应"
**流程：** sleuth（排查）→ spark（修复）→ arbiter（测试）→ 提交
**选项：** （无）

是否继续？[是 / 调整设置]

Scopes

范围说明

Scope	Chain	Description
`bug`	debug -> implement_task -> test-driven-development -> commit	General bug fix workflow
`hook`	debug-hooks -> hook-developer -> implement_task -> test hook	Hook-specific debugging
`deps`	dependency-preflight -> oracle -> plan-agent -> implement_plan -> qlty-check	Dependency issues
`pr-comments`	github-search -> research-codebase -> plan-agent -> implement_plan -> commit	Address PR feedback

范围	流程链	描述
`bug`	debug -> implement_task -> test-driven-development -> commit	通用Bug修复工作流
`hook`	debug-hooks -> hook-developer -> implement_task -> test hook	钩子专属调试工作流
`deps`	dependency-preflight -> oracle -> plan-agent -> implement_plan -> qlty-check	依赖问题处理工作流
`pr-comments`	github-search -> research-codebase -> plan-agent -> implement_plan -> commit	PR反馈处理工作流

Options

选项说明

Option	Effect
`--no-test`	Skip regression test creation
`--dry-run`	Diagnose only, don't implement fix
`--no-commit`	Don't auto-commit the fix

选项	作用
`--no-test`	跳过回归测试创建
`--dry-run`	仅诊断，不实现修复
`--no-commit`	不自动提交修复

Workflow

工作流详情

Phase 1: Parse Arguments

阶段1：解析参数

bash

undefined

bash

undefined

Parse scope and options

解析范围与选项

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

undefined

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

undefined

Phase 2: Investigation (Parallel)

阶段2：并行排查

Spawn sleuth agent for parallel investigation:

Task(
  subagent_type="sleuth",
  prompt="""
  Investigate this issue in parallel:

  1. **Logs**: Check recent logs for errors
     - Application logs
     - System logs if relevant
     - Build/test output

  2. **Database State** (if applicable):
     - Check for stuck/invalid records
     - Verify schema matches expectations

  3. **Git State**:
     - Recent commits that might relate
     - Uncommitted changes
     - Current branch context

  4. **Runtime State**:
     - Running processes
     - Port conflicts
     - Environment variables

  Issue description: {user_description}

  Return structured findings with evidence.
  """
)

启动sleuth agent进行并行排查：

Task(
  subagent_type="sleuth",
  prompt="""
  并行排查以下问题：

  1. **日志**：检查近期错误日志
     - 应用日志
     - 相关系统日志
     - 构建/测试输出

  2. **数据库状态**（如适用）：
     - 检查停滞/无效记录
     - 验证架构是否符合预期

  3. **Git状态**：
     - 可能相关的近期提交
     - 未提交的更改
     - 当前分支上下文

  4. **运行时状态**：
     - 运行中的进程
     - 端口冲突
     - 环境变量

  问题描述：{user_description}

  返回包含证据的结构化排查结果。
  """
)

Phase 3: Diagnosis Report

阶段3：诊断报告

Present findings to user:

markdown

undefined

向用户展示排查结果：

markdown

undefined

Diagnosis Report

诊断报告

Scope: {scope}

范围：{scope}

Evidence Found

发现的证据

Logs:

[Finding with timestamp/line reference]

Database:

[Finding with table/query reference]

Git State:

[Recent relevant commits]
[Uncommitted changes]

Runtime:

[Process/port findings]

日志：

[带时间戳/行号的排查结果]

数据库：

[带表/查询引用的排查结果]

Git状态：

[近期相关提交]
[未提交的更改]

运行时：

[进程/端口排查结果]

Root Cause Analysis

根因分析

Primary Hypothesis: [Most likely cause based on evidence]

Supporting Evidence:

[Evidence 1]
[Evidence 2]

Alternative Hypotheses:

[Alternative 1]: [Why less likely]

主要假设： [基于证据的最可能原因]

支持证据：

[证据1]
[证据2]

备选假设：

[备选假设1]：[可能性较低的原因]

Proposed Fix

修复方案

Approach: [How to fix]

Files to Modify:

```
path/to/file.ts:123
```
- [Change description]

Risk Assessment: [Low/Medium/High] - [Why]

Proceed with fix? (yes/no/modify approach)

undefined

实现思路： [修复方式]

需修改文件：

```
path/to/file.ts:123
```
- [更改说明]

风险评估： [低/中/高] - [评估依据]

是否继续执行修复？ (是/否/调整方案)

undefined

Phase 4: Human Checkpoint (Diagnosis)

阶段4：人工确认（诊断环节）

REQUIRED: Wait for user confirmation before implementing.

AskUserQuestion(
  question="Proceed with the proposed fix?",
  options=["yes", "no", "modify"]
)

If user says "modify", gather new requirements and update approach. If user says "no", create diagnostic handoff and exit. If

--dry-run

, create diagnostic handoff and exit here.

必须执行： 实现修复前等待用户确认。

AskUserQuestion(
  question="是否继续执行推荐的修复方案？",
  options=["是", "否", "调整"]
)

若用户选择“调整”，收集新需求并更新方案。若用户选择“否”，创建诊断交接文档并退出。若使用

--dry-run

参数，在此环节创建诊断交接文档并退出。

Phase 4.5: Risk Assessment (Premortem)

阶段4.5：风险评估（事前分析）

After diagnosis approval, before implementation:

Run a quick premortem on the proposed fix to catch risks:

/premortem quick

Context for premortem:

yaml

premortem:
  mode: quick
  context: "Bug fix for {diagnosis.root_cause}"

  check_for:
    - Will this fix break other functionality?
    - Is rollback possible if fix causes issues?
    - Are there related edge cases not covered?
    - Does the fix match codebase patterns?
    - Any external dependencies affected?

Risk Decision:

No HIGH tigers: Proceed to implementation
HIGH tigers found: Present to user with options:
- Accept risks and proceed
- Modify approach to address risks
- Research mitigation strategies

AskUserQuestion(
  question="Pre-mortem found {n} risks in the proposed fix. Proceed?",
  options=[
    "Accept risks and implement",
    "Modify fix approach",
    "Research mitigations first"
  ]
)

If "Research mitigations", spawn scout + oracle in parallel per risk, then re-present options.

诊断通过后，实现修复前：

对推荐的修复方案进行快速事前分析，排查潜在风险：

/premortem quick

事前分析上下文：

yaml

premortem:
  mode: quick
  context: "针对{diagnosis.root_cause}的Bug修复"

  check_for:
    - 该修复是否会破坏其他功能？
    - 若修复引发问题，是否可回滚？
    - 是否存在未覆盖的相关边缘场景？
    - 修复是否符合代码库的设计模式？
    - 是否会影响外部依赖？

风险决策：

无高风险问题：进入实现环节
发现高风险问题：向用户展示选项：
- 接受风险并继续
- 调整方案以解决风险
- 调研风险缓解策略

AskUserQuestion(
  question="事前分析发现{ n }个高风险问题。是否继续？",
  options=[
    "接受风险并实现修复",
    "调整修复方案",
    "先调研缓解策略"
  ]
)

若选择“调研缓解策略”，针对每个风险并行启动scout + oracle agent，然后重新展示选项。

Phase 5: Implementation

阶段5：实现修复

Route to appropriate implementation skill based on scope:

根据范围路由至对应的实现技能：

bug scope:

bug范围：

Task(
  subagent_type="kraken",
  prompt="""
  Implement fix with TDD approach.

  Root cause: {diagnosis.root_cause}
  Files: {diagnosis.files_to_modify}
  Approach: {diagnosis.approach}

  Follow implement_task workflow:
  1. Write failing test that reproduces the bug
  2. Implement minimal fix to pass test
  3. Refactor if needed
  4. Run full test suite
  """
)

Task(
  subagent_type="kraken",
  prompt="""
  采用TDD方式实现修复。

  根因：{diagnosis.root_cause}
  文件：{diagnosis.files_to_modify}
  思路：{diagnosis.approach}

  遵循implement_task工作流：
  1. 编写可复现Bug的失败测试
  2. 实现最小化修复以通过测试
  3. 按需重构
  4. 运行完整测试套件
  """
)

hook scope:

hook范围：

Task(
  subagent_type="kraken",
  prompt="""
  Fix hook issue.

  Root cause: {diagnosis.root_cause}

  Follow hook-developer patterns:
  1. Check hook registration in settings.json
  2. Verify shell wrapper exists and is executable
  3. Test hook manually with mock input
  4. Rebuild if TypeScript source was modified
  5. Verify hook fires correctly
  """
)

Task(
  subagent_type="kraken",
  prompt="""
  修复钩子问题。

  根因：{diagnosis.root_cause}

  遵循hook-developer模式：
  1. 检查settings.json中的钩子注册
  2. 验证shell包装器是否存在且可执行
  3. 使用模拟输入手动测试钩子
  4. 若修改了TypeScript源码则重新构建
  5. 验证钩子是否正常触发
  """
)

deps scope:

deps范围：

Task(
  subagent_type="kraken",
  prompt="""
  Fix dependency issue.

  Root cause: {diagnosis.root_cause}

  Follow plan-agent workflow:
  1. Research correct dependency versions
  2. Create implementation plan
  3. Update lockfiles
  4. Run dependency-preflight
  5. Run qlty-check
  """
)

Task(
  subagent_type="kraken",
  prompt="""
  修复依赖问题。

  根因：{diagnosis.root_cause}

  遵循plan-agent工作流：
  1. 调研正确的依赖版本
  2. 创建实现计划
  3. 更新锁文件
  4. 运行dependency-preflight
  5. 运行qlty-check
  """
)

pr-comments scope:

pr-comments范围：

Task(
  subagent_type="kraken",
  prompt="""
  Address PR feedback.

  Comments: {diagnosis.pr_comments}

  Follow plan-agent workflow:
  1. Research codebase for context
  2. Create implementation plan for each comment
  3. Implement changes
  4. Commit with reference to comment
  """
)

Task(
  subagent_type="kraken",
  prompt="""
  处理PR反馈。

  评论：{diagnosis.pr_comments}

  遵循plan-agent工作流：
  1. 调研代码库上下文
  2. 为每条评论创建实现计划
  3. 实现更改
  4. 提交时关联评论
  """
)

Phase 6: Regression Test (unless --no-test)

阶段6：回归测试（除非使用--no-test）

Task(
  subagent_type="kraken",
  prompt="""
  Create regression test for the fix.

  Bug: {original_issue}
  Fix: {implementation_summary}

  Follow test-driven-development:
  1. Write test that would have caught this bug
  2. Verify test fails against pre-fix code (mentally)
  3. Verify test passes against fixed code
  4. Test should be minimal and focused
  """
)

Task(
  subagent_type="kraken",
  prompt="""
  为修复创建回归测试。

  Bug：{original_issue}
  修复：{implementation_summary}

  遵循测试驱动开发流程：
  1. 编写可捕获该Bug的测试
  2. 确认测试在修复前代码上会失败（逻辑验证）
  3. 确认测试在修复后代码上会通过
  4. 测试应简洁且聚焦
  """
)

Phase 7: Human Checkpoint (Verification)

阶段7：人工确认（验证环节）

AskUserQuestion(
  question="Fix implemented. Please verify and confirm.",
  options=["looks good", "needs adjustment", "revert"]
)

If "needs adjustment", gather feedback and return to Phase 5. If "revert", run rollback command and exit.

AskUserQuestion(
  question="修复已实现，请验证并确认。",
  options=["没问题", "需要调整", "回滚"]
)

若选择“需要调整”，收集反馈并返回至阶段5。若选择“回滚”，执行回滚命令并退出。

Phase 8: Commit (unless --no-commit)

阶段8：提交（除非使用--no-commit）

Task(
  subagent_type="general-purpose",
  prompt="""
  Follow commit skill:

  1. Review changes with git diff
  2. Create descriptive commit message
  3. Reference issue/ticket if applicable
  4. Present plan and await confirmation
  5. Execute commit
  """
)

Task(
  subagent_type="general-purpose",
  prompt="""
  遵循提交技能流程：

  1. 使用git diff查看更改
  2. 创建描述性提交信息
  3. 关联相关问题/工单（如适用）
  4. 展示计划并等待确认
  5. 执行提交
  """
)

Chain Details by Scope

各范围的流程链详情

bug

sleuth (investigation)
  |
  v
[HUMAN CHECKPOINT: diagnosis]
  |
  v
[PREMORTEM: quick risk check]
  |
  v
kraken (implement_task + TDD)
  |
  v
kraken (regression test)
  |
  v
[HUMAN CHECKPOINT: verification]
  |
  v
commit

sleuth（排查）
  |
  v
[人工确认：诊断]
  |
  v
[事前分析：快速风险检查]
  |
  v
kraken（implement_task + TDD）
  |
  v
kraken（回归测试）
  |
  v
[人工确认：验证]
  |
  v
提交

hook

debug-hooks (structured investigation)
  |
  v
[HUMAN CHECKPOINT: diagnosis]
  |
  v
[PREMORTEM: quick risk check]
  |
  v
kraken (implement_task + hook-developer patterns)
  |
  v
test hook manually
  |
  v
[HUMAN CHECKPOINT: verification]
  |
  v
commit

debug-hooks（结构化排查）
  |
  v
[人工确认：诊断]
  |
  v
[事前分析：快速风险检查]
  |
  v
kraken（implement_task + hook-developer模式）
  |
  v
手动测试钩子
  |
  v
[人工确认：验证]
  |
  v
提交

deps

dependency-preflight (check current state)
  |
  v
oracle (find correct versions/alternatives)
  |
  v
plan-agent (create fix plan)
  |
  v
[HUMAN CHECKPOINT: diagnosis + plan review]
  |
  v
[PREMORTEM: quick risk check]
  |
  v
kraken (implement_plan)
  |
  v
qlty-check
  |
  v
[HUMAN CHECKPOINT: verification]
  |
  v
commit

dependency-preflight（检查当前状态）
  |
  v
oracle（查找正确版本/替代方案）
  |
  v
plan-agent（创建修复计划）
  |
  v
[人工确认：诊断 + 计划评审]
  |
  v
[事前分析：快速风险检查]
  |
  v
kraken（implement_plan）
  |
  v
qlty-check
  |
  v
[人工确认：验证]
  |
  v
提交

pr-comments

github-search (fetch PR context)
  |
  v
research-codebase (understand context)
  |
  v
plan-agent (plan for each comment)
  |
  v
[HUMAN CHECKPOINT: plan review]
  |
  v
[PREMORTEM: quick risk check]
  |
  v
kraken (implement_plan)
  |
  v
[HUMAN CHECKPOINT: verification]
  |
  v
commit (reference PR comments)

github-search（获取PR上下文）
  |
  v
research-codebase（理解上下文）
  |
  v
plan-agent（为每条评论制定计划）
  |
  v
[人工确认：计划评审]
  |
  v
[事前分析：快速风险检查]
  |
  v
kraken（implement_plan）
  |
  v
[人工确认：验证]
  |
  v
提交（关联PR评论）

Handoff Creation

交接文档创建

Always create a handoff, even with

--dry-run

yaml

---
session: fix-{scope}-{short-description}
ts: {ISO timestamp}
commit: {git commit hash}
branch: {git branch}
status: {complete|partial|blocked|diagnosis-only}
---

scope: {bug|hook|deps|pr-comments}
options: {flags used}

issue:
  description: {original user description}
  evidence: {key findings from investigation}

diagnosis:
  root_cause: {identified cause}
  hypothesis: {why we think this}
  files: [{affected files}]

fix:
  approach: {what was done}
  files_modified: [{files changed}]
  test_added: {test file if created}

verification:
  test_command: {command to verify}
  human_confirmed: {true|false}

next:
  - {any follow-up needed}

Location:

thoughts/shared/handoffs/fix/{scope}/{timestamp}_{description}.yaml

无论是否使用
--dry-run
，始终创建交接文档：

yaml

---
session: fix-{scope}-{short-description}
ts: {ISO时间戳}
commit: {Git提交哈希}
branch: {Git分支}
status: {完成|部分完成|阻塞|仅诊断}
---

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

Examples

示例

Basic Bug Fix

基础Bug修复

/fix bug

/fix bug

-> Investigates, diagnoses, implements, tests, commits

-> 排查、诊断、实现、测试、提交

undefined

undefined

Diagnose Only

仅诊断

/fix bug --dry-run

/fix bug --dry-run

-> Investigates, creates diagnosis handoff, stops

-> 排查、创建诊断交接文档、退出

undefined

undefined

Fix Without Auto-Commit

修复但不自动提交

/fix hook --no-commit

/fix hook --no-commit

-> Full fix workflow but stops before commit

-> 完整修复流程，但在提交前停止

undefined

undefined

Quick Fix (No Regression Test)

快速修复（无回归测试）

/fix bug --no-test

/fix bug --no-test

-> Implements fix, commits, no regression test

-> 实现修复、提交，不创建回归测试

undefined

undefined

Address PR Comments

处理PR反馈

/fix pr-comments

/fix pr-comments

-> Fetches PR, creates plan, implements, commits

-> 获取PR、创建计划、实现、提交

undefined

undefined

Error Handling

错误处理

Error	Action
Investigation finds nothing	Ask user for more context
User rejects diagnosis	Refine hypothesis with user input
Fix breaks other tests	Rollback, refine approach
User rejects verification	Offer to revert or adjust
Commit fails	Present error, offer retry

错误场景	处理方式
排查未发现任何问题	向用户请求更多上下文
用户拒绝诊断结果	根据用户输入优化假设
修复破坏了其他测试	回滚、优化方案
用户拒绝验证结果	提供回滚或调整选项
提交失败	展示错误、提供重试选项

Integration with Other Skills

与其他技能的集成

This skill orchestrates:

```
debug
```
/
```
debug-hooks
```
: Initial investigation
```
sleuth
```
: Parallel investigation agent
```
kraken
```
: TDD implementation agent
```
implement_task
```
: Single task implementation
```
test-driven-development
```
: Test creation
```
plan-agent
```
: Complex fix planning
```
dependency-preflight
```
: Dependency checks
```
oracle
```
/
```
research-codebase
```
: Context gathering
```
github-search
```
: PR context fetching
```
qlty-check
```
: Quality verification
```
premortem
```
: Risk assessment before implementation
```
commit
```
: Git commit workflow
```
create_handoff
```
: Session handoff

该技能编排以下技能：

```
debug
```
/
```
debug-hooks
```
：初始排查
```
sleuth
```
：并行排查Agent
```
kraken
```
：TDD实现Agent
```
implement_task
```
：单任务实现
```
test-driven-development
```
：测试创建
```
plan-agent
```
：复杂修复规划
```
dependency-preflight
```
：依赖检查
```
oracle
```
/
```
research-codebase
```
：上下文收集
```
github-search
```
：PR上下文获取
```
qlty-check
```
：质量验证
```
premortem
```
：实现前风险评估
```
commit
```
：Git提交工作流
```
create_handoff
```
：会话交接

Checkpoints Summary

确认环节汇总

Checkpoint	Purpose	Skip Condition
After diagnosis	Confirm root cause	Never skip
After premortem	Accept or mitigate risks	No HIGH tigers
After fix	Verify resolution	Never skip
Before commit	Review changes	`--no-commit`

The human checkpoints are critical for:

Preventing wrong fixes from being implemented
Ensuring user understands what changed
Catching edge cases only humans notice

确认环节	目的	跳过条件
诊断后	确认根因	不可跳过
事前分析后	接受或缓解风险	无高风险问题
修复后	验证修复效果	不可跳过
提交前	查看更改	`--no-commit`

人工确认环节至关重要，用于：

防止错误修复被实现
确保用户了解更改内容
发现仅人类能注意到的边缘场景