企业官网建设流程全解析

用 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和greploop面向托管平台（GitHub、GitLab、Perforce）上已存在的 PR/MR/CL，会从环境自动检测平台；cli-review则完全不依赖托管平台，直接针对当前本地 git checkout 运行 Greptile CLI，适合在打开 PR 之前先行自查。三者配合，即可覆盖"本地预审 → 平台提交 → 循环打磨"的完整链路。

二、环境需求与认证准备

三个技能均以命令行工具为执行底座，不同平台需要不同的 CLI 工具。原文档给出了完整的需求对照表：

安装与认证是使用前提：GitHub 场景需要git与gh，GitLab 场景需要glab，Perforce 场景需要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 号 PR（GitHub）/ MR（GitLab）/ CL（Perforce）
• /cli-review—— 对当前本地 checkout 运行 Greptile 审查
• /greploop—— 对当前分支对应的 PR/MR/CL 启动迭代打磨循环

若省略 PR/MR/CL 编号，check-pr与greploop会自动检测当前分支对应的 PR/MR，或 Perforce 环境下的待处理 changelist。对于主机名中不含 "gitlab" 的自托管 GitLab 实例，需要显式传入--vcs gitlab；Perforce 环境下自动检测失败时，则显式传入--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 2>&1; then VCS="perforce" else # Fall back to git remote detection REMOTE_URL=$(git remote get-url origin) if echo "$REMOTE_URL" | grep -qi "gitlab"; then VCS="gitlab" else VCS="github" fi fi

核心思路是：p4 info成功说明处于 Perforce depot（配合.p4config文件或P4CLIENT/P4PORT环境变量判断）；否则读取origin远程地址，主机名包含 "gitlab" 判定为 GitLab，其余默认 GitHub。检测失败或误判时由用户通过--vcs参数显式覆盖。

5.2 识别 PR/MR/CL

提供编号则直接使用，否则自动检测。三平台命令各不相同：

• GitHub：gh pr view --json number -q .number
• GitLab：glab mr view --output json | jq '.iid'
• Perforce：p4 changes -s pending -u $P4USER -c $P4CLIENT

技能还特别强调了三平台字段的差异，这是后续所有 API 调用的基础：GitHub 用number/headRefName/headRefOid；GitLab 用iid/source_branch/sha（注意 GitLab 的 MR 编号是iid而非id）；Perforce 则是 changelist 编号（CL），review 中的 CL 还需关注shelved文件。

5.3 拉取详情与等待检查完成

• GitHub：gh 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" 部分），而不能只看是否有新评论。
• GitLab：glab mr view <MR_IID> --output json拉取详情，行内 diff 评论通过 discussions 端点获取（类型为DiffNote，普通评论的type为null），需要分页时追加?per_page=100&page=N。
• Perforce：p4 describe -s <CL_NUMBER>查看描述、文件与状态，p4 describe -S <CL_NUMBER>查看 shelved 文件，p4 diff2 //...@=<CL_NUMBER> //...@=<CL_NUMBER>获取 shelved changelist 的 diff，p4 review -c <CL_NUMBER>列出审查评论。

随后进入等待阶段：在开始分析前必须确保所有状态检查到达终态。GitHub 轮询statusCheckRollup；GitLab 轮询 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 被原地编辑的总评）。所有问题按三类归档：

最终以表格形式汇报：面积（Area）| 问题（Issue）| 状态（Status）| 需要的行动（Action Needed），并给出状态检查汇总、问题总数、可忽略项及理由、推荐下一步。

5.5 修复与解决评论线程

用户确认后执行修复：GitHub/GitLab 上git add→git commit -m "address review feedback"→git push；Perforce 上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。
• GitLab：glab api "projects/:fullpath/merge_requests/<MR_IID>/discussions?per_page=100"拉取讨论，过滤"resolved": false的项，然后对每个 discussion ID 执行glab api --method PUT ".../discussions/<DISCUSSION_ID>" --field resolved=true。注意 GitLab不支持批量解决，必须逐个 PUT。
• Perforce：没有原生"解决线程"概念，通过在 CL 描述中更新说明、或在所用审查工具（Swarm 等）中回应来标记已处理；若使用p4 review工作流，则以p4 review -c <CL_NUMBER>标记文件已审查。

此外技能还支持一次检查多个 CL：p4 changes -s pending -u $P4USER -c $P4CLIENT -l可批量列出待处理 changelist，多个 PR/MR/CL 按顺序逐个处理。

六、cli-review 深度解析：打开 PR 前的本地预审

cli-review/SKILL.md（版本 1.0）提供了一条轻量的本地审查路径，全程不依赖托管平台。其流程为：

1. 确认仓库上下文：git rev-parse --show-toplevel定位仓库根目录，失败则提示用户 Greptile CLI 审查必须在 git 仓库内运行；
2. 检查 CLI 是否安装：command -v greptile；缺失时不自动安装，而是征得用户同意后展示推荐安装命令npm i -g greptile，若 npm 不可用则回退到 shell 安装脚本方式；安装完成后重新command -v greptile验证；
3. 确保已认证：greptile whoami检查登录态，缺失则执行greptile login并等待用户完成登录流程；
4. 运行审查：优先greptile review --json获取结构化输出；若 JSON 不受支持或报用法错误，回退到greptile review --agent；两条命令都失败时，如实向用户报告失败的原始命令与下一步动作，不隐藏错误；
5. 汇总结果：解析 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 拉取审查结果（步骤 B）

Greptile 的评分可能出现在多个位置，技能要求全部检查。以 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?topic=reviews/<REVIEW_ID>）。

解析时提取两个关键指标：置信度评分（形如3/5、5/5或Confidence: 3/5）与行内评论数量，并始终采用更新时间最新的那份评分。

7.4 退出条件与修复（步骤 C、D、E）

满足以下任一条件即退出循环：

• 置信度达到5/5且未解决评论为零；
• 达到最大迭代次数（此时如实报告当前状态）。

否则逐条处理 Greptile 评论：读文件理解上下文 → 判断是可处理项还是参考项 → 可处理项直接修改 → 参考项或误报项记录说明后同样解决该线程。线程解决方式与 check-pr 相同（GitHub 用 GraphQLresolveReviewThread支持别名批量；GitLab 逐个 PUTresolved=true；Perforce 在审查工具中标记处理）。

7.5 提交与汇报（步骤 F 与 Report）

每轮修复后git add -A→git commit -m "address greptile review feedback (greploop iteration N)"→git push（Perforce 为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.md：GitHub GraphQL 查询集，包括分页拉取reviewThreads、单条resolveReviewThreadmutation、利用别名批量解决多条线程，以及 REST 侧"按updated_at取最新 Greptile 总评"的完整jq管道示例；
• check-pr/references/gitlab-api.md：GitLab REST 调用集，覆盖 MR 详情字段对照（iid、source_branch、sha、description）、discussions 分页拉取、DiffNote过滤、单条讨论解决、pipeline 与 jobs 状态查询、MR notes 与评论发布。

两份参考均强调一个共性事实：GitHub 的评论可能被 Greptile 原地编辑更新，GitLab 的 bot 用户名因安装而异，因此判断"是否干净"永远要以最新状态为准。

九、许可证

本技能集以 MIT 许可证发布，仓库内的 .cursor/skills/greptile/LICENSE 即为许可证副本，可放心在各自项目中按 MIT 条款使用与定制。

十、实践建议与适用边界

综合三个技能的使用逻辑，给出几条实操建议：

1. 本地先cli-review，平台再check-pr，打磨用greploop：三技能按"预审 → 体检 → 打磨"分层，各司其职，组合使用覆盖完整生命周期；
2. 自托管 GitLab 记住--vcs gitlab：主机名不含 "gitlab" 时自动检测会失败，这是最常见的误判场景；Perforce 环境同理；
3. 轮询超时即停：greploop约 10 分钟的轮询上限是防失控设计，超时后应人工介入，不要基于过期结果继续修复；
4. 善用updated_at而非created_at：Greptile 会原地更新总评，读取最新编辑版本才能准确判断剩余问题；
5. 当前仓库为只读参照：本仓库中的技能位于 .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