尧图网页设计 
用 Greptile Agent Skills 构建自动化 PR 审查工作流danswer 仓库实战指南【免费下载链接】danswerOpen Source AI Platform - AI Chat with advanced features that works with every LLM项目地址: https://gitcode.com/GitHub_Trending/da/danswer本指南以当前仓库中 vendored 的 Greptile Agent Skills 为核心讲解如何利用check-pr、cli-review、greploop三个技能实现跨平台GitHub / GitLab / Perforce的自动化代码审查闭环。读完本文你将掌握这些技能的安装与发现机制、三套平台 CLI 的认证前提、PR/MR/CL 的自动识别与状态轮询方法以及触发审查 → 修复评论 → 重新审查直到 5/5 满分的完整迭代流程并理解其在当前仓库.cursor/skills/greptile/中的实际落地方式。一、技能总览一套技能三种审查工作流Greptile Agent Skills 是面向 AI Agent如 Claude Code / Cursor 等支持 Agent Skills 的客户端设计的一套自动化 PR 审查技能集合。当前仓库将其完整 vendored 到 .cursor/skills/greptile/共包含三个子技能分别对应三种不同的审查场景技能描述适用场景check-pr检查 PR/MR/CL 中未解决的评论、失败的检查项、不完整的描述并负责修复与解决提交前的自检、回复评审意见、准备提交cli-review从当前本地 checkout 直接运行 Greptile CLI 审查并汇总发现尚未打开 PR 时在本地获取 AI 审查反馈greploop循环执行触发 Greptile 审查 → 修复评论 → 重新审查直到达到 5/5 置信度且零未解决评论希望把 PR/MR/CL 打磨到完美状态三个技能的分工非常清晰check-pr和greploop面向托管平台GitHub、GitLab、Perforce上已存在的 PR/MR/CL会从环境自动检测平台cli-review则完全不依赖托管平台直接针对当前本地 git checkout 运行 Greptile CLI适合在打开 PR 之前先行自查。三者配合即可覆盖本地预审 → 平台提交 → 循环打磨的完整链路。二、环境需求与认证准备三个技能均以命令行工具为执行底座不同平台需要不同的 CLI 工具。原文档给出了完整的需求对照表平台CLI 工具认证方式GitHubghGitHub CLIgh auth loginGitLabglabGitLab CLIglab auth loginPerforcep4Helix 命令行客户端配置P4PORT/P4USER/P4CLIENTGreptile本地审查greptileGreptile CLIgreptile login安装与认证是使用前提GitHub 场景需要git与ghGitLab 场景需要glabPerforce 场景需要p4本地审查场景需要 Greptile CLI。这些 CLI 的安装与登录流程由各官方渠道提供本文不再赘述外部下载地址。三、安装多技能仓库的正确打开方式Agent 客户端发现技能的方式是扫描技能目录下的SKILL.md文件典型路径为~/.claude/skills/skill-name/SKILL.md。由于 greptile 是一个包含多个技能的多技能仓库直接克隆后其目录层级greptile/check-pr/SKILL.md与客户端期望的层级check-pr/SKILL.md不一致因此需要借助符号链接把每个子技能提升到正确深度。原文档提供了两种安装方式。方式一直接克隆 符号链接git clone https://github.com/greptileai/skills.git ~/.claude/skills/greptile cd ~/.claude/skills ln -s greptile/check-pr check-pr ln -s greptile/cli-review cli-review ln -s greptile/greploop greploop方式二作为 git submodule 引入git submodule add https://github.com/greptileai/skills.git .skills/greptile ln -s greptile/check-pr .skills/check-pr ln -s greptile/cli-review .skills/cli-review ln -s greptile/greploop .skills/greploop这两种方式的共同关键点在于必须为每个子技能创建符号链接使其在技能发现目录中呈现为skill-name/SKILL.md的形态客户端才能逐个发现它们。当前仓库的实际落地方式在本仓库中这套技能并非手工克隆而是通过脚本维护的 vendored 依赖。查看 .cursor/skills/sync-vendored-skills.sh 可以发现其同步机制脚本通过UPSTREAMS数组记录 vendored 上游来源其中包含greptile条目指向 greptileai/skills 仓库的main分支每次运行会git fetch上游并比对目录树哈希发生变化时用git read-tree --prefix将上游内容整体导入.cursor/skills/dir导入完成后脚本自动为每个包含SKILL.md的子目录在.cursor/skills/下创建符号链接如check-pr、cli-review、greploop并清理已失效的链接。因此当前仓库中实际存在两类路径一类是 .cursor/skills/greptile/ 下完整的上游目录含LICENSE与README.md另一类是.cursor/skills/顶层的三个符号链接。这种vendored 目录 顶层 symlink的布局正是原文档安装步骤的工程化体现——将多技能仓库的正确暴露方式固化到了同步脚本中。四、用法按名调用智能识别安装完成后在 Agent 中按技能名直接调用即可/check-pr 123—— 检查 123 号 PRGitHub/ MRGitLab/ CLPerforce/cli-review—— 对当前本地 checkout 运行 Greptile 审查/greploop—— 对当前分支对应的 PR/MR/CL 启动迭代打磨循环若省略 PR/MR/CL 编号check-pr与greploop会自动检测当前分支对应的 PR/MR或 Perforce 环境下的待处理 changelist。对于主机名中不含 gitlab 的自托管 GitLab 实例需要显式传入--vcs gitlabPerforce 环境下自动检测失败时则显式传入--vcs perforce。五、check-pr 深度解析一次完整的 PR 体检check-pr/SKILL.md版本 1.3把一次 PR 检查拆解为可执行的分步流程以下是核心环节。5.1 平台检测技能首先判断当前工作环境属于哪个 VCS检测逻辑遵循先 Perforce、后 git remote的优先级# Check for Perforce environment if p4 info /dev/null 21; then VCSperforce else # Fall back to git remote detection REMOTE_URL$(git remote get-url origin) if echo $REMOTE_URL | grep -qi gitlab; then VCSgitlab else VCSgithub fi fi核心思路是p4 info成功说明处于 Perforce depot配合.p4config文件或P4CLIENT/P4PORT环境变量判断否则读取origin远程地址主机名包含 gitlab 判定为 GitLab其余默认 GitHub。检测失败或误判时由用户通过--vcs参数显式覆盖。5.2 识别 PR/MR/CL提供编号则直接使用否则自动检测。三平台命令各不相同GitHubgh pr view --json number -q .numberGitLabglab mr view --output json | jq .iidPerforcep4 changes -s pending -u $P4USER -c $P4CLIENT技能还特别强调了三平台字段的差异这是后续所有 API 调用的基础GitHub 用number/headRefName/headRefOidGitLab 用iid/source_branch/sha注意 GitLab 的 MR 编号是iid而非idPerforce 则是 changelist 编号CLreview 中的 CL 还需关注shelved文件。5.3 拉取详情与等待检查完成GitHubgh pr view PR_NUMBER --json title,body,state,reviews,comments,headRefName,statusCheckRollup行内评论走gh api repos/{owner}/{repo}/pulls/PR_NUMBER/comments。技能特别提示GitHub 的 PR 本质也是 issue普通评论存放在 issue comments 端点repos/{owner}/{repo}/issues/PR_NUMBER/comments且 Greptile 可能在每个审查周期原地编辑同一条总评评论因此判断 PR 是否干净时必须读取updated_at最新的那条 Greptile 评论含 Prompt to fix all with AI 部分而不能只看是否有新评论。GitLabglab mr view MR_IID --output json拉取详情行内 diff 评论通过 discussions 端点获取类型为DiffNote普通评论的type为null需要分页时追加?per_page100pageN。Perforcep4 describe -s CL_NUMBER查看描述、文件与状态p4 describe -S CL_NUMBER查看 shelved 文件p4 diff2 //...CL_NUMBER //...CL_NUMBER获取 shelved changelist 的 diffp4 review -c CL_NUMBER列出审查评论。随后进入等待阶段在开始分析前必须确保所有状态检查到达终态。GitHub 轮询statusCheckRollupGitLab 轮询 pipelines状态为running/pending/success/failed/canceled/skipped每 30 秒轮询一次直到无进行中任务Perforce 本身没有内建 CI 检查若团队通过 Swarm 等工具或外部 CI 触发审查则检查相应系统否则直接进入分析。5.4 分析、分类与报告从四个维度评估 PR状态检查CI 是否全绿、PR 描述是否完整、是否符合团队约定、是否存在 TODO 占位符、行内评论bot 评论如greptile-apps[bot]、人类评审意见、Perforce 的 review 评论、普通评论含 Greptile 被原地编辑的总评。所有问题按三类归档分类含义Actionable可处理需要改代码、补测试或修复Informational仅供参考验证性说明、提问或无需改动的知会Already addressed已解决已被后续提交修复的问题最终以表格形式汇报面积Area| 问题Issue| 状态Status| 需要的行动Action Needed并给出状态检查汇总、问题总数、可忽略项及理由、推荐下一步。5.5 修复与解决评论线程用户确认后执行修复GitHub/GitLab 上git add→git commit -m address review feedback→git pushPerforce 上p4 edit打开文件、修改后p4 shelve -f -c CL_NUMBER重新 shelve。随后解决对应评论线程GitHub通过 GraphQL 查询reviewThreads每页 100 条hasNextPage为真时用after: $cursor翻页收集isResolved为 false 的线程 ID再用resolveReviewThreadmutation 逐个解决批量解决时可用 GraphQL 别名t1、t2…合并为单次 mutation。具体查询见 check-pr/references/graphql-queries.md。GitLabglab api projects/:fullpath/merge_requests/MR_IID/discussions?per_page100拉取讨论过滤resolved: false的项然后对每个 discussion ID 执行glab api --method PUT .../discussions/DISCUSSION_ID --field resolvedtrue。注意 GitLab不支持批量解决必须逐个 PUT。Perforce没有原生解决线程概念通过在 CL 描述中更新说明、或在所用审查工具Swarm 等中回应来标记已处理若使用p4 review工作流则以p4 review -c CL_NUMBER标记文件已审查。此外技能还支持一次检查多个 CLp4 changes -s pending -u $P4USER -c $P4CLIENT -l可批量列出待处理 changelist多个 PR/MR/CL 按顺序逐个处理。六、cli-review 深度解析打开 PR 前的本地预审cli-review/SKILL.md版本 1.0提供了一条轻量的本地审查路径全程不依赖托管平台。其流程为确认仓库上下文git rev-parse --show-toplevel定位仓库根目录失败则提示用户 Greptile CLI 审查必须在 git 仓库内运行检查 CLI 是否安装command -v greptile缺失时不自动安装而是征得用户同意后展示推荐安装命令npm i -g greptile若 npm 不可用则回退到 shell 安装脚本方式安装完成后重新command -v greptile验证确保已认证greptile whoami检查登录态缺失则执行greptile login并等待用户完成登录流程运行审查优先greptile review --json获取结构化输出若 JSON 不受支持或报用法错误回退到greptile review --agent两条命令都失败时如实向用户报告失败的原始命令与下一步动作不隐藏错误汇总结果解析 JSON 输出报告审查状态、发现数量、按严重程度降序排列的最高危发现、需要修改的文件、建议的下一步命令或修复路径纯文本输出时保持相同结构。该技能的价值在于把 Greptile 的审查能力前置到本地 checkout阶段——在 PR 尚未打开、甚至分支尚未推送时就能先拿到一份 AI 审查清单。七、greploop 深度解析把 PR 打磨到 5/5 满分的循环引擎greploop/SKILL.md版本 1.3是三者中自动化程度最高、逻辑最复杂的技能。它的目标只有一个反复迭代直到 Greptile 给出 5/5 置信度且零未解决评论。7.1 循环骨架循环前的平台检测与 PR/MR/CL 识别逻辑与 check-pr 一致含--vcs覆盖参数。核心循环为A 触发审查 → B 拉取结果 → C 检查退出条件 → D 修复评论 → E 解决线程 → F 提交/重新 shelve并且设置了最多 5 次迭代的上限以避免失控循环。7.2 触发审查与轮询步骤 A推送或 shelve 最新改动后等待检查启动sleep 5然后分平台处理GitHub先用gh pr checks PR_NUMBER --json name,state检查 Greptile 是否已在运行仅在未运行时通过gh pr comment PR_NUMBER --body greptile review触发随后以 10 秒间隔、最多 60 次约 10 分钟轮询repos/{owner}/{repo}/commits/$HEAD_SHA/check-runs直到名为 greptile 的 check run 状态为completed。轮询超时必须终止流程并报告绝不基于过期或缺席的审查结果继续。GitLab通过glab api projects/:fullpath/merge_requests/MR_IID/pipelines判断是否已有running/pending流水线没有则以glab mr note MR_IID --message greptile review触发随后按 HEAD SHA 找到最新流水线再定位其中名称含 greptile 的 job轮询其status至success/failed/canceled终态。Perforce无原生 check run若 Greptile 通过 webhook 集成如触发于p4 shelve则等待其处理通过 webhook 端点或面板查看状态反复拉取 CL 上的 Greptile 审查评论直至出现评分。7.3 拉取审查结果步骤 BGreptile 的评分可能出现在多个位置技能要求全部检查。以 GitHub 为例需同时查看PR 描述 body、issue comments普通评论按updated_at取最新编辑版本注意解析 Prompt to fix all with AI 段、PR reviews找greptile-apps[bot]或greptile-apps-staging[bot]的最新条目。GitLab 对应 MR description、MR notes按author.username过滤 Greptile bot用户名因安装而异需首次确认、discussions仅取最新 commit 上resolved: false的DiffNote。Perforce 则查看 CL 描述中附加的评分块以及 Helix Swarm 等审查工具的评论 API如GET /api/v11/comments?topicreviews/REVIEW_ID。解析时提取两个关键指标置信度评分形如3/5、5/5或Confidence: 3/5与行内评论数量并始终采用更新时间最新的那份评分。7.4 退出条件与修复步骤 C、D、E满足以下任一条件即退出循环置信度达到5/5且未解决评论为零达到最大迭代次数此时如实报告当前状态。否则逐条处理 Greptile 评论读文件理解上下文 → 判断是可处理项还是参考项 → 可处理项直接修改 → 参考项或误报项记录说明后同样解决该线程。线程解决方式与 check-pr 相同GitHub 用 GraphQLresolveReviewThread支持别名批量GitLab 逐个 PUTresolvedtruePerforce 在审查工具中标记处理。7.5 提交与汇报步骤 F 与 Report每轮修复后git add -A→git commit -m address greptile review feedback (greploop iteration N)→git pushPerforce 为p4 shelve -f -c CL_NUMBER然后回到步骤 A 开始下一轮。循环结束后按固定模板汇报Greploop complete. Platform: GitHub Iterations: 2 Confidence: 5/5 Resolved: 7 comments Remaining: 0未达满分时则输出剩余问题清单例如Greploop stopped after 5 iterations. Platform: GitLab Confidence: 4/5 Resolved: 12 comments Remaining: 2 Remaining issues: - src/auth.ts:45 — Consider rate limiting this endpoint - src/db.ts:112 — Missing index on user_id column八、API 参考文档进阶定制的地图技能目录下附带两份 API 参考供需要深入定制或排障时查阅check-pr/references/graphql-queries.mdGitHub GraphQL 查询集包括分页拉取reviewThreads、单条resolveReviewThreadmutation、利用别名批量解决多条线程以及 REST 侧按updated_at取最新 Greptile 总评的完整jq管道示例check-pr/references/gitlab-api.mdGitLab REST 调用集覆盖 MR 详情字段对照iid、source_branch、sha、description、discussions 分页拉取、DiffNote过滤、单条讨论解决、pipeline 与 jobs 状态查询、MR notes 与评论发布。两份参考均强调一个共性事实GitHub 的评论可能被 Greptile 原地编辑更新GitLab 的 bot 用户名因安装而异因此判断是否干净永远要以最新状态为准。九、许可证本技能集以 MIT 许可证发布仓库内的 .cursor/skills/greptile/LICENSE 即为许可证副本可放心在各自项目中按 MIT 条款使用与定制。十、实践建议与适用边界综合三个技能的使用逻辑给出几条实操建议本地先cli-review平台再check-pr打磨用greploop三技能按预审 → 体检 → 打磨分层各司其职组合使用覆盖完整生命周期自托管 GitLab 记住--vcs gitlab主机名不含 gitlab 时自动检测会失败这是最常见的误判场景Perforce 环境同理轮询超时即停greploop约 10 分钟的轮询上限是防失控设计超时后应人工介入不要基于过期结果继续修复善用updated_at而非created_atGreptile 会原地更新总评读取最新编辑版本才能准确判断剩余问题当前仓库为只读参照本仓库中的技能位于 .cursor/skills/greptile/由 sync-vendored-skills.sh 维护适合作为了解技能结构、调用逻辑与 vendored 工程实践的样例实际使用时应按第三节的安装方式将其引入自己的技能目录或直接引用本仓库内以.cursor/skills/为根的可发现路径。需要注意的是这些技能依赖各平台 CLI 的可用性与网络可达性且 Greptile 的评分行为如 bot 用户名、评分写入位置可能因安装配置而异首次使用时应以实际输出为准进行适配。【免费下载链接】danswerOpen Source AI Platform - AI Chat with advanced features that works with every LLM项目地址: https://gitcode.com/GitHub_Trending/da/danswer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 用 Greptile Agent Skills 构建自动化 PR 审查工作流：danswer 仓库实战指南
用 Greptile Agent Skills 构建自动化 PR 审查工作流danswer 仓库实战指南【免费下载链接】danswerOpen Source AI Platform - AI Chat with advanced features that works with every LLM项目地址: https://gitcode.com/GitHub_Trending/da/danswer本指南以当前仓库中 vendored 的 Greptile Agent Skills 为核心讲解如何利用check-pr、cli-review、greploop三个技能实现跨平台GitHub / GitLab / Perforce的自动化代码审查闭环。读完本文你将掌握这些技能的安装与发现机制、三套平台 CLI 的认证前提、PR/MR/CL 的自动识别与状态轮询方法以及触发审查 → 修复评论 → 重新审查直到 5/5 满分的完整迭代流程并理解其在当前仓库.cursor/skills/greptile/中的实际落地方式。一、技能总览一套技能三种审查工作流Greptile Agent Skills 是面向 AI Agent如 Claude Code / Cursor 等支持 Agent Skills 的客户端设计的一套自动化 PR 审查技能集合。当前仓库将其完整 vendored 到 .cursor/skills/greptile/共包含三个子技能分别对应三种不同的审查场景技能描述适用场景check-pr检查 PR/MR/CL 中未解决的评论、失败的检查项、不完整的描述并负责修复与解决提交前的自检、回复评审意见、准备提交cli-review从当前本地 checkout 直接运行 Greptile CLI 审查并汇总发现尚未打开 PR 时在本地获取 AI 审查反馈greploop循环执行触发 Greptile 审查 → 修复评论 → 重新审查直到达到 5/5 置信度且零未解决评论希望把 PR/MR/CL 打磨到完美状态三个技能的分工非常清晰check-pr和greploop面向托管平台GitHub、GitLab、Perforce上已存在的 PR/MR/CL会从环境自动检测平台cli-review则完全不依赖托管平台直接针对当前本地 git checkout 运行 Greptile CLI适合在打开 PR 之前先行自查。三者配合即可覆盖本地预审 → 平台提交 → 循环打磨的完整链路。二、环境需求与认证准备三个技能均以命令行工具为执行底座不同平台需要不同的 CLI 工具。原文档给出了完整的需求对照表平台CLI 工具认证方式GitHubghGitHub CLIgh auth loginGitLabglabGitLab CLIglab auth loginPerforcep4Helix 命令行客户端配置P4PORT/P4USER/P4CLIENTGreptile本地审查greptileGreptile CLIgreptile login安装与认证是使用前提GitHub 场景需要git与ghGitLab 场景需要glabPerforce 场景需要p4本地审查场景需要 Greptile CLI。这些 CLI 的安装与登录流程由各官方渠道提供本文不再赘述外部下载地址。三、安装多技能仓库的正确打开方式Agent 客户端发现技能的方式是扫描技能目录下的SKILL.md文件典型路径为~/.claude/skills/skill-name/SKILL.md。由于 greptile 是一个包含多个技能的多技能仓库直接克隆后其目录层级greptile/check-pr/SKILL.md与客户端期望的层级check-pr/SKILL.md不一致因此需要借助符号链接把每个子技能提升到正确深度。原文档提供了两种安装方式。方式一直接克隆 符号链接git clone https://github.com/greptileai/skills.git ~/.claude/skills/greptile cd ~/.claude/skills ln -s greptile/check-pr check-pr ln -s greptile/cli-review cli-review ln -s greptile/greploop greploop方式二作为 git submodule 引入git submodule add https://github.com/greptileai/skills.git .skills/greptile ln -s greptile/check-pr .skills/check-pr ln -s greptile/cli-review .skills/cli-review ln -s greptile/greploop .skills/greploop这两种方式的共同关键点在于必须为每个子技能创建符号链接使其在技能发现目录中呈现为skill-name/SKILL.md的形态客户端才能逐个发现它们。当前仓库的实际落地方式在本仓库中这套技能并非手工克隆而是通过脚本维护的 vendored 依赖。查看 .cursor/skills/sync-vendored-skills.sh 可以发现其同步机制脚本通过UPSTREAMS数组记录 vendored 上游来源其中包含greptile条目指向 greptileai/skills 仓库的main分支每次运行会git fetch上游并比对目录树哈希发生变化时用git read-tree --prefix将上游内容整体导入.cursor/skills/dir导入完成后脚本自动为每个包含SKILL.md的子目录在.cursor/skills/下创建符号链接如check-pr、cli-review、greploop并清理已失效的链接。因此当前仓库中实际存在两类路径一类是 .cursor/skills/greptile/ 下完整的上游目录含LICENSE与README.md另一类是.cursor/skills/顶层的三个符号链接。这种vendored 目录 顶层 symlink的布局正是原文档安装步骤的工程化体现——将多技能仓库的正确暴露方式固化到了同步脚本中。四、用法按名调用智能识别安装完成后在 Agent 中按技能名直接调用即可/check-pr 123—— 检查 123 号 PRGitHub/ MRGitLab/ CLPerforce/cli-review—— 对当前本地 checkout 运行 Greptile 审查/greploop—— 对当前分支对应的 PR/MR/CL 启动迭代打磨循环若省略 PR/MR/CL 编号check-pr与greploop会自动检测当前分支对应的 PR/MR或 Perforce 环境下的待处理 changelist。对于主机名中不含 gitlab 的自托管 GitLab 实例需要显式传入--vcs gitlabPerforce 环境下自动检测失败时则显式传入--vcs perforce。五、check-pr 深度解析一次完整的 PR 体检check-pr/SKILL.md版本 1.3把一次 PR 检查拆解为可执行的分步流程以下是核心环节。5.1 平台检测技能首先判断当前工作环境属于哪个 VCS检测逻辑遵循先 Perforce、后 git remote的优先级# Check for Perforce environment if p4 info /dev/null 21; then VCSperforce else # Fall back to git remote detection REMOTE_URL$(git remote get-url origin) if echo $REMOTE_URL | grep -qi gitlab; then VCSgitlab else VCSgithub fi fi核心思路是p4 info成功说明处于 Perforce depot配合.p4config文件或P4CLIENT/P4PORT环境变量判断否则读取origin远程地址主机名包含 gitlab 判定为 GitLab其余默认 GitHub。检测失败或误判时由用户通过--vcs参数显式覆盖。5.2 识别 PR/MR/CL提供编号则直接使用否则自动检测。三平台命令各不相同GitHubgh pr view --json number -q .numberGitLabglab mr view --output json | jq .iidPerforcep4 changes -s pending -u $P4USER -c $P4CLIENT技能还特别强调了三平台字段的差异这是后续所有 API 调用的基础GitHub 用number/headRefName/headRefOidGitLab 用iid/source_branch/sha注意 GitLab 的 MR 编号是iid而非idPerforce 则是 changelist 编号CLreview 中的 CL 还需关注shelved文件。5.3 拉取详情与等待检查完成GitHubgh pr view PR_NUMBER --json title,body,state,reviews,comments,headRefName,statusCheckRollup行内评论走gh api repos/{owner}/{repo}/pulls/PR_NUMBER/comments。技能特别提示GitHub 的 PR 本质也是 issue普通评论存放在 issue comments 端点repos/{owner}/{repo}/issues/PR_NUMBER/comments且 Greptile 可能在每个审查周期原地编辑同一条总评评论因此判断 PR 是否干净时必须读取updated_at最新的那条 Greptile 评论含 Prompt to fix all with AI 部分而不能只看是否有新评论。GitLabglab mr view MR_IID --output json拉取详情行内 diff 评论通过 discussions 端点获取类型为DiffNote普通评论的type为null需要分页时追加?per_page100pageN。Perforcep4 describe -s CL_NUMBER查看描述、文件与状态p4 describe -S CL_NUMBER查看 shelved 文件p4 diff2 //...CL_NUMBER //...CL_NUMBER获取 shelved changelist 的 diffp4 review -c CL_NUMBER列出审查评论。随后进入等待阶段在开始分析前必须确保所有状态检查到达终态。GitHub 轮询statusCheckRollupGitLab 轮询 pipelines状态为running/pending/success/failed/canceled/skipped每 30 秒轮询一次直到无进行中任务Perforce 本身没有内建 CI 检查若团队通过 Swarm 等工具或外部 CI 触发审查则检查相应系统否则直接进入分析。5.4 分析、分类与报告从四个维度评估 PR状态检查CI 是否全绿、PR 描述是否完整、是否符合团队约定、是否存在 TODO 占位符、行内评论bot 评论如greptile-apps[bot]、人类评审意见、Perforce 的 review 评论、普通评论含 Greptile 被原地编辑的总评。所有问题按三类归档分类含义Actionable可处理需要改代码、补测试或修复Informational仅供参考验证性说明、提问或无需改动的知会Already addressed已解决已被后续提交修复的问题最终以表格形式汇报面积Area| 问题Issue| 状态Status| 需要的行动Action Needed并给出状态检查汇总、问题总数、可忽略项及理由、推荐下一步。5.5 修复与解决评论线程用户确认后执行修复GitHub/GitLab 上git add→git commit -m address review feedback→git pushPerforce 上p4 edit打开文件、修改后p4 shelve -f -c CL_NUMBER重新 shelve。随后解决对应评论线程GitHub通过 GraphQL 查询reviewThreads每页 100 条hasNextPage为真时用after: $cursor翻页收集isResolved为 false 的线程 ID再用resolveReviewThreadmutation 逐个解决批量解决时可用 GraphQL 别名t1、t2…合并为单次 mutation。具体查询见 check-pr/references/graphql-queries.md。GitLabglab api projects/:fullpath/merge_requests/MR_IID/discussions?per_page100拉取讨论过滤resolved: false的项然后对每个 discussion ID 执行glab api --method PUT .../discussions/DISCUSSION_ID --field resolvedtrue。注意 GitLab不支持批量解决必须逐个 PUT。Perforce没有原生解决线程概念通过在 CL 描述中更新说明、或在所用审查工具Swarm 等中回应来标记已处理若使用p4 review工作流则以p4 review -c CL_NUMBER标记文件已审查。此外技能还支持一次检查多个 CLp4 changes -s pending -u $P4USER -c $P4CLIENT -l可批量列出待处理 changelist多个 PR/MR/CL 按顺序逐个处理。六、cli-review 深度解析打开 PR 前的本地预审cli-review/SKILL.md版本 1.0提供了一条轻量的本地审查路径全程不依赖托管平台。其流程为确认仓库上下文git rev-parse --show-toplevel定位仓库根目录失败则提示用户 Greptile CLI 审查必须在 git 仓库内运行检查 CLI 是否安装command -v greptile缺失时不自动安装而是征得用户同意后展示推荐安装命令npm i -g greptile若 npm 不可用则回退到 shell 安装脚本方式安装完成后重新command -v greptile验证确保已认证greptile whoami检查登录态缺失则执行greptile login并等待用户完成登录流程运行审查优先greptile review --json获取结构化输出若 JSON 不受支持或报用法错误回退到greptile review --agent两条命令都失败时如实向用户报告失败的原始命令与下一步动作不隐藏错误汇总结果解析 JSON 输出报告审查状态、发现数量、按严重程度降序排列的最高危发现、需要修改的文件、建议的下一步命令或修复路径纯文本输出时保持相同结构。该技能的价值在于把 Greptile 的审查能力前置到本地 checkout阶段——在 PR 尚未打开、甚至分支尚未推送时就能先拿到一份 AI 审查清单。七、greploop 深度解析把 PR 打磨到 5/5 满分的循环引擎greploop/SKILL.md版本 1.3是三者中自动化程度最高、逻辑最复杂的技能。它的目标只有一个反复迭代直到 Greptile 给出 5/5 置信度且零未解决评论。7.1 循环骨架循环前的平台检测与 PR/MR/CL 识别逻辑与 check-pr 一致含--vcs覆盖参数。核心循环为A 触发审查 → B 拉取结果 → C 检查退出条件 → D 修复评论 → E 解决线程 → F 提交/重新 shelve并且设置了最多 5 次迭代的上限以避免失控循环。7.2 触发审查与轮询步骤 A推送或 shelve 最新改动后等待检查启动sleep 5然后分平台处理GitHub先用gh pr checks PR_NUMBER --json name,state检查 Greptile 是否已在运行仅在未运行时通过gh pr comment PR_NUMBER --body greptile review触发随后以 10 秒间隔、最多 60 次约 10 分钟轮询repos/{owner}/{repo}/commits/$HEAD_SHA/check-runs直到名为 greptile 的 check run 状态为completed。轮询超时必须终止流程并报告绝不基于过期或缺席的审查结果继续。GitLab通过glab api projects/:fullpath/merge_requests/MR_IID/pipelines判断是否已有running/pending流水线没有则以glab mr note MR_IID --message greptile review触发随后按 HEAD SHA 找到最新流水线再定位其中名称含 greptile 的 job轮询其status至success/failed/canceled终态。Perforce无原生 check run若 Greptile 通过 webhook 集成如触发于p4 shelve则等待其处理通过 webhook 端点或面板查看状态反复拉取 CL 上的 Greptile 审查评论直至出现评分。7.3 拉取审查结果步骤 BGreptile 的评分可能出现在多个位置技能要求全部检查。以 GitHub 为例需同时查看PR 描述 body、issue comments普通评论按updated_at取最新编辑版本注意解析 Prompt to fix all with AI 段、PR reviews找greptile-apps[bot]或greptile-apps-staging[bot]的最新条目。GitLab 对应 MR description、MR notes按author.username过滤 Greptile bot用户名因安装而异需首次确认、discussions仅取最新 commit 上resolved: false的DiffNote。Perforce 则查看 CL 描述中附加的评分块以及 Helix Swarm 等审查工具的评论 API如GET /api/v11/comments?topicreviews/REVIEW_ID。解析时提取两个关键指标置信度评分形如3/5、5/5或Confidence: 3/5与行内评论数量并始终采用更新时间最新的那份评分。7.4 退出条件与修复步骤 C、D、E满足以下任一条件即退出循环置信度达到5/5且未解决评论为零达到最大迭代次数此时如实报告当前状态。否则逐条处理 Greptile 评论读文件理解上下文 → 判断是可处理项还是参考项 → 可处理项直接修改 → 参考项或误报项记录说明后同样解决该线程。线程解决方式与 check-pr 相同GitHub 用 GraphQLresolveReviewThread支持别名批量GitLab 逐个 PUTresolvedtruePerforce 在审查工具中标记处理。7.5 提交与汇报步骤 F 与 Report每轮修复后git add -A→git commit -m address greptile review feedback (greploop iteration N)→git pushPerforce 为p4 shelve -f -c CL_NUMBER然后回到步骤 A 开始下一轮。循环结束后按固定模板汇报Greploop complete. Platform: GitHub Iterations: 2 Confidence: 5/5 Resolved: 7 comments Remaining: 0未达满分时则输出剩余问题清单例如Greploop stopped after 5 iterations. Platform: GitLab Confidence: 4/5 Resolved: 12 comments Remaining: 2 Remaining issues: - src/auth.ts:45 — Consider rate limiting this endpoint - src/db.ts:112 — Missing index on user_id column八、API 参考文档进阶定制的地图技能目录下附带两份 API 参考供需要深入定制或排障时查阅check-pr/references/graphql-queries.mdGitHub GraphQL 查询集包括分页拉取reviewThreads、单条resolveReviewThreadmutation、利用别名批量解决多条线程以及 REST 侧按updated_at取最新 Greptile 总评的完整jq管道示例check-pr/references/gitlab-api.mdGitLab REST 调用集覆盖 MR 详情字段对照iid、source_branch、sha、description、discussions 分页拉取、DiffNote过滤、单条讨论解决、pipeline 与 jobs 状态查询、MR notes 与评论发布。两份参考均强调一个共性事实GitHub 的评论可能被 Greptile 原地编辑更新GitLab 的 bot 用户名因安装而异因此判断是否干净永远要以最新状态为准。九、许可证本技能集以 MIT 许可证发布仓库内的 .cursor/skills/greptile/LICENSE 即为许可证副本可放心在各自项目中按 MIT 条款使用与定制。十、实践建议与适用边界综合三个技能的使用逻辑给出几条实操建议本地先cli-review平台再check-pr打磨用greploop三技能按预审 → 体检 → 打磨分层各司其职组合使用覆盖完整生命周期自托管 GitLab 记住--vcs gitlab主机名不含 gitlab 时自动检测会失败这是最常见的误判场景Perforce 环境同理轮询超时即停greploop约 10 分钟的轮询上限是防失控设计超时后应人工介入不要基于过期结果继续修复善用updated_at而非created_atGreptile 会原地更新总评读取最新编辑版本才能准确判断剩余问题当前仓库为只读参照本仓库中的技能位于 .cursor/skills/greptile/由 sync-vendored-skills.sh 维护适合作为了解技能结构、调用逻辑与 vendored 工程实践的样例实际使用时应按第三节的安装方式将其引入自己的技能目录或直接引用本仓库内以.cursor/skills/为根的可发现路径。需要注意的是这些技能依赖各平台 CLI 的可用性与网络可达性且 Greptile 的评分行为如 bot 用户名、评分写入位置可能因安装配置而异首次使用时应以实际输出为准进行适配。【免费下载链接】danswerOpen Source AI Platform - AI Chat with advanced features that works with every LLM项目地址: https://gitcode.com/GitHub_Trending/da/danswer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考