19 · Automations 自动化

Trigger: GitHub PR
Events: opened, synchronize (新提交), labeled, review_requested, merged, closed

Trigger: Slack Webhook
格式: /cursor trigger <automation-name> [参数]

Trigger: Linear Issue
Events: created, status_changed, assigned, commented

Trigger: PagerDuty Incident
Events: triggered, acknowledged, resolved

Trigger: Cron
Schedule: "0 10 * * 1-5" (工作日上午10点)

automations:
  # 自动化 1: PR Code Review
  - name: auto-review-pr
    description: 自动 Review 新提交的 PR
    trigger:
      type: github_pr
      events: [opened, synchronize]
    agent:
      model: claude-sonnet-4-20250514
      instructions: |
        你是一个代码审查者。当收到 PR 时：
        1. 阅读 PR 描述和 diff
        2. 检查：逻辑正确性、边界情况、安全漏洞、性能问题
        3. 对每处问题给出具体修改建议
        4. 使用 GitHub API 以 review 评论形式提交反馈
      tools: [read, edit, bash]
    review:
      require_approval: false  # review 评论不需要人工审批
 
  # 自动化 2: CI 自动修复
  - name: auto-fix-ci
    description: CI 失败时自动分析和修复
    trigger:
      type: github_pr
      events: [opened, synchronize]
      conditions:
        - check: 'check_run.conclusion == "failure"'
    agent:
      model: claude-sonnet-4-20250514
      instructions: |
        当 CI 检查失败时：
        1. 读取 CI 日志，找到失败原因
        2. 定位到相关的源码文件
        3. 尝试修复问题（修改代码或配置）
        4. 提交 fix commit 到 PR 分支
        5. 在 PR 上留言说明修复了什么
      tools: [read, edit, bash, gh]
    review:
      require_approval: true  # 修改代码需要人工审批
      timeout: 30m            # 30分钟内未审批则过期
 
  # 自动化 3: 每日报告
  - name: daily-report
    description: 每天生成项目报告并发送到 Slack
    trigger:
      type: cron
      schedule: "0 9 * * 1-5"  # 工作日早9点
    agent:
      model: claude-sonnet-4-20250514
      instructions: |
        每天早上生成一份项目状态报告：
        1. 检查 Git 最近的 commit 和分支状态
        2. 查看 CI 最新运行状态
        3. 查看待处理的 PR
        4. 汇总为简洁的 Markdown 报告
        5. 通过 Slack Webhook 发送到团队频道
      tools: [read, bash, gh]

automations:
  - name: pr-reviewer
    description: 自动审查所有新 PR
    trigger:
      type: github_pr
      events: [opened, synchronize]
      repos: ["my-org/my-repo"]  # 限定仓库
    agent:
      model: claude-sonnet-4-20250514
      instructions: |
        你是一个严格的代码审查者。
 
        ## 每次 PR Review 必须检查
        1. **逻辑正确性**：代码逻辑是否符合 PR 描述的目标？有无隐藏 bug？
        2. **边界情况**：空值、越界、并发、网络错误等是否处理？
        3. **安全性**：有无 SQL 注入、XSS、敏感信息泄露、权限绕过？
        4. **性能**：有无 N+1 查询、不必要的循环、内存泄漏？
        5. **代码风格**：是否遵循项目规范？
        6. **测试覆盖**：新代码是否有对应的测试？
 
        ## Review 格式
        每条评论包含：
        - 文件路径和行号
        - 问题的严重级别（🔴 必须修 / 🟡 建议修 / 💡 仅供参考）
        - 具体的问题描述
        - 建议的修改方案（代码片段）
 
        ## 操作
        使用 `gh pr review` 提交 review 评论。
        如果发现了🔴级别的问题，reject PR。
        如果只有🟡或💡级别问题，approve 但加上注释。
 
        ## 约束
        - 不要修改 PR 的代码——这个自动化只做 review，不改代码
        - 不要关闭 PR
        - review 评论要简洁专业，用中文
      tools: [read, bash, gh]

automations:
  - name: ci-fixer
    description: CI 失败自动分析和修复
    trigger:
      type: github_pr
      events: [synchronize]
      conditions:
        - check: |
            # 仅当至少一个 CI check 失败时触发
            any(check_run.conclusion == "failure" for check_run in payload.check_runs)
    agent:
      model: claude-sonnet-4-20250514
      instructions: |
        你是 CI 修复专家。
 
        ## 工作流程
        1. 读取失败的 CI 日志（使用 `gh run view --log`）
        2. 理解失败原因：
           - 是测试失败？读失败测试的代码
           - 是编译错误？看错误信息定位到文件
           - 是 lint/style 问题？看具体违规
           - 是环境/配置问题？检查配置文件变更
        3. 定位到源码问题所在
        4. 提出修复方案并在 PR 上留言（需审批模式）
        5. 如果 require_approval 为 true，等审批通过后再提交 commit
        6. 提交后确认 CI 重新运行并通过
 
        ## 规则
        - 每次只修一个问题，commit message 写清楚修了什么
        - 如果不能确定修复方案，在 PR 上详细说明分析和建议，不要盲目改代码
        - 对于 flaky test，建议加 retry 或标记，而不是修改测试逻辑
        - 修完一个后等待 CI 结果，如果还有失败的再继续修
      tools: [read, edit, bash, gh]
    review:
      require_approval: true
      timeout: 60m

automations:
  - name: daily-standup-report
    description: 每天早上生成项目报告
    trigger:
      type: cron
      schedule: "0 9 * * 1-5"  # 工作日9:00
    agent:
      model: claude-sonnet-4-20250514
      instructions: |
        生成一份简洁的每日项目报告。
 
        ## 报告内容
        ### 1. 昨日代码活动
        - 昨天 main 分支的 commit 统计（数量、主要作者）
        - 主要变更摘要（每个 commit 的一句话总结）
 
        ### 2. 活跃 PR
        - 待 Review 的 PR（列出 PR 号、标题、作者、创建时间）
        - 等待合并的 PR（已批准但未合并的）
        - PR 合并率趋势
 
        ### 3. CI 状态
        - 主分支 CI 是否通过
        - 最近失败的 CI run（如果有）及其原因
 
        ### 4. 健康检查
        - 依赖是否有安全漏洞（通过 `npm audit` 或等效工具）
        - 代码库中是否有大的技术债务指标变化
 
        ## 输出
        - 以整洁的 Markdown 格式输出
        - 通过 Slack Webhook 发送到 #engineering-standup 频道
        - 同时保存到项目 `.reports/` 目录
      tools: [read, bash, gh]

❌ 错误：给 Automation 所有仓库的完整权限
✅ 正确：只授权需要操作的仓库，用 repos 字段限定

❌ 错误：所有工具无条件开放
✅ 正确：tools 只列出必要工具，不要在不需要时给 gh

阶段 1: 只读分析（PR Review 评论）
阶段 2: 可写但需要审批（CI 修复）
阶段 3: 全自动（已充分验证的日常任务）

conditions:
  - check: 'pr.draft == false'            # 跳过 Draft PR
  - check: 'pr.changed_files < 500'        # 跳过超大 PR
  - check: 'check_run.conclusion != null'   # 等 CI 跑完