claude-cookbooks 的 /review-issue 定制斜杠命令：用 Claude Code 标准化 GitHub Issue 审核流程

claude-cookbooks 的 /review-issue 定制斜杠命令用 Claude Code 标准化 GitHub Issue 审核流程【免费下载链接】claude-cookbooksA collection of notebooks/recipes showcasing some fun and effective ways of using Claude.项目地址: https://gitcode.com/GitHub_Trending/an/claude-cookbooksclaude-cookbooks 仓库在.claude/commands/review-issue.md中定义了一个名为/review-issue的 Claude Code 自定义斜杠命令用于按社区规范审核并回复 GitHub issue从拉取 issue 详情、六类问题分类、逐类型草拟回复到标签建议与人工批准后执行的完整闭环。阅读本文你将掌握该命令的完整定义结构、八步审核流程、回复语气准则与三类范例回复并能复用到自己的仓库中用最小权限工具声明 结构化流程提示词 人工审批门这一模式把重复性的 issue 维护工作交给 AI 完成。1. 命令定位.claude/commands/下的仓库级工作流在 claude-cookbooks 中所有 Claude Code 斜杠命令集中存放在.claude/commands/目录仓库根目录的 CLAUDE.md 将.claude/标注为 Claude Code commands and skillsCONTRIBUTING.md 进一步说明这些命令在 Claude Code本地开发和 GitHub Actions CI 中都能工作并强调其使用与 CI 流水线完全相同的校验逻辑帮助开发者在 push 之前提前发现问题。当前该目录下共有六个命令各自覆盖一种协作场景命令文件用途review-issue.md审核并回复 GitHub issue本文主题review-pr.md人工触发的 PR 代码审查含审批交互review-pr-ci.md面向 CI/自动化环境的 PR 审查自动回帖notebook-review.mdJupyter notebook 与 Python 脚本综合审查model-check.md校验 notebook 中 Claude 模型引用是否过时link-review.md检查变更文件中的链接质量与安全问题可以看到一个清晰的设计分界PR 侧审查/review-pr、/notebook-review等关注代码与 notebook 质量而/review-issue是唯一面向 issue 队列的命令承担的是社区接口人角色——它不写代码而是帮助维护者快速判断一个 issue 属于什么性质、该怎么回、要不要关。2. 定义文件完整结构解析整个命令就是一个带 YAML frontmatter 的 Markdown 文件由元数据 提示词正文两部分构成。2.1 YAML frontmatter最小权限的工具白名单文件头部review-issue.md 第 1–4 行声明了--- allowed-tools: Bash(gh issue view:*), Bash(gh issue list:*), Bash(gh issue comment:*), Bash(gh issue edit:*), Bash(gh issue close:*), Read, Glob, Grep, AskUserQuestion description: Review and respond to a GitHub issue ---这里有两处值得借鉴的工程细节allowed-tools做了细粒度收敛。它没有笼统地放开Bash而是用Bash(gh issue view:*)这样的语法把 Shell 权限精确限定在gh issue子命令族内——view查看、list列表、comment评论、edit加标签等编辑、close关闭。这意味着即便提示词被跑偏命令执行器层面也不允许 Claude 执行git push、gh pr merge等白名单之外的操作。对比同目录的 review-pr.md声明了Bash(gh pr checkout:*)、Bash(git log:*)、Task等更宽的工具集issue 命令的工具面更小与其只读调研 有限写操作的任务性质匹配。Read、Glob、Grep与AskUserQuestion各司其职。前者三个支撑流程中读取被 issue 引用的 notebook/文件以验证问题是否属实这一步AskUserQuestion则是后面 Step 7人工审批门的载体——所有对 GitHub 产生实际写操作回帖、打标、关单的动作都必须在用户通过该工具明确点头之后才执行。description字段则用于命令发现与展示Review and respond to a GitHub issue。2.2 参数约定正文以## Arguments开篇声明唯一入参$ARGUMENTS要审核的 issue 编号。调用形式即/review-issue issue number。$ARGUMENTS是 Claude Code 斜杠命令的内置占位符会在命令体中的所有gh命令里被替换为实际编号。3. 八步审核流程命令正文## Your task之后把整个任务编排成 Step 1 至 Step 8每一步都有明确的输入、动作和产出。以下按原文完整展开并标注其中蕴含的设计意图。Step 1收集 issue 上下文命令要求第一步就执行固定的gh命令一次性拉取结构化数据gh issue view $ARGUMENTS --repo anthropics/claude-cookbooks --json number,title,body,author,labels,state,comments,createdAt注意--json显式列出了七个字段编号、标题、正文、作者、标签、状态、评论、创建时间而不是默认的文本渲染输出——这让模型在分类时获得的是机器可读的完整结构尤其comments字段保证了issue 下面已经讨论了什么不会遗漏。另外--repo anthropics/claude-cookbooks把目标仓库硬编码进了命令从源码结构看这是一个适用前提该命令直接在本仓库语境下运行若要移植到其他仓库需要同步改写这一参数。Step 2六类问题分类命令要求根据 issue 内容将其归入六类每一类对应完全不同的处理策略Spam/Noise垃圾/噪音乱码、测试帖、跑题内容或有恶意的内容Bug Report缺陷报告报告 cookbook 中损坏的代码、失效链接或错误信息Cookbook Proposal内容提案提议新增内容或重大扩充Question提问询问用法、API 行为或寻求澄清Community Resource社区资源分享分享外部项目或资源应引导至 Discord 等社区渠道Duplicate重复 issue已有同类 issue 或问题已被解决。这套分类覆盖了维护一个内容型仓库而非纯代码库时 issue 队列的主要形态代码仓库常见的bug在这里特指notebook 里坏掉的代码/链接而提案评估与资源分享分流则是教程类仓库特有的高频场景。分类是后续所有分支决策怎么回、打什么标签、关不关的开关。Step 3核验相关上下文对于引用了具体文件或 notebook 的 issue命令要求模型做三件事读取被引用的文件理解上下文验证 issue 是否属实例如失效链接是否真的失效查找可能已处理该问题的相关 issue 或 PR。这一步把流程从机械回帖升级为有据可依的回应——回复中可以说I can confirm the link is broken我已确认链接确实失效而不是空泛的感谢。对仓库维护者而言这也省去了人工翻查 notebook 的时间。Step 4按类型草拟回复这是命令最核心的部分为六类 issue 分别规定了回复策略。原文要求逐条继承如下。Spam/Noise建议不留评论直接关闭如涉及安全问题则单独标记。Bug Report确认收到并感谢报告者尽可能自行验证检查被引用的文件/代码若属实且修复简单邀请报告者提交一个带签名提交signed commits的 PR若属实但复杂确认收到并表示已在关注on our radar;若已修复直接引用修复所在的 PR/commit。原文给出的示例话术是Thanks for the report! Would you be open to submitting a PR to fix this? If so, please ensure you use signed commits。这里邀请提交者直接提 PR的策略与 CONTRIBUTING.md 中的贡献流程分支命名、conventional commits、pre-commit 钩子是配套的——回复把新贡献者引导进了仓库既有的开发工作流。Cookbook Proposal先致谢按三条标准评估是否直接聚焦 Claude API/SDK 能力是否实用且有清晰的教学价值是否与现有内容有差异化若有价值表达兴趣必要时提出澄清问题若不符礼貌说明原因并引导至合适渠道。原文的婉拒示例话术While [topic] is interesting, we focus on showcasing Claudes native API capabilities. Wed encourage you to think about what specific Claude features you want to demonstrate rather than translating patterns from external frameworks. 这实际上把仓库的内容边界只做 Claude 原生 API 能力演示而非移植外部框架模式固化进了回复模板。Question能给直接答案就给指向 Claude 官方文档docs.claude.com如适用引用仓库中具体的 cookbook 示例引导后续讨论去 Discord 社区若属 API 本身的 bug引导至正确的报告渠道。Community Resource感谢分享但分流到更合适的场地明确该仓库的 issue 只用于 cookbook 相关问题不做社区展示墙分流后关闭 issue。原文示例话术Thanks for sharing your project! We dont track community resources as GitHub issues, but there are great places to share your work: the#share-your-projectchannel on our Discord or the r/ClaudeAI community on Reddit.Duplicate引用原始 issue/PR情况合适时作为重复项关闭。Step 5建议标签命令维护了一张七项标签映射表让分类结果直接落成 GitHub label标签适用类型bugBug 报告enhancement功能请求或提案question提问documentation文档改进duplicate已存在wontfix不予处理good first issue适合新贡献者的简单修复值得注意的是good first issue这一项当 Step 4 判定bug 属实且修复简单、并邀请报告者提 PR 时打上该标签可以进一步把它转化为社区新手的入口任务。分类、回复、标签三条线在这里汇合。Step 6结构化呈现审核结果在采取任何动作之前命令要求把调查结论以固定六段式呈现给用户Issue Summaryissue 说了什么的简述Classification归类结果Validity Checkissue 是否成立/可操作如果做过核验Suggested Response草拟好的、可直接发布的评论Suggested Labels建议添加的标签Suggested Action建议是评论、关闭还是其他操作。这个输出模板让AI 做了什么判断完全透明可审查——维护者不需要逐条追问一眼即可看到分类依据、草稿回复和建议动作然后整体拍板或逐条修正。Step 7人工审批Human-in-the-loop 门命令明确要求使用AskUserQuestion工具向用户确认三个独立问题是否发布草拟的回复是否添加建议的标签是否关闭该 issue如果适用把三个动作拆成三个可独立批准的选项而不是一个全部执行/全部取消的总开关是细粒度授权的体现例如用户可能只想发评论、暂不打标签。所有对 GitHub 的写操作都被挡在这道门之后这正是 frontmatter 里AskUserQuestion工具存在的意义。Step 8执行动作仅当获批批准后按用户选择执行对应的gh命令原文给出的四条命令为发布评论gh issue comment $ARGUMENTS --repo anthropics/claude-cookbooks --body YOUR_RESPONSE添加标签gh issue edit $ARGUMENTS --repo anthropics/claude-cookbooks --add-label label1,label2关闭 issue指定原因gh issue close $ARGUMENTS --repo anthropics/claude-cookbooks --reason not planned或附带评论关闭gh issue close $ARGUMENTS --repo anthropics/claude-cookbooks --comment Closing because...这四条命令恰好与 frontmatter 白名单中的Bash(gh issue comment:*)、Bash(gh issue edit:*)、Bash(gh issue close:*)一一对应——流程用到的每一类写操作都有且仅有对应的工具权限工具声明与流程步骤互相印证。4. 回复语气准则与三类范例命令正文在流程之后还固定了两段软规范约束草拟回复的风格。语气准则Response Tone Guidelines原文六条准则为专业、友好、简洁感谢贡献者的参与婉拒提案时直接但不居高临下尽可能给出可执行的下一步用链接指向资源而不是把所有解释内联写进评论不过度解释、不过度道歉。三类范例回复原文附带了三段可直接参照的回复模板分别对应最高频的三种 issue 类型Bug 报告回复Hi username, thanks for the detailed report! I can confirm the link is broken. Would you be open to submitting a PR to fix this? If so, please ensure you use signed commits. If youd prefer not to submit a PR, no worries - well get this fixed.注意确认属实I can confirm the link is broken→ 邀请提 PR → 兜底承诺你不提我们也会修的三段结构与 Step 4 的 Bug Report 策略完全一致。提问回复Hi username! The cache_control parameter is needed because... [explanation] For more details, check out the prompt caching documentation. If you have follow-up questions, our Discord is a great place for discussion!以cache_control参数为例展示了直接解释 指向官方文档 引导社区讨论的组合拳其中 prompt caching 主题在仓库内有对应实战内容可查如 misc/prompt_caching.ipynb这也呼应了 Step 4 中引用具体 cookbook 示例的要求。提案婉拒回复Hi username, thanks for the detailed proposal! While the concept is interesting, we focus our cookbooks on demonstrating Claudes native API capabilities directly. Wed encourage you to consider: - What specific Claude API features are you showcasing? - How is this differentiated from existing documentation? - Can users run this self-contained without external dependencies? If you can reframe the proposal around these questions, wed be happy to reconsider. Thanks for your engagement with the SDK!婉拒模板把三条评估标准Claude 能力聚焦、差异化、自包含可运行转成了反问清单给提案者留下重新提交的路径而不是简单关门。5. 与仓库内其他审查命令的协同从源码结构看/review-issue并非孤立存在而是与 PR 侧命令构成完整的质量闭环/review-pr与/review-pr-ci分别面向人工与 CI 环境的 PR 审查。人工版通过Task工具调用code-reviewer子代理一位专精本仓库 notebook 审查的资深工程师人设检查 TLO 学习目标、密钥管理、ruff 规范等审查报告按 APPROVE / REQUEST_CHANGES / COMMENT 三档给出建议同样经AskUserQuestion批准后回帖CI 版则去掉交互直接回帖并把 Detailed Review 折叠进details标签以降低噪音。/model-check拉取官方当前模型列表检查变更文件中是否引用了已废弃模型如旧版 Sonnet 3.5、Opus 3CLAUDE.md 中的 Key Rules 也同步要求使用不带日期后缀的模型别名、Never use dated model IDs。/link-review检查变更文件里的失效链接、过时链接与安全问题与/review-issue中bug 特指 notebook 里坏掉的链接/代码相互呼应——issue 报告失效链接PR 侧则防止新链接问题混入。/notebook-review调用.claude/skills/cookbook-audit/中的 notebook 审查技能做综合质量检查并按 ✅/⚠️/❌ 三级输出结论。也就是说issue 侧命令负责入口分流判断问题真伪、引导贡献者、清理噪音PR 侧命令负责出口把关代码与 notebook 质量、模型时效、链接健康两条线合起来覆盖了 claude-cookbooks 社区贡献的主要协作路径。6. 可复用的设计模式总结以 review-issue.md 为样本可以提炼出一套在任意 GitHub 仓库中复刻AI 值守 issue 队列的做法一个 Markdown 文件即一条命令YAML frontmatter 声明description可发现性与allowed-tools最小权限边界正文用编号步骤写清流程。工具白名单与正文实际使用的命令应严格对齐形成双重约束。固定数据入口第一步就用gh ... --json拉取结构化字段避免模型基于不完整的上下文做判断。先分类后分支定义一张覆盖 issue 队列全部形态的分类表每类绑定独立的回复策略、标签与处置动作避免一刀切模板。验证再说话要求模型读取被引用文件核验真伪回复中才能给出已确认级别的表述。结构化中间产物用固定的六段式输出摘要/分类/核验/草稿/标签/动作把 AI 的判断链完整暴露给人类。写操作必经审批门把发布评论、加标签、关单拆成独立的AskUserQuestion选项批准后才调用对应的gh写命令--repo等目标参数建议按实际仓库改写后固定。语气与范例内置把语气准则和三类回复范例直接写进命令文件让草拟出的评论风格稳定可预期而不是依赖模型自由发挥。这套最小权限 结构化流程 人工审批门的组合让/review-issue既能自动完成最耗时的调查与草拟环节又保证每一次对外发声都经过维护者确认是 claude-cookbooks 维护 issue 队列的代表性实践。【免费下载链接】claude-cookbooksA collection of notebooks/recipes showcasing some fun and effective ways of using Claude.项目地址: https://gitcode.com/GitHub_Trending/an/claude-cookbooks创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考