Claude Code Routines 完全指南：10 个开箱即用的 AI 自动化开发任务模板

# Routine 示例：每日代码简报
name: daily-code-digest
trigger:
  type: schedule
  cron: "0 9 * * 1-5"   # 工作日每天 9 点
task: |
  检查 main 分支过去 24 小时的 git log：
  1. 列出提交摘要（作者、改动范围）
  2. 标记出任何可能有风险的改动
  3. 统计测试文件的变更比例
  生成 Markdown 报告发到 Slack #dev-digest 频道

# Routine 示例：PR 自动初审
name: pr-auto-review
trigger:
  type: event
  event: pull_request.opened
  repo: your-org/your-repo
task: |
  对这个新 PR 做初步审查：
  1. 理解改动目的和范围
  2. 检查是否有明显的逻辑问题或潜在 bug
  3. 验证有无对应的单元测试
  4. 如果改动影响 API，检查是否更新了文档
  把审查意见作为 PR comment 发出，语气友好，标注「AI 初审，供参考」

name: weekly-security-scan
trigger:
  type: schedule
  cron: "0 3 * * 1"   # 每周一凌晨 3 点
task: |
  扫描 package.json（Node.js）和 requirements.txt（Python）中的依赖漏洞：
  - Critical/High：生成告警，列出漏洞名称、影响版本和修复方案
  - Medium/Low：汇总列表
  如果有 Critical 漏洞，立刻发邮件到 security@yourcompany.com
  无论如何都把完整报告保存到 reports/security-YYYY-MM-DD.md

name: tech-debt-tracker
trigger:
  type: schedule
  cron: "0 10 * * 5"   # 每周五上午 10 点
task: |
  扫描整个代码库：
  1. 统计 TODO/FIXME/HACK 注释数量，按文件和模块分类
  2. 找出超过 300 行的文件（可能需要拆分）
  3. 找出圈复杂度高的函数（嵌套超过 4 层）
  4. 与上周数据对比，技术债是增加还是减少？
  生成报告到 docs/tech-debt-report.md，并更新 README 里的技术债仪表盘数据

name: docs-sync-check
trigger:
  type: schedule
  cron: "0 14 * * 3"   # 每周三下午 2 点
task: |
  对比代码和文档：
  1. 检查 src/api/ 下的接口，是否都有对应的 API 文档
  2. 检查 README 里的安装步骤，实际执行一遍验证是否还正确
  3. 找出文档里引用了但代码里已经删除的函数或配置项
  把差异列表生成 Issue 到 GitHub，标签 documentation

name: nightly-refactor
trigger:
  type: schedule
  cron: "0 23 * * 5"   # 每周五晚 11 点
task: |
  对 src/legacy/ 目录做一次渐进式重构：
  - 遵循 .eslintrc 的规范
  - 每次只改一个文件，不做破坏性变更
  - 每个修改都要保证现有测试通过
  - 生成 PR，标题格式：「chore: refactor legacy/[filename] (automated)」
  如果发现某个文件的改动可能有风险，跳过并在 PR 描述里说明原因

name: issue-triage
trigger:
  type: schedule
  cron: "0 9 * * 1"   # 每周一早上 9 点
task: |
  处理过去一周新开的 GitHub Issues：
  1. 对每个没有标签的 issue，根据内容打上合适的标签（bug/feature/docs/question）
  2. 重复的 issue 标记为 duplicate 并关联到原 issue
  3. 信息不完整的 issue 评论要求补充（使用 Bug 报告模板）
  4. 生成 issue 周报：新增多少、关闭多少、高优先级有哪些
  发 Slack 到 #product 频道

name: coverage-monitor
trigger:
  type: event
  event: push
  branch: main
task: |
  每次 main 分支有新提交时：
  运行测试并生成覆盖率报告。
  如果覆盖率比上次提交下降超过 2%，
  在 commit 上发评论警告，并列出未覆盖的新增代码行

name: standup-prep
trigger:
  type: schedule
  cron: "30 8 * * 1-5"   # 工作日 8:30
task: |
  基于 git log（过去 24 小时）和 GitHub Issues 准备站会素材：
  1. 昨天完成了什么（从 commit message 总结）
  2. 今天计划做什么（从 open issues 和 PRs 推断）
  3. 有无阻塞项（stale PR、长时间未解决的 issue）
  生成 3-5 条简洁要点，发到我的 Telegram

name: api-change-detector
trigger:
  type: event
  event: pull_request.opened
  path_filter: "src/api/**"
task: |
  这个 PR 涉及 API 改动，检查：
  1. 有无 breaking change（删除字段、改变类型、改变语义）
  2. API 文档是否同步更新
  3. 是否需要版本号升级（semver）
  4. 现有的 API 测试是否覆盖了改动
  在 PR 上留下详细的 API 变更分析评论

name: perf-benchmark
trigger:
  type: schedule
  cron: "0 2 * * *"   # 每天凌晨 2 点
task: |
  运行性能基准测试套件（make benchmark）：
  1. 记录关键指标：API 响应时间、数据库查询时间、内存使用峰值
  2. 与昨天的数据对比，标记出降幅超过 10% 的指标
  3. 保存结果到 benchmarks/YYYY-MM-DD.json
  4. 如果有明显性能退化，创建 GitHub Issue 并 @cto

name: new-member-guide
trigger:
  type: event
  event: member_added   # 新成员加入仓库
task: |
  新成员加入了，自动发欢迎邮件并附上：
  1. 仓库结构说明（基于实际目录生成）
  2. 本地开发环境搭建步骤（验证过可执行的）
  3. 常用 make 命令一览
  4. 第一周推荐 review 的代码模块（适合入门的部分）
  5. 联系方式和沟通渠道