Back to Details

fix-issue

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Fix GitHub Issue: $ARGUMENTS

修复GitHub问题：$ARGUMENTS

Fix a GitHub issue following the systematic debugging workflow based on the 
debug
skill.
基于
debug
skill，遵循系统化调试流程修复GitHub问题。

Summary

概述

Goal: Systematically diagnose and fix a GitHub issue with evidence-based root cause analysis and user approval before implementation.
StepActionKey Notes
1Fetch issue details
gh issue view
-- extract title, labels, stack traces
2Understand the issueMap expected vs actual behavior, reproduction steps
3Evidence gatheringMulti-pattern search: imports, string literals, dynamic invocations
4Root cause analysisRank causes by probability with file:line evidence
5Propose fixMinimal changes, risk assessment, test plan, rollback plan
6Wait for approvalPresent analysis -- DO NOT code without explicit user approval
7Implement fixCode changes, tests, PR creation
Key Principles:
  • Always use external memory at 
    .ai/workspace/analysis/issue-[number].md
  • If confidence < 90%, request user confirmation before proceeding
  • Never make code changes without explicit user approval
IMPORTANT: Always use external memory at 
.ai/workspace/analysis/issue-[number].md
for structured analysis.
目标： 通过基于证据的根因分析系统化诊断并修复GitHub问题，且在实施前获得用户批准。
步骤操作关键说明
1获取问题详情使用
gh issue view
-- 提取标题、标签、堆栈跟踪信息
2理解问题梳理预期行为与实际行为的差异，明确复现步骤
3收集证据多模式搜索：导入语句、字符串字面量、动态调用
4根因分析结合文件:行号证据，按概率排序可能的原因
5提出修复方案最小化修改、风险评估、测试计划、回滚计划
6等待批准提交分析结果 -- 未获得用户明确批准前请勿编写代码
7实施修复代码修改、测试、创建PR
核心原则：
  • 始终使用外部存储
    .ai/workspace/analysis/issue-[number].md
    记录分析内容
  • 若置信度低于90%，请在继续前请求用户确认
  • 未获得用户明确批准前，绝不进行代码修改
重要提示：务必使用外部存储
.ai/workspace/analysis/issue-[number].md
进行结构化分析。

IMPORTANT: Anti-Hallucination Protocols

重要提示：防幻觉协议

Before any operation:
  1. "What assumptions am I making about this issue?"
  2. "Have I verified this with actual code evidence?"
  3. "Could I be wrong about the root cause?"
执行任何操作前，请确认：
  1. "我对这个问题做出了哪些假设？"
  2. "我是否已通过实际代码证据验证了这些假设？"
  3. "我会不会对根因判断错误？"

Phase 1: Fetch Issue Details

阶段1：获取问题详情

  1. Get issue information:
    bash
    gh issue view $ARGUMENTS
  2. Extract key information:
    • Issue title and description
    • Labels (bug, feature, enhancement)
    • Related PRs or issues
    • Assignees and reviewers
    • Stack traces or error messages
  3. Create analysis notes at 
    .ai/workspace/analysis/issue-[number].md
  1. 获取问题信息：
    bash
    gh issue view $ARGUMENTS
  2. 提取关键信息：
    • 问题标题与描述
    • 标签（bug、feature、enhancement等）
    • 相关PR或问题
    • 经办人与审核人
    • 堆栈跟踪或错误信息
  3. 在
    .ai/workspace/analysis/issue-[number].md
    创建分析笔记

Phase 2: Understand the Issue

阶段2：理解问题

  1. Analyze the issue:
    • What is the expected behavior?
    • What is the actual behavior?
    • Are there reproduction steps?
    • Is there a stack trace or error message?
  2. Search codebase for relevant code:
    • Use grep for error messages and keywords
    • Search patterns: 
      .*EventHandler.*{Entity}
      , 
      .*Consumer.*{Entity}
      , etc.
    • Find related entities/components
    • Map the affected code paths
  1. 分析问题：
    • 预期行为是什么？
    • 实际行为是什么？
    • 是否有复现步骤？
    • 是否有堆栈跟踪或错误信息？
  2. 在代码库中搜索相关代码：
    • 使用grep搜索错误信息与关键词
    • 搜索模式：
      .*EventHandler.*{Entity}
      、
      .*Consumer.*{Entity}
      等
    • 找到相关实体/组件
    • 梳理受影响的代码路径

Phase 3: Evidence Gathering

阶段3：收集证据

  1. Multi-pattern search:
    • Static imports and usages
    • String literals (runtime/config references)
    • Dynamic invocations (reflection, attributes)
  2. Trace dependency chains:
    • Who calls this code?
    • Who depends on this code?
    • Cross-service message flows
  3. Read actual implementations (not just interfaces)
  4. Document evidence with file:line references
  1. 多模式搜索：
    • 静态导入与用法
    • 字符串字面量（运行时/配置引用）
    • 动态调用（反射、属性）
  2. 追踪依赖链：
    • 谁调用了这段代码？
    • 谁依赖这段代码？
    • 跨服务消息流
  3. 阅读实际实现代码（而非仅接口）
  4. 记录证据并标注文件:行号

Phase 4: Root Cause Analysis

阶段4：根因分析

Analyze across dimensions:
  1. Technical: Code defects, architectural issues
  2. Business Logic: Rule violations, validation failures
  3. Data: Corruption, integrity violations, race conditions
  4. Integration: API contract violations, cross-service failures
  5. Environmental: Configuration issues, deployment problems
Document:
  • Potential root causes ranked by probability
  • Evidence with file:line references
  • Confidence level (High 90%+, Medium 70-89%, Low <70%)
从以下维度分析：
  1. 技术层面：代码缺陷、架构问题
  2. 业务逻辑：规则违反、验证失败
  3. 数据层面：数据损坏、完整性违规、竞态条件
  4. 集成层面：API契约违反、跨服务故障
  5. 环境层面：配置问题、部署故障
需记录：
  • 按概率排序的潜在根因
  • 标注文件:行号的证据
  • 置信度等级（高 90%+、中 70-89%、低 <70%）

Phase 5: Propose Fix

阶段5：提出修复方案

  1. Design the fix:
    • Minimal changes principle
    • Follow platform patterns from documentation
    • Consider edge cases
  2. Risk assessment:
    • Impact level (Low/Medium/High)
    • Regression risk
    • Affected components
  3. Test plan:
    • Unit tests to add
    • Manual testing steps
    • Regression considerations
  4. Rollback plan:
    • How to revert if fix causes issues
  1. 设计修复方案：
    • 最小化修改原则
    • 遵循文档中的平台模式
    • 考虑边缘情况
  2. 风险评估：
    • 影响等级（低/中/高）
    • 回归风险
    • 受影响组件
  3. 测试计划：
    • 需添加的单元测试
    • 手动测试步骤
    • 回归测试考量
  4. 回滚计划：
    • 若修复引发问题，如何回退

Phase 6: Wait for Approval

阶段6：等待批准

CRITICAL: Present your analysis and proposed fix in this format:
markdown
undefined
关键注意事项： 请按以下格式提交分析结果与修复方案：
markdown
undefined

Issue Analysis Complete - Approval Required

问题分析完成 - 等待批准

Issue

问题

#[number] - [title]
#[编号] - [title]

Root Cause Summary

根因总结

[Primary root cause with evidence at file:line]
[主要根因，附带文件:行号证据]

Proposed Fix

修复方案

[Fix description with specific files and changes]
[修复描述，包含具体文件与修改内容]

Risk Assessment

风险评估

  • Risk Level: [Low/Medium/High]
  • Regression Risk: [assessment]
  • 风险等级：[低/中/高]
  • 回归风险：[评估结果]

Confidence Level: [X%]

置信度等级：[X%]

Files to Modify:

待修改文件：

  1. path/to/file.cs:line
    - [change description]
Awaiting approval to proceed with implementation.

**DO NOT** make any code changes without explicit user approval.

---
  1. path/to/file.cs:line
    - [修改描述]
等待批准以推进实施。

**请勿**在未获得用户明确批准的情况下进行任何代码修改。

---

Phase 7: Implement Fix

阶段7：实施修复

After approval:
  1. Make the code changes following platform patterns
  2. Add/update tests
  3. Verify fix works
  4. Create PR with issue reference using 
    gh pr create
获得批准后：
  1. 遵循平台模式进行代码修改
  2. 添加/更新测试
  3. 验证修复效果
  4. 使用
    gh pr create
    创建关联问题的PR

Quick Verification Checklist

快速验证清单

Before proposing any change:
  • Searched static imports?
  • Searched string literals?
  • Checked dynamic invocations?
  • Read actual implementations?
  • Traced dependencies?
  • Assessed what breaks?
  • Documented evidence?
  • Declared confidence?
If ANY unchecked → DO MORE INVESTIGATION If confidence < 90% → REQUEST USER CONFIRMATION
Use the 
debug
skill for the complete debugging protocol. For autonomous mode, use 
debugging --autonomous
. ⚠️ MUST READ 
.ai/docs/AI-DEBUGGING-PROTOCOL.md
for comprehensive guidelines.
在提出任何修改前，请确认：
  • 是否已搜索静态导入？
  • 是否已搜索字符串字面量？
  • 是否已检查动态调用？
  • 是否已阅读实际实现代码？
  • 是否已追踪依赖关系？
  • 是否已评估修改影响？
  • 是否已记录证据？
  • 是否已声明置信度？
若有任何未勾选项 → 需进一步调查 若置信度 < 90% → 请求用户确认
如需完整调试协议，请使用
debug
skill。若使用自主模式，请使用
debugging --autonomous
。 ⚠️ 必读 
.ai/docs/AI-DEBUGGING-PROTOCOL.md
以获取全面指南。

IMPORTANT Task Planning Notes

重要任务规划说明

  • Always plan and break many small todo tasks
  • Always add a final review todo task to review the works done at the end to find any fix or enhancement needed
  • 始终规划并拆分多个小型待办任务
  • 始终添加最终审查待办任务，在结束时回顾已完成工作，查找是否需要进一步修复或优化