review-pr-clickup

带 ClickUp 上下文的 Pull Request 评审

目的

获取指定 GitHub Pull Request 的差异内容，根据相关的 .github/instructions 文件和 ClickUp 任务要求进行分析，并使用 GitHub CLI（gh）直接在 PR 上发布结构化评审评论。

第 1 步：解析上下文 — 始终先运行捆绑脚本

旧工作流中的第 1、2、3 和 3.5 步（解析 REPO/PR、计算隔离的 WORKDIR、检查工作树是否干净、通过 gh 获取 PR 差异/元数据/评论，以及检测并获取 ClickUp 任务）完全是机械操作——不需要任何判断，因此我们将这些步骤一次性实现为捆绑脚本，而不是用文字描述供你手动复现。自行复现这些逻辑（重新计算 WORKDIR、单独重新运行各个 gh 调用），正是导致运行过程中路径偏差和混乱的原因——始终交由脚本处理。

每次都将此作为你的第一项操作，无论运行模式如何：

bash "$(dirname "$0")/../scripts/prefetch.sh" --repo "$REPO" --pr "$PR"

实际使用时，相对于安装此 SKILL.md 的位置解析 scripts/prefetch.sh 的路径（例如 ~/.claude/skills/review-pr-clickup/scripts/prefetch.sh），并传入 --repo owner/repo --pr NUMBER。如果调用方（例如 CI 流水线）在调用你之前已经运行过这个完全相同的脚本，并告知了你，则无需再次运行；但如果你有任何不确定，就直接运行：它是幂等的（已获取的文件会被复用，而不会重新获取），可以根据需要安全地多次调用；即使除了 --print-workdir-only 之外不带任何参数也可以，这样在只需快速恢复 WORKDIR、无需访问网络时就能使用。

脚本会打印（并持久化到 $WORKDIR/context.env）如下形式的最终信息块：

MODE=CI|INTERACTIVE
REPO=owner/repo
PR=123
WORKDIR=/tmp/pr_review/owner_repo/123
SHA=<head-commit-sha>
TICKET_ID=CU-xxxxxxxx (or empty)
CLICKUP_STATUS=fetched|skipped|error|no_ticket
REPO_ROOT=/absolute/path/to/checked-out/repo

将这些值视为权威信息——绝不要手动重新计算 WORKDIR，不要根据上下文重新推导 REPO/PR，也不要猜测 SHA。如果运行期间稍后还需要其中任何值，请保留此输出中的值，或重新运行 --print-workdir-only 来恢复 WORKDIR，并从 $WORKDIR/context.env 读取其余值。

REPO_ROOT 是已检出仓库的绝对路径——此技能绝不会再次克隆或复制该仓库。 每当需要读取仓库本身中的文件（而不是 WORKDIR 下获取的内容）时——例如 .github/instructions/ 或任何源文件——始终在路径前加上 $REPO_ROOT（例如 "$REPO_ROOT/.github/instructions"）。绝不要使用裸相对路径：运行期间你当前的 shell 工作目录不一定仍是仓库根目录（你可能已进入 $WORKDIR 检查获取的文件），而这种不确定性正是导致实际运行中未能检测到仓库里已有指令文件的原因。

需要处理的退出码：

• 0：成功，继续执行第 4 步。
• 1：致命错误——缺少 REPO/PR，或 CI 模式下工作树不干净。打印脚本自己的错误输出并停止；不要尝试绕过错误。
• 2：交互模式下工作树不干净。告知用户先提交或暂存更改（只有在用户明确确认可以的情况下，才自行使用 --force 重新运行）。

未提供 PR（仅限交互模式）： 如果还没有 --repo/--pr，请在运行脚本前向用户索取 PR URL 或 owner/repo#number（例如 andresjz/API#1）。在 CI 模式下，REPO/PR 来自 GITHUB_REPOSITORY/PR_NUMBER 环境变量，脚本会自动读取——在 CI 模式下绝不要提问（见下文）。

模式和发布行为，以脚本输出的 MODE= 为准：

• MODE=CI：发布前绝不要请求确认——流水线本身就是审批关卡。生成评审后直接发布（第 6 步）。绝不要以任何形式等待用户输入。
• MODE=INTERACTIVE：向用户展示草稿，并在发布前请求确认（见第 5 步）。

前提条件

• gh 必须已通过身份验证（gh auth status）
• 必须已安装 clickup-cli，且可在 PATH 中访问
• 必须设置 CLICKUP_TOKEN 环境变量以进行 ClickUp 身份验证
• 必须设置 CLICKUP_TEAM_ID 环境变量（例如 90111366728）
• .github/instructions/ 目录必须存在且包含指令文件
• PR 必须处于开放状态且可访问

必需工作流

此后引用的所有临时文件（meta.json、diff.txt、files.txt、head_sha.txt、comments.json、inline_comments.json、clickup_tickets.txt、clickup_summary.txt、context.env、summary.md、summary_simple.md、summary_fallbacks.md、findings.jsonl）都必须位于步骤 1 中 scripts/prefetch.sh 输出的 WORKDIR 下，绝不能放在其他路径或手动计算出的路径下。

4. 发现并仅加载相关指令（与仓库无关）

此技能必须适用于任何仓库、语言和框架。绝不要硬编码 java.instructions.md 或 controllers.instructions.md 之类的文件名——应发现实际存在的文件并动态判断其相关性。

ls "$REPO_ROOT/.github/instructions"/*.md 2>/dev/null

始终以 $REPO_ROOT（来自步骤 1 的输出）为基准，绝不要使用裸相对路径——参见步骤 1 中关于 REPO_ROOT 的说明。

不要将搜索范围限制为仅 *.instructions.md。 有些仓库会直接使用普通文件名（例如 coding-standards.md、security.md），不带 .instructions.md 后缀或任何 frontmatter——这些也都是有效的指令文件，必须一并发现。如果上面的 glob 没有返回结果，说明该目录中完全没有 .md 文件（或目录不存在）——不要在未实际运行搜索的情况下假定“没有指令”。

对于找到的每个 *.md 文件，判断它是否适用于此 PR：

层级 1 — frontmatter 中的 applyTo（优先，符合 GitHub Copilot 自定义指令约定）： 读取文件顶部的 YAML frontmatter（位于 --- 行之间）。如果其中有一个包含一个或多个 glob 模式的 applyTo 键（例如 applyTo: "**/*.java" 或 applyTo: "**/*Controller.java,**/*Controller.kt"），将 $WORKDIR/files.txt 中的每个路径与这些 glob 模式匹配。

• 匹配 → 审查这些文件时纳入此指令文件的内容。
• 没有任何变更文件匹配 → 完全跳过此指令文件（不要加载其内容，也不要提及它）。
• 如果文件没有 applyTo、applyTo 为空，或设为 ** / * → 将其视为始终适用（通用/整个仓库范围的指引，例如 general.instructions.md）。

层级 2 — 文件名关键词回退（仅适用于没有 frontmatter，或没有 applyTo 键的文件）： 从文件名中去掉扩展名（.md 或 .instructions.md），得到关键词。

• 如果关键词指向某种特定技术/模块/层（例如 services、migrations、frontend、terraform），则只有当至少一个已修改文件的路径中包含该关键词（单数或复数形式，不区分大小写）时，才纳入此文件。
• 如果关键词指向通用、与技术栈无关的工程实践——例如 general、default、common、coding-standards、standards、guidelines、conventions、style、security、commits——则将其视为始终适用，与明确设置 applyTo: "**" 相同。如果仅凭文件名无法确定含义，应先阅读文件开头几行：如果内容声明了规则“所有 PR 都必须遵守”（即适用于整个项目，而非特定文件类型），则无论文件名如何，都属于通用指引。
• 如果确实无法判断没有 frontmatter 的文件是通用指引还是特定范围的指引，倾向于纳入该文件——误纳入只会多检查一条指引；误排除则会悄无声息地遗漏真实的项目标准，后者更糟。

仅加载匹配的指令文件。在审查草稿中说明哪些指令文件被认为相关以及原因（写一行即可），以便按仓库审计对应关系，而不是凭空假定。

5. 生成结构化 Review 草稿

分析 diff、说明、ClickUp 工单上下文和现有评论，并用西班牙语生成结构化反馈（参见下文“Review 目标”）。

利用现有评论消除疑问，而不只是避免重复。 将某项问题列为发现之前，请先检查 $WORKDIR/comments.json 和 $WORKDIR/inline_comments.json：

• 如果先前的评论已经说明某个看似异常的做法是有意为之，就不要再次指出；如有相关性，请引用之前的讨论。
• 如果先前的评论提出了相同问题，且当前 diff 中仍未解决，可以引用之前的评论（“如之前所述……”），而不是将其作为新的发现。
• 如果确实不确定某个问题是否成立（例如，某种不寻常的模式可能是项目有意采用的惯例），请先检查之前的评论是否已经解决了这个问题，再作判断。

利用 ClickUp 工单上下文验证实现： 如果 $WORKDIR/clickup_summary.txt 存在且包含工单数据：

• 阅读工单描述，了解需求。
• 找到“Alcance”（范围）部分，确认应修改哪些路由／模块。
• 找到“Resultado esperado”（预期结果），验证 PR 是否实现了预期结果。
• 检查是否有“Replicar”（复现步骤）部分，并验证 PR 是否解决了所述问题。
• 如果 PR 修改了范围中未提及的文件，且没有明确理由，请指出。
• 验证校验逻辑是否符合工单描述（例如，电子邮件校验是否不区分大小写）。

你可以有限度地阅读 diff 之外的文件，以检查代码模式和重复代码。 之前禁止浏览代码仓库的限制过于严格——有些发现（例如“这与 X 中已有的逻辑重复”“这不符合 Y 中使用的模式”）确实需要查看其他文件，才能确保判断准确，而非凭空推测。请遵守以下限制（另请参阅“防止循环的限制”）：

• 与第 4 步中的说明文件一样，始终从 $REPO_ROOT 解析这些路径（例如 "$REPO_ROOT/src/..."）；绝不要使用裸相对路径。
• 只有当读取 diff 之外的文件会实质性影响某项具体发现时才读取，不要为了泛泛探索而读取。
• 优先使用有针对性的 grep／find 搜索函数／类名称，而不是浏览目录。
• 最多额外读取约 5 个文件。若所需文件更多，这项发现可能不值得继续追查；请在 review 中将疑虑作为问题提出，而不是试图穷尽验证。

仅限交互模式：向用户展示草稿并询问：

你确认要在 PR 中发布这条 review 吗？（sí/no）

如果你回答“sí”，就会发布。 如果你回答“no”或希望修改，请告诉我需要更改的内容。

CI 模式：跳过此步骤，直接进入第 6 步。

分析时准备行内评论候选项，但要一次性写入，不要针对每条发现单独调用工具。 对于每条符合行内评论条件的发现（参见“撰写可执行评论”中的标签指南），在识别它时，也就是查看对应 diff 代码块时，立即确定其 path／snippet／tag／body，但暂时将其保存在自己的工作笔记中。只有在完成所有文件的分析之后，才使用一次 Bash 调用（一个 heredoc，每条发现占一行）将所有收集到的发现写入 $WORKDIR/findings.jsonl。绝不要针对每条发现分别调用 Bash 工具，逐条追加到此文件——每次工具调用都会占用预算中的一轮；在大型 PR 中，这样会耗尽预算，导致你甚至无法进入第 6 步（发布），最终一条评论都发不出去，连总体摘要也无法发布。此限制适用于所有技术栈：任何语言的大型 PR 都可能出现这种情况。 不要计算行号——请改用具有辨识度的 snippet。 post_review.sh 脚本（第 6 步）会通过机械方式将片段解析为行号。请选择你要评论的准确行中最独特的子字符串——函数／方法调用、字符串字面量或变量赋值，且该内容在文件中只出现一次。避免使用单个常见标记（}、);、pass、return、null），因为它们会在文件中反复出现。片段越独特，解析就越可靠。

对于多行建议块，请添加 start_snippet，填写范围的第一行（同时保留作为最后一行的 snippet）。脚本会解析二者并构建正确的范围负载。

一次性写入所有发现（单次调用，每行一个 JSON 对象——JSONL）：

cat > "$WORKDIR/findings.jsonl" << EOF
{"path": "<path/to/file>", "snippet": "<distinctive substring from the exact line>", "tag": "BUG", "body": "[BUG] full comment body here, including any suggestion fence"}
{"path": "<path/to/other-file>", "snippet": "<last line of range>", "start_snippet": "<first line of range>", "tag": "PATTERN", "body": "[PATTERN] another finding's full comment body here"}
EOF

到达第 6 步时，findings.jsonl 已包含每条行内评论候选的标识信息——脚本会自动解析行号并发布评论。

6. 发布审查

CI 模式：自动发布，无需确认。交互模式：仅在用户确认后发布。

所有发布逻辑都由 scripts/post_review.sh 处理——这是一个确定性脚本，它会：

1. 读取 $WORKDIR/findings.jsonl（在第 5 步中写入）和 $WORKDIR/summary.md
2. 通过 grep -n -F 将每条发现中的 snippet 解析为实际行号
3. 通过 gh pr comment 发布摘要（选项 A）
4. 通过 gh api POST .../pulls/.../comments 发布每条行内评论（选项 B）
5. 失败时重试一次；如果行内评论失败，则改为发布后续的一般评论
6. 将结果报告到 stdout

bash "$(dirname "$0")/../scripts/post_review.sh"

**退出代码：**成功时（包括使用回退方案的部分成功）post_review.sh 返回 0；如果摘要评论本身无法发布，则返回 1。

**CI 模式：**如果只需要一般摘要（可减少 API 调用和 CI 耗时），可以使用 POST_REVIEW_DISABLE_INLINE=true 运行 post_review.sh，以完全跳过行内评论。

7. 清理

这是必须执行的最后一步，无论审查是否已发布、是否跳过，或运行是否中途失败，都始终要执行。要求很明确：仅清空本技能在本次运行期间创建的临时文件——不要处理 /tmp 中的其他内容。

for f in "$WORKDIR/meta.json" \
         "$WORKDIR/diff.txt" \
         "$WORKDIR/files.txt" \
         "$WORKDIR/head_sha.txt" \
         "$WORKDIR/comments.json" \
         "$WORKDIR/inline_comments.json" \
         "$WORKDIR/clickup_tickets.txt" \
         "$WORKDIR/clickup_summary.txt" \
         "$WORKDIR/context.env" \
         "$WORKDIR/summary.md" \
         "$WORKDIR/summary_simple.md" \
         "$WORKDIR/summary_fallbacks.md" \
         "$WORKDIR/findings.jsonl"; do
  [ -f "$f" ] && echo "" > "$f"
done

将此操作作为最后一步，在所有 gh 发布调用完成（无论成功或失败）后执行——切勿在运行过程中清空这些文件，因为后续步骤仍会读取它们。不要使用通配符，也不要删除 $WORKDIR 下的其他任何内容——只能删除本技能写入的文件。

审查目标

你是一名正在审查 Pull Request 的资深代码审查员。

使用：

• PR 差异（$WORKDIR/diff.txt）
• PR 元数据（标题、描述、作者）
• ClickUp 工单上下文（如有，$WORKDIR/clickup_summary.txt）
• 与已修改文件相关的 .github/instructions
• PR 上现有的评论（避免重复）

用西班牙语撰写结构化审查，内容包括：

0. 质量评分

审查开头必须给出 PR 的总体质量评分，并严格使用以下格式：

## Puntuación de Calidad
⭐⭐⭐⭐ — [Justificación de 1-2 líneas, basada en los hallazgos concretos de las secciones siguientes, no genérica.]

评分标准（选择一个最符合 PR 实际状况的标准——与技术栈无关，适用于后端、前端、基础设施等）：

评分	标准
⭐	引入错误或破坏关键模式
⭐⭐	存在多处与标准不一致的情况
⭐⭐⭐	功能可用，但仍有改进空间
⭐⭐⭐⭐	遵循良好实践；只有细微问题
⭐⭐⭐⭐⭐	代码堪称典范；遵循所有标准

评分理由必须提及实际发现的问题（例如“有 2 个潜在错误，且缺少测试覆盖”或“遵循项目模式，只有命名方面的细节问题”），不能使用“做得不错”这类没有结合下文内容的泛泛表述。必须在完成逐文件分析和指南合规性分析之后再确定评分——评分应由发现的问题得出，而不是先定评分再找依据。

1. 更改摘要

• 用 3 到 7 条要点描述 PR 中的主要更改。

2. 逐文件反馈

对于每个已修改的文件，请指出：

• 可能存在或已确认的错误。
• 缺失的边界情况。
• 性能、并发或安全方面的问题。

3. 规范遵循情况

根据步骤 4 中加载的所有指令文件核查是否遵循规范——每个已加载的指令文件单独设一个小节，并以该文件自身的名称或主题作为标题（例如，如果仓库包含 frontend.instructions.md 和 terraform.instructions.md，就根据这两者进行审查；除非仓库指令确实定义了这些类别，否则不要假设应按 Java/API 风格划分控制器、服务、实体和 DTO）。

4. 测试缺口

指出 PR 中缺失或薄弱的测试。 必要时提出具体的测试用例。

5. 改进建议

提出切实可行的改进，例如：

• 小幅重构。
• 改进命名。
• 提取辅助函数。
• 优化模块组织。

6. ClickUp 工单背景

仅当 ClickUp 工单数据已成功获取时（即 $WORKDIR/clickup_summary.txt 存在且包含有效数据），才包含此部分。

解析摘要文件并呈现：

### 6. Contexto del Ticket ClickUp
**Ticket**: [CU-XXXXXXXX](https://app.clickup.com/t/XXXXXXXX)
**Nombre**: [Task name from summary]
**Estado**: [status] | **Prioridad**: [priority]
**Asignados**: [assignees]

**Descripción del ticket**:
[Resumen breve de lo que el ticket solicita, extraído de la descripción]

**Alcance mencionado en el ticket**:
- [Lista de rutas/módulos mencionados en el ticket]
- Verificar que estos archivos/rutas están modificados en el PR

**Resultado esperado**:
[Lo que el ticket espera como resultado]

**Validación**:
- ✅/❌ El PR implementa el resultado esperado
- ✅/❌ Todas las rutas del alcance están cubiertas
- ✅/❌ La validación maneja el caso descrito
- ⚠️ Observaciones adicionales o gaps detectados

如果未找到工单或获取失败：

### 6. Contexto del Ticket ClickUp
⚠️ **Ticket no encontrado**: No se pudo obtener la información del ticket CU-XXXXXXXX.
El PR será revisado sin el contexto del ticket.

如果在分支名称或 PR 描述中未找到工单 ID： 完全省略此部分。

编写可执行的评论——包含解决方案示例

每条 [BUG]、[MIGRATION]、[PATTERN] 和 [BREAKING] 评论都应包含一个代码示例，展示如何修复或缓解问题。

[MIGRATION] 不仅适用于后端或 SQL，还应用于任何结构性且难以回退的更改：数据库迁移、基础设施状态变更（Terraform/Pulumi）、配置架构变更、队列或主题重命名、功能标志推出步骤、前端构建或路由迁移等。具体示例应使用实际变更所采用的语言或格式（SQL、HCL、YAML、JSON、shell），而不是默认使用 SQL。

不佳——只说明问题（后端/数据库示例）：

[MIGRATION] DROP COLUMN 没有回填。建议添加 UPDATE 回填，以防万一。

良好——问题 + 具体修复（后端/数据库示例）：

[MIGRATION] DROP COLUMN 没有回填。请在 DROP 前添加 UPDATE 回填：

UPDATE notifications
SET message_data = (
    COALESCE(message_data::jsonb, '{}'::jsonb) ||
    jsonb_build_object('unitType', unit_type)
)::text
WHERE unit_type IS NOT NULL;

ALTER TABLE notifications DROP COLUMN IF EXISTS unit_type;

良好——问题 + 具体修复（基础设施示例，适用于非后端仓库，同一原则）：

[MIGRATION] 此 Terraform 中 instance_type 的变更会强制重新创建资源（而非原地更新），导致停机。请使用 lifecycle.create_before_destroy，或分阶段迁移：

resource "aws_instance" "app" {
  instance_type = "t3.large"
  lifecycle {
    create_before_destroy = true
  }
}

以上两个示例展示了相同标签在不同技术栈中的应用——请选择与实际仓库相符的格式，不要强行对非后端变更使用 SQL。

按发现类型提供指导：

标签	示例中应包含的内容	是否使用 suggestion 块？
[BUG]	修正后的代码片段（前后对比）	是，如果修复是机械性的，且只涉及一处（空值检查、错误的变量、差一错误）
[MIGRATION]	按仓库所用格式编写的结构性变更修正方案（数据库迁移使用 SQL、基础设施使用 HCL/YAML、配置使用 JSON schema 等），并在适用时包含回滚或回填策略	否——几乎总是需要判断（数据量、停机窗口、部署顺序）
[PATTERN]	按项目模式应有的写法（重构后的代码）	否，除非变更很简单，且完全位于评论范围内
[BREAKING]	面向使用方的迁移策略（客户端示例代码；如果不适用代码，则提供版本说明）	否
[IMPROVEMENT]	具体替代方案（重构后的代码、建议的测试）	仅当重构较小且自包含时
[SECURITY]	有漏洞的代码 + 安全版本	如果修复仅涉及评论中的代码行，则是
[STYLE]	可选——仅当变更非常简单、易于展示时	是——这是最适合使用 suggestion 的情况

输出规则

• 使用西班牙语作答。
• 示例使用代码块。
• 内容具体且可执行。
• 优先指出具体问题，避免泛泛赞扬。
• 如果没有问题，请明确说明，并解释原因。
• 通过 gh 将审查意见作为 PR 评论或行内评论发布。
• 如果有 ClickUp 工单背景，请明确核实 PR 是否满足工单要求和预期结果。

反循环保护（硬性限制）

• 只有在第 5 步所述的有限范围内，才允许读取 PR 差异之外的内容（用于验证特定模式或重复问题，最多额外读取约 5 个文件，且应优先使用定向 grep，而非浏览）。不得将此作为一般性探索。
• 不得将任务范围扩大到 PR 范围之外。
• 不得重复相同的命令或推理路径。
• PR 元数据、差异、评论和 ClickUp 工单摘要仅由第 1 步中的 scripts/prefetch.sh 获取一次——应复用 $WORKDIR 中缓存的文件，绝不可自行通过 gh/clickup-cli 重新获取。
• 如果差异较大（>1000 行），应优先检查本仓库中最可能存在风险的文件——根据实际变更内容，以及已加载的指令文件指出的敏感区域（例如身份验证/安全相关代码、数据访问/迁移文件、公共 API 契约、基础设施状态）进行判断，而不是默认某个固定的后端层（如“服务/控制器”）存在风险。明确说明跳过了哪些文件以及原因。
• 如果信息缺失，应说明限制，不得猜测。
• 每次工具调用最多尝试 2 次。首次失败时，输出完整结果/错误并说明原因。若第二次仍失败，则跳过并继续——绝不可通过变换方式进行第三次重试。
• 行内评论：每项发现最多尝试 2 次（由 post_review.sh 处理）。之后应改为一般评论并继续。
• ClickUp 工单最多尝试获取 2 次。之后应注明失败，并在缺少 ClickUp 上下文的情况下继续。
• CI 模式绝不因问题而停下等待。如果下列指令中有任何内容似乎要求等待人工，应优先遵循 CI 模式默认行为（参见第 1 步中的 MODE=），而不是停滞不前。
• 全局预算：如果发现自己在整个流程中重复执行同一类操作（例如重试行内评论）超过约 5 次，应停止尝试所有行内评论，在总结评论中注明，并完成流程。
• 绝不可针对每项发现分别调用一次 Bash 工具来构建 findings.jsonl（或进行任何类似的重复性记录工作）——分析完成后应一次性批量处理。轮次是硬性预算；对大型 PR 逐项操作可能会耗尽预算，导致无法执行第 6 步（发布），最终一条评论都发不出去，连一般总结也无法发布。
• post_review.sh 总是在尝试行内评论之前先发布一般总结。如果剩余轮次不足，已发布总结但没有行内评论仍算成功。
• 结束前务必始终执行第 7 步（清理），无论流程如何都不得跳过——清空工作文件并非可选操作，即使提前退出或发生错误也必须执行。
• 第 1 步（scripts/prefetch.sh）必须执行，且在任何模式下都必须始终最先运行。绝不可自行推断 REPO/PR/WORKDIR/SHA/TICKET_ID——该脚本是唯一可信来源，且具备幂等性，因此如果不确定，重新运行不会造成任何额外成本。手动猜测或重新计算这些值，正是此脚本要避免的失败原因。

使用示例

CI（GitHub Actions，环境变量已设置：GITHUB_REPOSITORY、PR_NUMBER、GITHUB_BASE_REF、CI=true、CLICKUP_TOKEN、CLICKUP_TEAM_ID）：

以非交互式／打印模式运行 Agent，并将该技能的 SKILL.md 作为输入。具体命令取决于所用的 Agent。Agent 需要能够使用 git、gh、jq、clickup-cli、ls、cat、find、grep、head、mkdir、tr、echo、bash、Read 和 Write 工具。

示例（通用）：

<agent-cli> --print --max-turns 40 < SKILL.md

**CI，推荐做法：**流水线可以选择在调用 Agent 前自行运行 scripts/prefetch.sh --repo "$GITHUB_REPOSITORY" --pr "$PR_NUMBER"，这样如果获取失败，就能在 Agent 的回合预算之外尽早让任务失败。无论采用哪种方式，Agent 都会在步骤 1 中将同一脚本作为首个操作运行（或无害地重新运行）；现在无需单独配置“快速通道”提示词，因为该脚本已随技能打包，且在设计上具备幂等性。对于使用不太擅长遵循纯文本指令的模型的流水线（例如通过中继使用的非 Claude 模型），这是预期的集成方式——它能消除一整类虚构或臆造上下文值的问题，并减少令牌用量。

交互式：

• 用户：“审查 PR myorg/myrepo#42”
• 用户：“审查 https://github.com/myorg/myrepo/pull/42”
• 用户：“审查当前 PR（假设在已检出的分支上运行 gh pr view 可正常工作）”