fix
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseFix
修复
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 with no or partial arguments, guide them through this question flow. Use AskUserQuestion for each phase.
/fix如果用户仅输入而未提供参数或参数不全,将引导用户完成以下提问流程。每个阶段使用AskUserQuestion交互。
/fixPhase 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 problemCapture 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 |
|---|---|---|
| debug -> implement_task -> test-driven-development -> commit | General bug fix workflow |
| debug-hooks -> hook-developer -> implement_task -> test hook | Hook-specific debugging |
| dependency-preflight -> oracle -> plan-agent -> implement_plan -> qlty-check | Dependency issues |
| github-search -> research-codebase -> plan-agent -> implement_plan -> commit | Address PR feedback |
| 范围 | 流程链 | 描述 |
|---|---|---|
| debug -> implement_task -> test-driven-development -> commit | 通用Bug修复工作流 |
| debug-hooks -> hook-developer -> implement_task -> test hook | 钩子专属调试工作流 |
| dependency-preflight -> oracle -> plan-agent -> implement_plan -> qlty-check | 依赖问题处理工作流 |
| github-search -> research-codebase -> plan-agent -> implement_plan -> commit | PR反馈处理工作流 |
Options
选项说明
| Option | Effect |
|---|---|
| Skip regression test creation |
| Diagnose only, don't implement fix |
| Don't auto-commit the fix |
| 选项 | 作用 |
|---|---|
| 跳过回归测试创建 |
| 仅诊断,不实现修复 |
| 不自动提交修复 |
Workflow
工作流详情
Phase 1: Parse Arguments
阶段1:解析参数
bash
undefinedbash
undefinedParse 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
undefinedSCOPE="${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
undefinedPhase 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
undefinedDiagnosis 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:
- - [Change description]
path/to/file.ts:123
Risk Assessment: [Low/Medium/High] - [Why]
Proceed with fix? (yes/no/modify approach)
undefined实现思路: [修复方式]
需修改文件:
- - [更改说明]
path/to/file.ts:123
风险评估: [低/中/高] - [评估依据]
是否继续执行修复? (是/否/调整方案)
undefinedPhase 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 , create diagnostic handoff and exit here.
--dry-run必须执行: 实现修复前等待用户确认。
AskUserQuestion(
question="是否继续执行推荐的修复方案?",
options=["是", "否", "调整"]
)若用户选择“调整”,收集新需求并更新方案。
若用户选择“否”,创建诊断交接文档并退出。
若使用参数,在此环节创建诊断交接文档并退出。
--dry-runPhase 4.5: Risk Assessment (Premortem)
阶段4.5:风险评估(事前分析)
After diagnosis approval, before implementation:
Run a quick premortem on the proposed fix to catch risks:
/premortem quickContext 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
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
commitsleuth(排查)
|
v
[人工确认:诊断]
|
v
[事前分析:快速风险检查]
|
v
kraken(implement_task + TDD)
|
v
kraken(回归测试)
|
v
[人工确认:验证]
|
v
提交hook
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
commitdebug-hooks(结构化排查)
|
v
[人工确认:诊断]
|
v
[事前分析:快速风险检查]
|
v
kraken(implement_task + hook-developer模式)
|
v
手动测试钩子
|
v
[人工确认:验证]
|
v
提交deps
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
commitdependency-preflight(检查当前状态)
|
v
oracle(查找正确版本/替代方案)
|
v
plan-agent(创建修复计划)
|
v
[人工确认:诊断 + 计划评审]
|
v
[事前分析:快速风险检查]
|
v
kraken(implement_plan)
|
v
qlty-check
|
v
[人工确认:验证]
|
v
提交pr-comments
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-runyaml
---
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-runyaml
---
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}.yamlExamples
示例
Basic Bug Fix
基础Bug修复
/fix bug/fix bug-> Investigates, diagnoses, implements, tests, commits
-> 排查、诊断、实现、测试、提交
undefinedundefinedDiagnose Only
仅诊断
/fix bug --dry-run/fix bug --dry-run-> Investigates, creates diagnosis handoff, stops
-> 排查、创建诊断交接文档、退出
undefinedundefinedFix Without Auto-Commit
修复但不自动提交
/fix hook --no-commit/fix hook --no-commit-> Full fix workflow but stops before commit
-> 完整修复流程,但在提交前停止
undefinedundefinedQuick Fix (No Regression Test)
快速修复(无回归测试)
/fix bug --no-test/fix bug --no-test-> Implements fix, commits, no regression test
-> 实现修复、提交,不创建回归测试
undefinedundefinedAddress PR Comments
处理PR反馈
/fix pr-comments/fix pr-comments-> Fetches PR, creates plan, implements, commits
-> 获取PR、创建计划、实现、提交
undefinedundefinedError 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: Initial investigationdebug-hooks - : Parallel investigation agent
sleuth - : TDD implementation agent
kraken - : Single task implementation
implement_task - : Test creation
test-driven-development - : Complex fix planning
plan-agent - : Dependency checks
dependency-preflight - /
oracle: Context gatheringresearch-codebase - : PR context fetching
github-search - : Quality verification
qlty-check - : Risk assessment before implementation
premortem - : Git commit workflow
commit - : Session handoff
create_handoff
该技能编排以下技能:
- /
debug:初始排查debug-hooks - :并行排查Agent
sleuth - :TDD实现Agent
kraken - :单任务实现
implement_task - :测试创建
test-driven-development - :复杂修复规划
plan-agent - :依赖检查
dependency-preflight - /
oracle:上下文收集research-codebase - :PR上下文获取
github-search - :质量验证
qlty-check - :实现前风险评估
premortem - :Git提交工作流
commit - :会话交接
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 | |
The human checkpoints are critical for:
- Preventing wrong fixes from being implemented
- Ensuring user understands what changed
- Catching edge cases only humans notice
| 确认环节 | 目的 | 跳过条件 |
|---|---|---|
| 诊断后 | 确认根因 | 不可跳过 |
| 事前分析后 | 接受或缓解风险 | 无高风险问题 |
| 修复后 | 验证修复效果 | 不可跳过 |
| 提交前 | 查看更改 | |
人工确认环节至关重要,用于:
- 防止错误修复被实现
- 确保用户了解更改内容
- 发现仅人类能注意到的边缘场景