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.

Step	Action	Key Notes
1	Fetch issue details	`gh issue view` -- extract title, labels, stack traces
2	Understand the issue	Map expected vs actual behavior, reproduction steps
3	Evidence gathering	Multi-pattern search: imports, string literals, dynamic invocations
4	Root cause analysis	Rank causes by probability with file:line evidence
5	Propose fix	Minimal changes, risk assessment, test plan, rollback plan
6	Wait for approval	Present analysis -- DO NOT code without explicit user approval
7	Implement fix	Code 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:

"What assumptions am I making about this issue?"
"Have I verified this with actual code evidence?"
"Could I be wrong about the root cause?"

执行任何操作前，请确认：

"我对这个问题做出了哪些假设？"
"我是否已通过实际代码证据验证了这些假设？"
"我会不会对根因判断错误？"

Phase 1: Fetch Issue Details

阶段1：获取问题详情

Get issue information:
bash
```
gh issue view $ARGUMENTS
```
Extract key information:
- Issue title and description
- Labels (bug, feature, enhancement)
- Related PRs or issues
- Assignees and reviewers
- Stack traces or error messages

Create analysis notes at

.ai/workspace/analysis/issue-[number].md

获取问题信息：
bash
```
gh issue view $ARGUMENTS
```
提取关键信息：
- 问题标题与描述
- 标签（bug、feature、enhancement等）
- 相关PR或问题
- 经办人与审核人
- 堆栈跟踪或错误信息

在

.ai/workspace/analysis/issue-[number].md

创建分析笔记

Phase 2: Understand the Issue

阶段2：理解问题

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?
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

分析问题：
- 预期行为是什么？
- 实际行为是什么？
- 是否有复现步骤？
- 是否有堆栈跟踪或错误信息？
在代码库中搜索相关代码：
- 使用grep搜索错误信息与关键词
- 搜索模式：
```
.*EventHandler.*{Entity}
```
  、
```
.*Consumer.*{Entity}
```
  等
- 找到相关实体/组件
- 梳理受影响的代码路径

Phase 3: Evidence Gathering

阶段3：收集证据

Multi-pattern search:
- Static imports and usages
- String literals (runtime/config references)
- Dynamic invocations (reflection, attributes)
Trace dependency chains:
- Who calls this code?
- Who depends on this code?
- Cross-service message flows
Read actual implementations (not just interfaces)
Document evidence with file:line references

多模式搜索：
- 静态导入与用法
- 字符串字面量（运行时/配置引用）
- 动态调用（反射、属性）
追踪依赖链：
- 谁调用了这段代码？
- 谁依赖这段代码？
- 跨服务消息流
阅读实际实现代码（而非仅接口）
记录证据并标注文件:行号

Phase 4: Root Cause Analysis

阶段4：根因分析

Analyze across dimensions:

Technical: Code defects, architectural issues
Business Logic: Rule violations, validation failures
Data: Corruption, integrity violations, race conditions
Integration: API contract violations, cross-service failures
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%)

从以下维度分析：

技术层面：代码缺陷、架构问题
业务逻辑：规则违反、验证失败
数据层面：数据损坏、完整性违规、竞态条件
集成层面：API契约违反、跨服务故障
环境层面：配置问题、部署故障

需记录：

按概率排序的潜在根因
标注文件:行号的证据
置信度等级（高 90%+、中 70-89%、低 <70%）

Phase 5: Propose Fix

阶段5：提出修复方案

Design the fix:
- Minimal changes principle
- Follow platform patterns from documentation
- Consider edge cases
Risk assessment:
- Impact level (Low/Medium/High)
- Regression risk
- Affected components
Test plan:
- Unit tests to add
- Manual testing steps
- Regression considerations
Rollback plan:
- How to revert if fix causes issues

设计修复方案：
- 最小化修改原则
- 遵循文档中的平台模式
- 考虑边缘情况
风险评估：
- 影响等级（低/中/高）
- 回归风险
- 受影响组件
测试计划：
- 需添加的单元测试
- 手动测试步骤
- 回归测试考量
回滚计划：
- 若修复引发问题，如何回退

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:

待修改文件：

```
path/to/file.cs:line
```
- [change description]

Awaiting approval to proceed with implementation.


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

---

```
path/to/file.cs:line
```
- [修改描述]

等待批准以推进实施。


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

---

Phase 7: Implement Fix

阶段7：实施修复

After approval:

Make the code changes following platform patterns
Add/update tests
Verify fix works
Create PR with issue reference using
```
gh pr create
```

获得批准后：

遵循平台模式进行代码修改
添加/更新测试
验证修复效果
使用
```
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

始终规划并拆分多个小型待办任务
始终添加最终审查待办任务，在结束时回顾已完成工作，查找是否需要进一步修复或优化