---
name: gitea-process-issue
description: 手动处理单个 Issue
arguments:
  - name: issue_number
    description: Issue 编号
    required: true
---

手动处理指定的 Issue，启动 Agent 实现代码和创建 PR。

## 工作流程

### 第一步：获取 Issue 详情

依据 `.claude/commands/gitea/API-QUICK-REFERENCE.md` 文档中的 Issue 操作指南获取 Issue 详情。

### 第二步：解析 Issue 信息

从 Issue 提取：
- 标题和描述
- 标签（类型、优先级）
- 依赖关系（从描述中解析）

### 第三步：检查依赖

解析 Issue 描述中的依赖标记：
```markdown
## 依赖关系
- 前置 Issue: #1, #2
```

依据 `.claude/commands/gitea/API-QUICK-REFERENCE.md` 文档中的 Issue 操作指南检查前置 Issue 是否已完成。

### 第四步：启动 Code Agent

使用 Agent 工具启动 general-purpose Agent 处理 Issue。

**Agent 提示词模板**：
```
处理 Gitea Issue #${issue_number}

## Issue 信息
标题: ${issue_title}
描述: ${issue_body}
标签: ${labels}

## 工作流程

### 1. 准备工作
首先检查当前 Git 状态：
```bash
git status
git branch
```

### 2. 创建特性分支
```bash
git checkout main
git pull origin main
git checkout -b feature/issue-${issue_number}
```

### 3. 分析需求
仔细阅读 Issue 描述，理解需要实现的功能。

### 4. 探索现有代码
使用 Glob 和 Grep 工具了解项目结构：
- 查找相关的源代码文件
- 了解现有的代码组织方式
- 识别可以复用的模块

### 5. 增量式实现代码
重要原则：
- 只实现 Issue 要求的功能
- 不重复已有代码
- 遵循项目代码规范
- 保持代码简洁

使用 Read 工具读取现有代码，然后使用 Edit 或 Write 工具添加新代码。

### 6. 生成测试代码
根据功能特点生成适当的测试：
- 对于数据模型：单元测试
- 对于业务逻辑：单元测试 + 集成测试
- 对于 UI 组件：UI 测试（如果适用）

测试文件命名规范：
- 单元测试: `Tests/Editor/{ClassName}Tests.cs`
- 集成测试: `Tests/Integration/{FeatureName}Tests.cs`

### 7. 运行测试（如果有测试框架）
```bash
# 如果是 Unity 项目，使用 Unity Test Runner
# 如果有其他测试框架，运行相应命令
```

如果测试失败：
- 分析失败原因
- 修复代码
- 重新运行测试
- 重复直到测试通过

### 8. 提交代码
```bash
git add .
git commit -m "feat(${module}): 实现 Issue #${issue_number} - ${feature_name}

- 实现了 XXX 功能
- 添加了 YYY 测试
- 修复了 ZZZ 问题

Closes #${issue_number}"
```

### 9. 推送到远程
```bash
git push -u origin feature/issue-${issue_number}
```

### 10. 创建 Pull Request

依据 `.claude/commands/gitea/API-QUICK-REFERENCE.md` 文档中的 Pull Request 操作指南创建 PR。

### 11. 在 Issue 中添加评论

依据 `.claude/commands/gitea/API-QUICK-REFERENCE.md` 文档中的 Issue 评论操作指南在 Issue 中添加评论说明已创建 PR。

## 重要提示

1. **增量式开发**: 不要重新生成整个项目，只添加新的功能
2. **测试覆盖**: 必须生成测试代码，测试覆盖率目标 > 80%
3. **代码质量**: 遵循项目代码规范，保持代码整洁
4. **原子提交**: 每次提交应该是一个完整的、可工作的变更
5. **PR 描述**: PR 描述应该清晰说明变更内容和测试结果

## 错误处理

- 如果依赖未满足：报告并退出
- 如果分支已存在：询问是否继续或使用新分支名
- 如果测试失败：分析失败原因，修复代码，重试
- 如果 PR 创建失败：报告错误并建议手动创建
```

### 第五步：等待 Agent 完成

使用 TaskOutput 监控 Agent 的执行进度和结果。

### 第六步：报告结果

显示处理结果：
- 创建的分支名称
- 创建的 PR 编号
- 测试结果
- 下一步建议

## 示例输出

```
🔧 处理 Issue #3
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

✅ 获取 Issue 详情
  • 标题: [功能] 任务增删改查核心功能
  • 标签: 功能, 优先级:中
  • 依赖: Issue #2

✅ 检查依赖
  • Issue #2: ✅ 已完成

🤖 启动 Code Agent
  • 分支: feature/issue-3
  • Agent ID: agent-xyz789

⏳ Agent 工作中...
  [Agent 输出会实时显示]

✅ Agent 完成

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📋 处理结果:

  ✅ 分支创建成功: feature/issue-3
  ✅ 代码实现完成: 5 个文件
  ✅ 测试通过: 12/12
  ✅ Pull Request 创建: #3
  ✅ Issue 评论已添加

🔗 链接:
  • PR: http://192.168.2.200:3000/chen/task-manager-unity/pulls/3
  • Issue: http://192.168.2.200:3000/chen/task-manager-unity/issues/3

💡 下一步:
  • 等待 PR 审核
  • 或使用 /gitea-status 查看状态
```

## 注意事项

1. **依赖检查**: 必须确保依赖 Issue 已完成
2. **分支命名**: 使用 `feature/issue-{number}` 格式
3. **测试要求**: 测试覆盖率必须 > 80%
4. **原子性**: 每个 Issue 应该是一个完整的功能单元
5. **冲突处理**: 如果有冲突，需要手动解决

## 错误场景

### 依赖未满足
```
❌ 无法处理 Issue #3

原因: 依赖 Issue #2 未完成
状态: Issue #2 当前状态为 open

💡 建议:
  • 先完成 Issue #2
  • 或修改 Issue #3 的依赖关系
```

### 分支已存在
```
⚠️  分支已存在: feature/issue-3

选项:
1. 继续在现有分支上工作
2. 创建新分支: feature/issue-3-v2
3. 取消操作

请选择: _
```

### 测试失败
```
❌ 测试失败

失败的测试:
  • TaskManagerTests.CreateTask_ShouldSetDefaultValues
  • TaskManagerTests.DeleteTask_ShouldRemoveFromList

💡 Agent 正在尝试修复...
```

## 相关命令

- `/gitea-status` - 查看项目状态
- `/gitea-start-scheduler` - 启动自动处理
- `/gitea-init-project` - 初始化项目