taskmanager/.claude/commands/gitea/start-scheduler.md

name	description
gitea-start-scheduler	启动定时任务（Issue 处理和 PR 审核）

创建两个定时任务，自动处理 Issues 和审核 PRs。

工作流程

第一步：读取配置

从环境变量读取配置：

• GITEA_URL: Gitea 实例地址
• GITEA_TOKEN: API 访问令牌
• GITEA_OWNER: 仓库所有者
• GITEA_REPO: 仓库名称（如果没有，则使用当前目录名）
• CODE_AGENT_INTERVAL: Code Agent 间隔（默认 5 分钟）
• PR_AGENT_INTERVAL: PR Agent 间隔（默认 10 分钟）

第二步：创建 Code Agent 定时任务

使用 CronCreate 创建定时任务，定期扫描和处理未完成的 Issues。

定时任务逻辑：

每 N 分钟执行一次：
1. 依据 .claude/commands/gitea/API-QUICK-REFERENCE.md 文档中的 Issue 操作指南获取所有打开的 Issues
2. 过滤出未处理的（没有 PR 关联）
3. 按优先级排序
4. 依据 API-QUICK-REFERENCE.md 文档检查依赖是否满足
5. 选择优先级最高的未阻塞 Issue
6. 启动 Agent 处理该 Issue

Agent 工作流程：

1. 依据 .claude/commands/gitea/API-QUICK-REFERENCE.md 文档中的 Issue 操作指南获取 Issue 详情
2. 解析 Issue 描述，提取需求
3. 依据 API-QUICK-REFERENCE.md 文档检查依赖 Issue 是否已完成
4. 如果依赖未满足，跳过该 Issue
5. 创建特性分支: feature/issue-{number}
6. 分析需要实现的功能
7. 读取现有代码结构
8. 增量式生成实现代码
   - 只实现 Issue 要求的功能
   - 不重复已有代码
   - 遵循项目代码规范
9. 生成测试代码
   - 单元测试
   - 集成测试（如果需要）
10. 运行测试
    - 如果测试失败，修复代码并重试
11. 提交代码
    git add .
    git commit -m "feat: 实现 Issue #{number}"
    git push origin feature/issue-{number}
12. 依据 API-QUICK-REFERENCE.md 文档中的 Pull Request 操作指南创建 Pull Request
    - 标题: [Issue #{number}] {Issue 标题}
    - 描述: 关联 Issue，说明实现内容
    - 标签: 继承 Issue 的标签
13. 依据 API-QUICK-REFERENCE.md 文档中的 Issue 评论操作指南在 Issue 中添加评论，说明已创建 PR

第三步：创建 PR Agent 定时任务

使用 CronCreate 创建定时任务，定期审核未审核的 PRs。

定时任务逻辑：

每 N 分钟执行一次：
1. 依据 .claude/commands/gitea/API-QUICK-REFERENCE.md 文档中的 Pull Request 操作指南获取所有打开的 Pull Requests
2. 过滤出未审核的
3. 对每个 PR 启动 Agent 审核

Agent 审核流程：

1. 依据 .claude/commands/gitea/API-QUICK-REFERENCE.md 文档中的 Pull Request 操作指南获取 PR 详情
   - 代码变更
   - 关联的 Issue
   - 提交历史

2. 代码质量检查
   - 代码规范（如果有 linter）
   - 代码风格一致性
   - 潜在的 bug

3. 测试检查
   - 检查是否有测试代码
   - 运行测试（如果有测试框架）
   - 验证测试覆盖率

4. 安全检查
   - 检查是否有敏感信息泄露
   - 检查是否有安全漏洞

5. 依据 API-QUICK-REFERENCE.md 文档中的 PR 审核操作指南创建审核评论
   如果发现问题：
   - 列出所有问题
   - 提供修复建议
   - 请求修改（REQUEST_CHANGES）

   如果审核通过：
   - 批准（APPROVE）
   - 根据 AUTO_MERGE 配置决定是否自动合并

6. 如果需要修改
   - 启动修复 Agent
   - 修复问题
   - 推送修复

第四步：显示任务状态

创建完成后，显示：

• 两个定时任务的 ID
• 下次执行时间
• 如何停止任务（/gitea-stop-scheduler）

配置选项

环境变量

创建 .env 文件（如果不存在）：

# Gitea 配置
GITEA_URL=http://your-gitea-url
GITEA_TOKEN=your-api-token
GITEA_OWNER=your-username
GITEA_REPO=your-repo-name  # 可选，默认使用当前目录名

# 定时间隔（分钟）
CODE_AGENT_INTERVAL=5      # 默认 5 分钟
PR_AGENT_INTERVAL=10       # 默认 10 分钟

# 审核配置
AUTO_MERGE=false           # 是否自动合并审核通过的 PR
REQUIRE_REVIEW=true        # 是否需要代码审查
TEST_COVERAGE_TARGET=80    # 测试覆盖率目标

定时间隔建议

根据项目规模调整间隔：

• 小型项目 (< 10 个 Issues):

  • Code Agent: 3-5 分钟
  • PR Agent: 5-10 分钟

• 中型项目 (10-50 个 Issues):

  • Code Agent: 5-10 分钟
  • PR Agent: 10-15 分钟

• 大型项目 (> 50 个 Issues):

  • Code Agent: 10-15 分钟
  • PR Agent: 15-20 分钟

示例输出

🚀 启动定时任务
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

✅ 读取配置
  • 仓库: chen/task-manager-unity
  • Code Agent 间隔: 5 分钟
  • PR Agent 间隔: 10 分钟

✅ 创建 Code Agent 定时任务
  • ID: job-abc123
  • 间隔: */5 * * * *
  • 下次执行: 2 分钟后

✅ 创建 PR Agent 定时任务
  • ID: job-def456
  • 间隔: */10 * * * *
  • 下次执行: 7 分钟后

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

⏰ 定时任务已启动！

Agent 将自动：
  • 扫描未处理的 Issues 并实现功能
  • 审核提交的 Pull Requests
  • 运行测试并确保代码质量

💡 提示：
  • 使用 /gitea-status 查看进度
  • 使用 /gitea-stop-scheduler 停止任务
  • 定时任务仅在当前会话有效（最多 3 天）

✨ 准备就绪，Agent 开始工作！

注意事项

1. 会话限制: 定时任务仅在当前会话有效，会话结束后需要重新启动
2. 自动过期: 定时任务最多运行 3 天，之后会自动删除
3. 并发控制: 同一时间只处理一个 Issue，避免冲突
4. 依赖检查: 会自动跳过依赖未满足的 Issues
5. 错误重试: 如果 Agent 执行失败，会在下次定时任务时重试
6. 手动干预: 可以随时使用 /gitea-process-issue 手动处理特定 Issue

工作流示例

时间轴：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

T=0 min   启动定时任务
T=2 min   Code Agent 扫描 → 发现 Issue #2
          开始实现 Issue #2...

T=5 min   Code Agent 完成 Issue #2，创建 PR #1
          下次扫描...

T=10 min  PR Agent 审核通过 PR #1
          AUTO_MERGE=false → 等待人工合并

T=15 min  Code Agent 扫描 → 发现 Issue #3
          开始实现 Issue #3...

...以此类推

下一步

启动定时任务后：

1. 使用 /gitea-status 查看实时状态
2. 查看 Issues 和 PRs 的进度
3. 手动审核和合并 PRs（如果 AUTO_MERGE=false）
4. 根据需要调整定时间隔