核心用法
该技能是一个自治GitHub Issue修复代理，完整覆盖从问题发现到PR提交的工作流。用户只需提供仓库地址（owner/repo），系统将自动执行：
Phase 1 - 问题发现：通过 recommend.py 智能获取、评分并推荐开放Issue，基于严重性/影响力/工作量/新鲜度四维排序，严禁手动格式化输出。
Phase 2 - 修复实施：锁定Issue → 克隆仓库 → 创建安全分支 → 代码探查 → 提交修复方案（需用户明确批准）→ 执行修改。所有文件访问和命令执行均需通过护栏验证。
Phase 3 - 测试验证：自动检测并运行测试套件，支持失败自动回滚（若 autoRollbackOnTestFail 启用），无测试时自动补写基础测试。
Phase 4 - PR提交：始终以Draft模式创建PR，禁止在聊天中dump完整diff，强制推送到GitHub供用户Review。
显著优点
- 5层安全护栏体系：作用域验证（repo/branch/path）、动作门控（auto/notify/approve三级）、命令白名单、审计日志，形成纵深防御
- 强制单Issue串行：
issue_lock机制杜绝并发修改冲突 - 关键危险操作双保险：写代码、commit、push、PR创建均需用户显式批准
- 保护分支与敏感文件黑名单：main/master/production、.env、CI配置、依赖文件等均不可触碰
- 审计可追溯：所有操作强制记录至
audit/目录
潜在局限
- 交互频繁：每个关键节点需用户确认，可能降低批量处理效率
- 工具链依赖：高度依赖特定脚本生态（guardrails.py, sandbox.py等），迁移成本较高
- 测试覆盖依赖：自动回滚策略依赖
autoRollbackOnTestFail配置，若未启用可能导致问题代码残留 - PR创建限制：强制Draft模式可能不符合部分团队的快速迭代流程
适合人群
- 开源维护者需批量处理积压Issue
- 企业团队需标准化代码贡献流程并强制安全合规
- 新手开发者希望在有护栏保护下学习Issue修复流程
常规风险
| 风险类型 | 等级 | 说明 |
|---------|------|------|
| 权限越界 | 中 | 护栏理论上阻断，但 `sandbox.py` 执行git命令存在潜在逃逸面 |
| 代码质量 | 低 | 依赖用户Review，Draft PR机制提供缓冲 |
| 审计日志篡改 | 低 | 需确认 `audit.py` 日志是否防篡改（如append-only） |
| 依赖注入 | 中 | 禁止无批准修改依赖文件，但 `recommend.py` 解析Issue内容可能引入恶意输入 |
> 注意：提供的安全认证报告为系统占位符，未执行实际扫描，T1/S+评级需以真实安全审计为准。