ccusage 仓库的 PR 全流程指南从 CodeRabbit / Cubic AI 审查到评论闭环处理【免费下载链接】ccusagenpx ccusage项目地址: https://gitcode.com/gh_mirrors/cc/ccusage导读ccusage 是一个以 Rust 为核心、通过 npm 发行的 Claude Code 用量统计工具npx ccusage其仓库维护了一套由 Agent 驱动的完整 PR 生命周期工作流其中AI 审查环节位于.agents/skills/create-pr/技能目录下每次打开 PR 后请求 CodeRabbitcoderabbitai与 Cubiccubic-dev-ai进行自动代码审查并在每次推送后持续跟进、轮询评论、分类并修复反馈直至所有 actionable 反馈清零。阅读本文你将掌握这套 AI 审查请求规范、ghCLI 的线程级回复方法、GraphQL 线程解决状态查询以及修复 → 提交 → 回复的闭环操作流程。一、AI 审查工作流概览ccusage 仓库的 PR 工作被收拢在 create-pr 技能 中该技能拥有本仓库的 PR 工作分支创建、打开 PR、AI 审查请求、审查线程回复、后续推送、CI 检查与合并。其完整的流程阶段为分支推送到main需要用户明确许可其余工作一律走以变更命名type/description的特性分支推送并打开 PR依据 open-pr.mdsquash 合并会把 PR 标题写成main上的提交主题因此 CI 会按与 commit 技能相同的 Conventional Commit scope 规则校验标题对应 .github/workflows/check-pr-title.yaml 与 scripts/validate-commit-scope.nu请求并处理 AI 审查即本文核心依据 ai-review.md 与 gh-review.md跟踪 CI每次打开 PR 及每次推送后用gh pr checks观察读取失败步骤的日志与 annotations 而非概要用fix-ci技能修复合并仅当用户明确要求且条件满足时执行gh pr merge pr --squash --delete-branch——squash 是本仓库的正常流程。AI 审查处于第三阶段是整个Ready means就绪判定中不可跳过的一环CodeRabbit——以及在其可用的 PR 上的 Cubic——必须审查过最新推送的提交且不存在未解决的 actionable 反馈。二、请求 AI 审查在何时、向谁、如何提及ai-review.md 定义了严格的请求规则1. 审查对象每个 PR 都请求CodeRabbitcoderabbitai在每一个PR 上都请求Cubiccubic-dev-aiGitHub 用户为cubic.dev当它在该仓库**可用usable**时请求。需要注意 handle 的动态性如果 PR 或近期仓库评论中显示了不同的 Cubic handle应使用评论中实际出现的那一个而不是机械照抄cubic-dev-ai。2. 提及时机mention 是触发条件打开 PR 之后添加一条顶层评论提及这些 bot在每一次有意义的推送meaningful push之后再次提及相关的 bot当 bot 没有自行重跑时重复请求。之所以如此强调提及是因为仓库技能上下文SKILL.md明确记录了一个关键机制审查 bot 只有在评论中提及它们的 handle 时才会行动——无论是初始请求还是每条要求它们做某事的回复。这决定了后续所有回复都必须以 bot 的提及开头。3. 就绪判定Ready means调用Ready之前必须满足分支已推送、PR 已存在且 PR 正文描述了变更与已运行的验证CodeRabbit——以及 Cubic当其可用时——审查过最新推送的提交且没有未解决的 actionable 反馈所有必需的检查通过——排队中、已取消、失败或缺失的必需检查都意味着未就绪用户已拿到 PR URL以及任何残余风险或待处理的外部状态。若 bot 或 CI 在合理的轮询窗口内保持沉默应如实说明当前处于等待状态而不是声称已完成并保留可见的 PR 评论或 CI 状态供后续跟进。三、轮询与分类从评论到线程解决状态在调用 PR Ready 之前需要轮询评论、review 与行内线程inline threads相关命令集中在 gh-review.md 中。1. 顶层轮询命令gh的 porcelaingh pr comment发布顶层评论gh pr view --json comments,reviews,statusCheckRollup一次性获取评论、review 与状态检查汇总gh pr checks查看检查状态。这些命令覆盖了请求审查 轮询的大部分场景下文两条是gh**没有现成子命令porcelain**的补充调用。2. 在线程内回复REST replies 端点gh pr comment只能发布顶层评论因此在 bot 打开的行内线程里回复必须使用 REST replies 端点并以该评论的 id 作为参数id 来自gh api repos/:owner/:repo/pulls/pr-number/commentsgh api -X POST repos/:owner/:repo/pulls/pr-number/comments/comment-id/replies \ -f bodycoderabbitai Fixed in commit-sha. Validation: just typecheck, just test.注意 body 的格式规范以 bot 的提及开头coderabbitai说明改动了什么Fixed in commit-sha并列出实际通过的验证Validation: ...与 commit 技能 中测试列出真正跑过的验证的约定一致。3. 线程解决状态GraphQL 专属行内线程的isResolved是否已解决状态只有 GraphQL 能查询。下面的查询返回前 100 个线程大 PR 需要自行补充pageInfo与after做分页gh api graphql \ -F ownerOWNER \ -F repoREPO \ -F numberpr-number \ -f query query($owner: String!, $repo: String!, $number: Int!) { repository(owner: $owner, name: $repo) { pullRequest(number: $number) { reviewThreads(first: 100) { nodes { id isResolved comments(first: 20) { nodes { id databaseId author { login } path body } } } } } } }该查询返回的isResolved字段与comments.nodes含databaseId、author.login、path、body正是判断每个反馈是否已闭环的依据只有所有 actionable 线程都已解决才能进入就绪判定。4. 反馈分类与处理策略对收集到的每一条反馈将其分类为四类之一actionable可行动需要修改代码question提问需要回答澄清false positive误报无需修改可在线程中说明理由informational信息性仅提供背景信息。对每一条actionable反馈执行最小修复闭环应用保持仓库约定的最小修复smallest fix运行相关检查relevant checks通过 commit 技能 提交并推送——该技能要求 commit 是原子且可独立回滚的 Conventional Commitreview 修复以小型 follow-up commit 形式叠加而不是 amend除非用户明确要求在该线程中回复以 bot 的提及开头说明改动了什么、哪些验证已通过。四、与仓库既有约定的衔接这套 AI 审查流程并非孤立存在它与仓库的多处约定相互咬合标题约束squash 合并会把 PR 标题直接写成main上的提交主题因此 .github/workflows/check-pr-title.yaml 校验 Conventional Commit 形状并调用 scripts/validate-commit-scope.nu 依据 PR diff 复核 scope——审查回复中提到的 commit 也必须遵守同一套规则提交纪律commit 技能 规定每次提交都要回答单独回滚它是否会破坏其他东西AI 审查修复常被拆成极小的提交一条评论、一处措辞修正、一次参考文件抽取赞助关系CodeRabbit 是 ccusage 的赞助商之一见 docs/guide/sponsors.md仓库中也能找到其品牌素材这与仓库默认在每个PR 上请求 CodeRabbit 的实践相互印证仓库通信语言AGENTS.md 规定面向仓库的 GitHub 通信——issue 评论、PR 描述、审查回复、triage 说明、面向 bot 的回复——一律使用美式英语因此上述所有评论与线程回复的 body 均以英文撰写CI 观察开 PR 与每次推送后用gh pr checks观察若 bot 未自行重跑则重复请求——这与 ai-review.md 的重复请求规则构成完整的跟进循环。五、典型闭环流程速查把以上内容串联成一次完整的 AI 审查闭环打开 PR └─ 顶层评论提及 coderabbitai及可用的 cubic-dev-ai └─ 每次 meaningful push 后再次提及 └─ gh pr view --json comments,reviews,statusCheckRollup / gh pr checks 轮询 └─ 对每条反馈分类actionable / question / false positive / informational └─ actionable 1. 应用最小修复并运行相关检查 2. commit 技能提交 推送squash 合并且不 amend 3. 用 REST replies 端点在原线程回复以 bot 提及开头 └─ 用 GraphQL 查询 reviewThreads 确认 isResolved └─ 全部 actionable 清零 必需检查通过 → 才可向用户报告 Ready核心要点可以浓缩为三条提及才触发bot 只在 handle 被 时行动、线程内闭环顶层评论用gh pr comment线程回复走 REST replies 端点、解决状态只认 GraphQLisResolved无 porcelain 命令可查。掌握这三条你就能在 ccusage 仓库乃至任何启用 CodeRabbit 的 GitHub 仓库上复现这套可审计、可跟踪的 AI 审查驱动 PR 流程。【免费下载链接】ccusagenpx ccusage项目地址: https://gitcode.com/gh_mirrors/cc/ccusage创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ccusage 仓库的 PR 全流程指南从 CodeRabbit / Cubic AI 审查到评论闭环处理【免费下载链接】ccusagenpx ccusage项目地址: https://gitcode.com/gh_mirrors/cc/ccusage导读ccusage 是一个以 Rust 为核心、通过 npm 发行的 Claude Code 用量统计工具npx ccusage其仓库维护了一套由 Agent 驱动的完整 PR 生命周期工作流其中AI 审查环节位于.agents/skills/create-pr/技能目录下每次打开 PR 后请求 CodeRabbitcoderabbitai与 Cubiccubic-dev-ai进行自动代码审查并在每次推送后持续跟进、轮询评论、分类并修复反馈直至所有 actionable 反馈清零。阅读本文你将掌握这套 AI 审查请求规范、ghCLI 的线程级回复方法、GraphQL 线程解决状态查询以及修复 → 提交 → 回复的闭环操作流程。一、AI 审查工作流概览ccusage 仓库的 PR 工作被收拢在 create-pr 技能 中该技能拥有本仓库的 PR 工作分支创建、打开 PR、AI 审查请求、审查线程回复、后续推送、CI 检查与合并。其完整的流程阶段为分支推送到main需要用户明确许可其余工作一律走以变更命名type/description的特性分支推送并打开 PR依据 open-pr.mdsquash 合并会把 PR 标题写成main上的提交主题因此 CI 会按与 commit 技能相同的 Conventional Commit scope 规则校验标题对应 .github/workflows/check-pr-title.yaml 与 scripts/validate-commit-scope.nu请求并处理 AI 审查即本文核心依据 ai-review.md 与 gh-review.md跟踪 CI每次打开 PR 及每次推送后用gh pr checks观察读取失败步骤的日志与 annotations 而非概要用fix-ci技能修复合并仅当用户明确要求且条件满足时执行gh pr merge pr --squash --delete-branch——squash 是本仓库的正常流程。AI 审查处于第三阶段是整个Ready means就绪判定中不可跳过的一环CodeRabbit——以及在其可用的 PR 上的 Cubic——必须审查过最新推送的提交且不存在未解决的 actionable 反馈。二、请求 AI 审查在何时、向谁、如何提及ai-review.md 定义了严格的请求规则1. 审查对象每个 PR 都请求CodeRabbitcoderabbitai在每一个PR 上都请求Cubiccubic-dev-aiGitHub 用户为cubic.dev当它在该仓库**可用usable**时请求。需要注意 handle 的动态性如果 PR 或近期仓库评论中显示了不同的 Cubic handle应使用评论中实际出现的那一个而不是机械照抄cubic-dev-ai。2. 提及时机mention 是触发条件打开 PR 之后添加一条顶层评论提及这些 bot在每一次有意义的推送meaningful push之后再次提及相关的 bot当 bot 没有自行重跑时重复请求。之所以如此强调提及是因为仓库技能上下文SKILL.md明确记录了一个关键机制审查 bot 只有在评论中提及它们的 handle 时才会行动——无论是初始请求还是每条要求它们做某事的回复。这决定了后续所有回复都必须以 bot 的提及开头。3. 就绪判定Ready means调用Ready之前必须满足分支已推送、PR 已存在且 PR 正文描述了变更与已运行的验证CodeRabbit——以及 Cubic当其可用时——审查过最新推送的提交且没有未解决的 actionable 反馈所有必需的检查通过——排队中、已取消、失败或缺失的必需检查都意味着未就绪用户已拿到 PR URL以及任何残余风险或待处理的外部状态。若 bot 或 CI 在合理的轮询窗口内保持沉默应如实说明当前处于等待状态而不是声称已完成并保留可见的 PR 评论或 CI 状态供后续跟进。三、轮询与分类从评论到线程解决状态在调用 PR Ready 之前需要轮询评论、review 与行内线程inline threads相关命令集中在 gh-review.md 中。1. 顶层轮询命令gh的 porcelaingh pr comment发布顶层评论gh pr view --json comments,reviews,statusCheckRollup一次性获取评论、review 与状态检查汇总gh pr checks查看检查状态。这些命令覆盖了请求审查 轮询的大部分场景下文两条是gh**没有现成子命令porcelain**的补充调用。2. 在线程内回复REST replies 端点gh pr comment只能发布顶层评论因此在 bot 打开的行内线程里回复必须使用 REST replies 端点并以该评论的 id 作为参数id 来自gh api repos/:owner/:repo/pulls/pr-number/commentsgh api -X POST repos/:owner/:repo/pulls/pr-number/comments/comment-id/replies \ -f bodycoderabbitai Fixed in commit-sha. Validation: just typecheck, just test.注意 body 的格式规范以 bot 的提及开头coderabbitai说明改动了什么Fixed in commit-sha并列出实际通过的验证Validation: ...与 commit 技能 中测试列出真正跑过的验证的约定一致。3. 线程解决状态GraphQL 专属行内线程的isResolved是否已解决状态只有 GraphQL 能查询。下面的查询返回前 100 个线程大 PR 需要自行补充pageInfo与after做分页gh api graphql \ -F ownerOWNER \ -F repoREPO \ -F numberpr-number \ -f query query($owner: String!, $repo: String!, $number: Int!) { repository(owner: $owner, name: $repo) { pullRequest(number: $number) { reviewThreads(first: 100) { nodes { id isResolved comments(first: 20) { nodes { id databaseId author { login } path body } } } } } } }该查询返回的isResolved字段与comments.nodes含databaseId、author.login、path、body正是判断每个反馈是否已闭环的依据只有所有 actionable 线程都已解决才能进入就绪判定。4. 反馈分类与处理策略对收集到的每一条反馈将其分类为四类之一actionable可行动需要修改代码question提问需要回答澄清false positive误报无需修改可在线程中说明理由informational信息性仅提供背景信息。对每一条actionable反馈执行最小修复闭环应用保持仓库约定的最小修复smallest fix运行相关检查relevant checks通过 commit 技能 提交并推送——该技能要求 commit 是原子且可独立回滚的 Conventional Commitreview 修复以小型 follow-up commit 形式叠加而不是 amend除非用户明确要求在该线程中回复以 bot 的提及开头说明改动了什么、哪些验证已通过。四、与仓库既有约定的衔接这套 AI 审查流程并非孤立存在它与仓库的多处约定相互咬合标题约束squash 合并会把 PR 标题直接写成main上的提交主题因此 .github/workflows/check-pr-title.yaml 校验 Conventional Commit 形状并调用 scripts/validate-commit-scope.nu 依据 PR diff 复核 scope——审查回复中提到的 commit 也必须遵守同一套规则提交纪律commit 技能 规定每次提交都要回答单独回滚它是否会破坏其他东西AI 审查修复常被拆成极小的提交一条评论、一处措辞修正、一次参考文件抽取赞助关系CodeRabbit 是 ccusage 的赞助商之一见 docs/guide/sponsors.md仓库中也能找到其品牌素材这与仓库默认在每个PR 上请求 CodeRabbit 的实践相互印证仓库通信语言AGENTS.md 规定面向仓库的 GitHub 通信——issue 评论、PR 描述、审查回复、triage 说明、面向 bot 的回复——一律使用美式英语因此上述所有评论与线程回复的 body 均以英文撰写CI 观察开 PR 与每次推送后用gh pr checks观察若 bot 未自行重跑则重复请求——这与 ai-review.md 的重复请求规则构成完整的跟进循环。五、典型闭环流程速查把以上内容串联成一次完整的 AI 审查闭环打开 PR └─ 顶层评论提及 coderabbitai及可用的 cubic-dev-ai └─ 每次 meaningful push 后再次提及 └─ gh pr view --json comments,reviews,statusCheckRollup / gh pr checks 轮询 └─ 对每条反馈分类actionable / question / false positive / informational └─ actionable 1. 应用最小修复并运行相关检查 2. commit 技能提交 推送squash 合并且不 amend 3. 用 REST replies 端点在原线程回复以 bot 提及开头 └─ 用 GraphQL 查询 reviewThreads 确认 isResolved └─ 全部 actionable 清零 必需检查通过 → 才可向用户报告 Ready核心要点可以浓缩为三条提及才触发bot 只在 handle 被 时行动、线程内闭环顶层评论用gh pr comment线程回复走 REST replies 端点、解决状态只认 GraphQLisResolved无 porcelain 命令可查。掌握这三条你就能在 ccusage 仓库乃至任何启用 CodeRabbit 的 GitHub 仓库上复现这套可审计、可跟踪的 AI 审查驱动 PR 流程。【免费下载链接】ccusagenpx ccusage项目地址: https://gitcode.com/gh_mirrors/cc/ccusage创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
