fix-issue by yonatangross/orchestkit
npx skills add https://github.com/yonatangross/orchestkit --skill fix-issue包含钩子
此技能使用 Claude 钩子,可自动执行代码以响应事件。安装前请仔细审查。
系统化的问题解决,包含基于假设的根因分析、类似问题检测和预防建议。
/ork:fix-issue 123
/ork:fix-issue 456
Opus 4.6 : 根因分析使用原生自适应思维。动态令牌预算随上下文窗口扩展,以进行彻底调查。
ISSUE_NUMBER = "$ARGUMENTS[0]" # 例如,"123" (CC 2.1.59 索引访问)
# $ARGUMENTS 包含完整的参数字符串
# $ARGUMENTS[0] 是第一个以空格分隔的标记
在任何其他步骤之前运行。 检测可用的 MCP 服务器并检查可恢复状态。
# 探测 MCP (并行 — 全部在一个消息中):
ToolSearch(query="select:mcp__memory__search_nodes")
ToolSearch(query="select:mcp__context7__resolve-library-id")
# 写入能力映射:
Write(".claude/chain/capabilities.json", JSON.stringify({
"memory": <true if found>,
"context7": <true if found>,
"timestamp": now()
}))
# 检查可恢复状态:
Read(".claude/chain/state.json")
# 如果存在且 skill == "fix-issue":
# 读取上次交接,跳转到 current_phase
# 告诉用户: "从阶段 {N} 恢复"
# 如果不存在: 写入初始状态
Write(".claude/chain/state.json", JSON.stringify({
"skill": "fix-issue",
"issue": ISSUE_NUMBER,
"current_phase": 1,
"completed_phases": [],
"capabilities": capabilities
}))
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
加载模式详情:
Read("${CLAUDE_PLUGIN_ROOT}/skills/chain-patterns/references/mcp-detection.md")
根据 /effort 级别调整调查深度:
| 工作量级别 | 方法 | 智能体数量 | 阶段 |
|---|---|---|---|
| 低 | 快速修复: 读取 → 修复 → 测试 → 完成 | 0 个智能体 | 1, 6, 7, 11 |
| 中 | 标准: 调查 → 修复 → 测试 → 预防 | 2-3 个智能体 | 1-4, 6-8, 11 |
| 高 (默认) | 完整 RCA: 5 个并行智能体 → 修复 → 预防 → 经验总结 | 5 个智能体 | 所有 11 个阶段 |
覆盖: 明确的用户选择 (例如,"Proper fix") 会覆盖
/effort的降级调整。Hotfix 始终使用最少的阶段,无论工作量如何。
在创建任务之前,澄清修复方法:
AskUserQuestion(
questions=[{
"question": "您希望如何处理此修复?",
"header": "修复方法",
"options": [
{"label": "Proper fix (推荐)", "description": "完整的 RCA、回归测试、预防计划", "markdown": "```\nProper Fix (11 个阶段)\n──────────────────────\n 理解 ──▶ 提出假设 ──▶ RCA\n │ │ │\n ▼ ▼ ▼\n 5 个并行 排序后的 已确认的\n 智能体 假设 根本原因\n │\n ▼\n 修复 ──▶ 验证 ──▶ 预防 ──▶ PR\n + 回归测试 + 运行手册\n```"},
{"label": "快速修复", "description": "最小化调查,修复并测试", "markdown": "```\n快速修复 (~10 分钟)\n───────────────────\n 阅读问题 ──▶ 修复 ──▶ 测试 ──▶ PR\n\n 跳过: 完整 RCA、预防计划、\n 运行手册、经验总结\n 保留: 回归测试 (强制)\n```"},
{"label": "先调查", "description": "在决定方法前进行深入分析", "markdown": "```\n先调查\n─────────────────\n 阅读问题 ──▶ 5 个并行智能体 ──▶ 报告\n\n 输出: 根因分析\n + 假设排序\n + 推荐方法\n 暂无代码更改\n```"},
{"label": "热修复", "description": "紧急修复,流程最简化", "markdown": "```\n热修复 (紧急)\n──────────────────\n 阅读问题 ──▶ 修复 ──▶ 推送\n\n 跳过: 智能体、RCA、预防\n 保留: 基本测试验证\n 修复后: 安排适当的 RCA\n```"}
],
"multiSelect": false
}]
)
根据答案调整工作流:
如果选择了 '先调查':
# 1. 进入只读计划模式
EnterPlanMode("调查问题: $ISSUE_REF")
# 2. 调查阶段 — 仅 Read/Grep/Glob,无 Write/Edit
# - 阅读问题描述和链接的上下文
# - 通过相关代码追踪错误路径
# - 搜索相关问题、过去的修复、测试失败
# - 构建带证据的假设列表
# 3. 生成 RCA 报告:
# - 根本原因假设 (按置信度排序)
# - 受影响的文件和影响范围
# - 推荐方法 (proper fix 与 quick fix)
# - 风险评估
# 4. 退出计划模式 — 返回分析供用户决策
ExitPlanMode()
# 5. 用户审查 RCA。如果"继续修复" → 继续到阶段 5 (修复)。
# 如果"需要更多信息" → 重新进入调查。
加载 Read("${CLAUDE_SKILL_DIR}/rules/evidence-gathering.md") 以获取每种方法的详细工作流调整。
选择 智能体团队 (网状) 或 任务工具 (星形)。加载 Read("${CLAUDE_SKILL_DIR}/references/agent-selection.md") 以获取选择标准、成本比较和任务创建模式。
当问题涉及正在运行的 Web 应用、API 或 UI 错误时,在 形成假设之前,发现服务并进行可视化检查:
# 1. 通过 Portless 发现服务 (首选)
portless list 2>/dev/null
# api → api.localhost:1355 (端口 8080)
# app → app.localhost:1355 (端口 3000)
# 2. 备选方案: 手动发现端口
lsof -iTCP -sTCP:LISTEN -nP | grep -E 'node|python|java'
# 3. 使用 agent-browser 进行可视化检查
agent-browser open "http://app.localhost:1355"
agent-browser screenshot /tmp/issue-before.png # 捕获故障状态
agent-browser console # 检查 JS 错误
agent-browser network log # 检查失败的 API 调用
agent-browser get text @error-banner # 提取错误消息
在所有调查步骤中使用 Portless 命名 URL (*.localhost:1355) — 它们稳定、自文档化,并消除了端口猜测失败。使用 npm i -g portless 安装。
| 阶段 | 活动 | 输出 |
|---|---|---|
| 1. 理解问题 | 阅读 GitHub 问题详情 | 问题陈述 |
| 1b. 服务发现 | Portless list, agent-browser 可视化检查 | 服务 URL、截图 |
| 2. 类似问题检测 | 搜索相关的过去问题 | 相关问题列表 |
| 3. 假设形成 | 形成带置信度分数的假设 | 排序后的假设 |
| 4. 根因分析 | 5 个并行智能体调查 | 已确认的根本原因 |
| 5. 修复设计 | 基于 RCA 设计方法 | 修复规范 |
| 6. 实施 | 应用修复并进行测试 | 工作代码 |
| 7. 验证 | 验证修复解决问题,截图修复后状态 | 证据 |
| 8. 预防 | 如何防止再次发生 | 预防计划 |
| 9. 运行手册 | 创建/更新运行手册条目 | 运行手册 |
| 10. 经验总结 | 捕获知识 | 持久化的经验 |
| 11. 提交和 PR | 创建包含修复的 PR | 已合并的 PR |
增量式 输出每个阶段完成后的结果 — 不要等到 PR 才批量输出:
| 阶段之后 | 向用户展示 |
|---|---|
| 1. 理解问题 | 问题陈述、受影响文件 |
| 3. 假设形成 | 带置信度分数的排序假设 |
| 4. RCA | 已确认的根本原因、证据链 |
| 6. 实施 | 修复描述、更改的文件 |
| 7. 验证 | 测试结果、修复前后行为 |
对于使用 5 个并行 RCA 智能体的 proper fix 路径,在它们返回时 输出每个智能体的发现 — 不要等待所有 5 个。如果一个智能体早期就以高置信度识别出根本原因,立即标记它,以便用户可以确认并跳过剩余的智能体。
在阶段 3, 4, 6, 7 之后将交接 JSON 写入 .claude/chain/。有关模式,请参阅 chain-patterns 技能。
| 阶段之后 | 交接文件 | 关键输出 |
|---|---|---|
| 3. 假设 | 03-hypotheses.json | 带置信度分数的排序假设 |
| 4. RCA | 04-rca.json | 已确认的根本原因、证据、受影响文件 |
| 6. 实施 | 06-fix.json | 修复描述、更改的文件、测试计划 |
| 7. 验证 | 07-validation.json | 测试结果、覆盖率差异 |
阶段 4 的智能体在需要编辑文件时应该使用 isolation: "worktree":
Agent(subagent_type="debug-investigator",
prompt="调查假设: {desc}...",
isolation="worktree", run_in_background=true)
在阶段 11 (提交 + PR) 之后,安排 CI 监控:
# 防护: 在 headless/CI 中跳过 cron (CLAUDE_CODE_DISABLE_CRON)
# 如果设置了环境变量 CLAUDE_CODE_DISABLE_CRON,则运行单次检查
CronCreate(
schedule="*/5 * * * *",
prompt="检查 PR #{pr_number} 的 CI: gh pr checks {pr_number} --repo {repo}。
全部通过 → CronDelete 此作业。任何失败 → 使用详细信息发出警报。"
)
如果在阶段 4 中使用了工作树隔离,请在验证后进行清理:
# 在阶段 7 验证通过后 — 退出工作树,为 PR 保留分支
ExitWorktree(action="keep")
每个 EnterWorktree 或 isolation: "worktree" 智能体都必须有匹配的清理操作。如果智能体使用了 isolation: "worktree",它们会处理自己的退出 — 但如果主导者在步骤 0 中进入了工作树,则必须在阶段 11 提交之前调用 ExitWorktree。
如果内存 MCP 可用 (来自步骤 -1 的探测),保存修复模式:
if capabilities.memory:
mcp__memory__create_entities([{
name: "fix-pattern-{slug}",
entityType: "fix-pattern",
observations: [root_cause, fix_description, regression_test, issue_ref]
}])
完整阶段详情 : 加载
Read("${CLAUDE_SKILL_DIR}/references/fix-phases.md")以获取每个阶段的 bash 命令、模板和程序。
加载
Read("${CLAUDE_SKILL_DIR}/references/cc-enhancements.md")以获取会话恢复、任务指标、工具指导、工作树隔离和自适应思维。
| 规则 | 影响 | 涵盖内容 |
|---|---|---|
evidence-gathering (加载 ${CLAUDE_SKILL_DIR}/rules/evidence-gathering.md) | 高 | 用户意图验证、置信度量表、关键决策 |
rca-five-whys (加载 ${CLAUDE_SKILL_DIR}/rules/rca-five-whys.md) | 高 | 5 Whys 迭代因果分析 |
rca-fishbone (加载 ${CLAUDE_SKILL_DIR}/rules/rca-fishbone.md) | 中 | 石川图、多因素分析 |
rca-fault-tree (加载 ${CLAUDE_SKILL_DIR}/rules/rca-fault-tree.md) | 中 | 故障树分析、AND/OR 门、关键系统 |
ork:commit - 提交问题修复debug-investigator - 调试复杂问题browser-tools - 使用 agent-browser + Portless 进行可视化检查ork:issue-progress-tracking - 从提交自动更新ork:remember - 存储经验总结使用 Read("${CLAUDE_SKILL_DIR}/references/<file>") 按需加载:
| 文件 | 内容 |
|---|---|
fix-phases.md | 每个阶段的 Bash 命令、模板、程序 |
agent-selection.md | 编排模式选择标准和成本比较 |
similar-issue-search.md | 类似问题检测模式 |
hypothesis-rca.md | 基于假设的根因分析 |
agent-teams-rca.md | 智能体团队 RCA 工作流 |
prevention-patterns.md | 复发预防模式 |
cc-enhancements.md | CC 2.1.49 会话恢复、任务指标、自适应思维 |
版本: 2.4.0 (2026年3月) — 丰富的引导选项用于修复方法,渐进式输出用于增量阶段结果
每周安装
85
仓库
GitHub 星标
134
首次出现
2026年1月22日
安全审计
安装于
gemini-cli77
opencode77
codex75
github-copilot74
claude-code72
cursor71
Contains Hooks
This skill uses Claude hooks which can execute code automatically in response to events. Review carefully before installing.
Systematic issue resolution with hypothesis-based root cause analysis, similar issue detection, and prevention recommendations.
/ork:fix-issue 123
/ork:fix-issue 456
Opus 4.6 : Root cause analysis uses native adaptive thinking. Dynamic token budgets scale with context window for thorough investigation.
ISSUE_NUMBER = "$ARGUMENTS[0]" # e.g., "123" (CC 2.1.59 indexed access)
# $ARGUMENTS contains the full argument string
# $ARGUMENTS[0] is the first space-separated token
Run BEFORE any other step. Detect available MCP servers and check for resumable state.
# Probe MCPs (parallel — all in ONE message):
ToolSearch(query="select:mcp__memory__search_nodes")
ToolSearch(query="select:mcp__context7__resolve-library-id")
# Write capability map:
Write(".claude/chain/capabilities.json", JSON.stringify({
"memory": <true if found>,
"context7": <true if found>,
"timestamp": now()
}))
# Check for resumable state:
Read(".claude/chain/state.json")
# If exists and skill == "fix-issue":
# Read last handoff, skip to current_phase
# Tell user: "Resuming from Phase {N}"
# If not exists: write initial state
Write(".claude/chain/state.json", JSON.stringify({
"skill": "fix-issue",
"issue": ISSUE_NUMBER,
"current_phase": 1,
"completed_phases": [],
"capabilities": capabilities
}))
Load pattern details:
Read("${CLAUDE_PLUGIN_ROOT}/skills/chain-patterns/references/mcp-detection.md")
Scale investigation depth based on /effort level:
| Effort Level | Approach | Agents | Phases |
|---|---|---|---|
| low | Quick fix: read → fix → test → done | 0 agents | 1, 6, 7, 11 |
| medium | Standard: investigate → fix → test → prevent | 2-3 agents | 1-4, 6-8, 11 |
| high (default) | Full RCA: 5 parallel agents → fix → prevent → lessons | 5 agents | All 11 phases |
Override: Explicit user selection (e.g., "Proper fix") overrides
/effortdownscaling. Hotfix always uses minimal phases regardless of effort.
BEFORE creating tasks , clarify fix approach:
AskUserQuestion(
questions=[{
"question": "How do you want to approach this fix?",
"header": "Fix Approach",
"options": [
{"label": "Proper fix (Recommended)", "description": "Full RCA, regression test, prevention plan", "markdown": "```\nProper Fix (11 phases)\n──────────────────────\n Understand ──▶ Hypothesize ──▶ RCA\n │ │ │\n ▼ ▼ ▼\n 5 parallel Ranked Confirmed\n agents hypotheses root cause\n │\n ▼\n Fix ──▶ Validate ──▶ Prevent ──▶ PR\n + regression test + runbook\n```"},
{"label": "Quick fix", "description": "Minimal investigation, fix and test", "markdown": "```\nQuick Fix (~10 min)\n───────────────────\n Read issue ──▶ Fix ──▶ Test ──▶ PR\n\n Skip: full RCA, prevention plan,\n runbook, lessons learned\n Keep: regression test (mandatory)\n```"},
{"label": "Investigate first", "description": "Deep analysis before deciding on approach", "markdown": "```\nInvestigate First\n─────────────────\n Read issue ──▶ 5 parallel agents ──▶ Report\n\n Output: Root cause analysis\n + hypothesis ranking\n + recommended approach\n No code changes yet\n```"},
{"label": "Hotfix", "description": "Emergency fix, minimal process", "markdown": "```\nHotfix (emergency)\n──────────────────\n Read issue ──▶ Fix ──▶ Push\n\n Skip: agents, RCA, prevention\n Keep: basic test verification\n Post-fix: schedule proper RCA\n```"}
],
"multiSelect": false
}]
)
Based on answer, adjust workflow:
If 'Investigate first' selected:
# 1. Enter read-only plan mode
EnterPlanMode("Investigate issue: $ISSUE_REF")
# 2. Investigation phase — Read/Grep/Glob ONLY, no Write/Edit
# - Read the issue description and linked context
# - Trace the error path through relevant code
# - Search for related issues, past fixes, test failures
# - Build hypothesis list with evidence
# 3. Produce RCA report:
# - Root cause hypothesis (ranked by confidence)
# - Affected files and blast radius
# - Recommended approach (proper fix vs quick fix)
# - Risk assessment
# 4. Exit plan mode — returns analysis for user decision
ExitPlanMode()
# 5. User reviews RCA. If "proceed with fix" → continue to Phase 5 (Fix).
# If "need more info" → re-enter investigation.
Load Read("${CLAUDE_SKILL_DIR}/rules/evidence-gathering.md") for detailed workflow adjustments per approach.
Choose Agent Teams (mesh) or Task tool (star). Load Read("${CLAUDE_SKILL_DIR}/references/agent-selection.md") for the selection criteria, cost comparison, and task creation patterns.
When the issue involves a running web app, API, or UI bug, discover services and inspect visually before forming hypotheses:
# 1. Discover services via Portless (preferred)
portless list 2>/dev/null
# api → api.localhost:1355 (port 8080)
# app → app.localhost:1355 (port 3000)
# 2. Fallback: discover ports manually
lsof -iTCP -sTCP:LISTEN -nP | grep -E 'node|python|java'
# 3. Visual inspection with agent-browser
agent-browser open "http://app.localhost:1355"
agent-browser screenshot /tmp/issue-before.png # capture broken state
agent-browser console # check for JS errors
agent-browser network log # inspect failed API calls
agent-browser get text @error-banner # extract error messages
Use Portless named URLs (*.localhost:1355) in all investigation steps — they're stable, self-documenting, and eliminate port-guessing failures. Install with npm i -g portless.
| Phase | Activities | Output |
|---|---|---|
| 1. Understand Issue | Read GitHub issue details | Problem statement |
| 1b. Service Discovery | Portless list, agent-browser visual inspection | Service URLs, screenshots |
| 2. Similar Issue Detection | Search for related past issues | Related issues list |
| 3. Hypothesis Formation | Form hypotheses with confidence scores | Ranked hypotheses |
| 4. Root Cause Analysis | 5 parallel agents investigate | Confirmed root cause |
| 5. Fix Design | Design approach based on RCA | Fix specification |
| 6. Implementation | Apply fix with tests | Working code |
Output results incrementally as each phase completes — don't batch until the PR:
| After Phase | Show User |
|---|---|
| 1. Understand Issue | Problem statement, affected files |
| 3. Hypothesis Formation | Ranked hypotheses with confidence scores |
| 4. RCA | Confirmed root cause, evidence chain |
| 6. Implementation | Fix description, files changed |
| 7. Validation | Test results, before/after behavior |
For the proper fix path with 5 parallel RCA agents, output each agent's findings as they return — don't wait for all 5. If one agent identifies the root cause with high confidence early, flag it immediately so the user can confirm and skip remaining agents.
Write handoff JSON after phases 3, 4, 6, 7 to .claude/chain/. See chain-patterns skill for schema.
| After Phase | Handoff File | Key Outputs |
|---|---|---|
| 3. Hypothesis | 03-hypotheses.json | Ranked hypotheses with confidence scores |
| 4. RCA | 04-rca.json | Confirmed root cause, evidence, affected files |
| 6. Implementation | 06-fix.json | Fix description, files changed, test plan |
| 7. Validation | 07-validation.json | Test results, coverage delta |
Phase 4 agents SHOULD use isolation: "worktree" when they need to edit files:
Agent(subagent_type="debug-investigator",
prompt="Investigate hypothesis: {desc}...",
isolation="worktree", run_in_background=true)
After Phase 11 (commit + PR), schedule CI monitoring:
# Guard: Skip cron in headless/CI (CLAUDE_CODE_DISABLE_CRON)
# if env CLAUDE_CODE_DISABLE_CRON is set, run a single check instead
CronCreate(
schedule="*/5 * * * *",
prompt="Check CI for PR #{pr_number}: gh pr checks {pr_number} --repo {repo}.
All pass → CronDelete this job. Any fail → alert with details."
)
If worktree isolation was used in Phase 4, clean up after validation:
# After Phase 7 validation passes — exit worktree, keep branch for PR
ExitWorktree(action="keep")
Every EnterWorktree or isolation: "worktree" agent must have a matching cleanup. If agents used isolation: "worktree", they handle their own exit — but if the lead entered a worktree in Step 0, it must call ExitWorktree before Phase 11 commit.
If memory MCP is available (from Step -1 probe), save the fix pattern:
if capabilities.memory:
mcp__memory__create_entities([{
name: "fix-pattern-{slug}",
entityType: "fix-pattern",
observations: [root_cause, fix_description, regression_test, issue_ref]
}])
Full phase details : Load
Read("${CLAUDE_SKILL_DIR}/references/fix-phases.md")for bash commands, templates, and procedures for each phase.
Load
Read("${CLAUDE_SKILL_DIR}/references/cc-enhancements.md")for session resume, task metrics, tool guidance, worktree isolation, and adaptive thinking.
| Rule | Impact | What It Covers |
|---|---|---|
evidence-gathering (load ${CLAUDE_SKILL_DIR}/rules/evidence-gathering.md) | HIGH | User intent verification, confidence scale, key decisions |
rca-five-whys (load ${CLAUDE_SKILL_DIR}/rules/rca-five-whys.md) | HIGH | 5 Whys iterative causal analysis |
rca-fishbone (load ${CLAUDE_SKILL_DIR}/rules/rca-fishbone.md) | MEDIUM | Ishikawa diagram, multi-factor analysis |
rca-fault-tree (load ${CLAUDE_SKILL_DIR}/rules/rca-fault-tree.md) | MEDIUM | Fault tree analysis, AND/OR gates, critical systems |
ork:commit - Commit issue fixesdebug-investigator - Debug complex issuesbrowser-tools - Visual inspection with agent-browser + Portlessork:issue-progress-tracking - Auto-updates from commitsork:remember - Store lessons learnedLoad on demand with Read("${CLAUDE_SKILL_DIR}/references/<file>"):
| File | Content |
|---|---|
fix-phases.md | Bash commands, templates, procedures per phase |
agent-selection.md | Orchestration mode selection criteria and cost comparison |
similar-issue-search.md | Similar issue detection patterns |
hypothesis-rca.md | Hypothesis-based root cause analysis |
agent-teams-rca.md | Agent Teams RCA workflow |
prevention-patterns.md |
Version: 2.4.0 (March 2026) — Rich elicitation with options for fix approach, progressive output for incremental phase results
Weekly Installs
85
Repository
GitHub Stars
134
First Seen
Jan 22, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykWarn
Installed on
gemini-cli77
opencode77
codex75
github-copilot74
claude-code72
cursor71
Skills CLI 使用指南:AI Agent 技能包管理器安装与管理教程
46,600 周安装
| 7. Validation |
| Verify fix resolves issue, screenshot after state |
| Evidence |
| 8. Prevention | How to prevent recurrence | Prevention plan |
| 9. Runbook | Create/update runbook entry | Runbook |
| 10. Lessons Learned | Capture knowledge | Persisted learnings |
| 11. Commit and PR | Create PR with fix | Merged PR |
| Recurrence prevention patterns |
cc-enhancements.md | CC 2.1.49 session resume, task metrics, adaptive thinking |