Cursor 官方插件 pr-review-canvas把 PR Diff 重组为按审查价值分层的 Review Canvas【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins本文基于 Cursor 官方插件仓库中的pr-review-canvas插件完整解析其核心技能文件 SKILL.md 定义的一套 PR 审查方法如何收集 diff、如何按“审查者价值”而非文件树顺序重排变更、何时用伪代码和具体示例轨迹辅助理解、如何用 callout 标注易错点。读完后你能掌握该技能的完整工作流约定并理解 Cursor 技能Skill机制如何把一个“代码审查方法论”固化成可被 Agent 自动触发的流程。插件定位与清单文件pr-review-canvas是这个多插件市场仓库中的一个独立插件目录其定位在仓库根 README 的插件表中被描述为“Render PR diffs as review canvases grouped by importance.”将 PR diff 渲染为按重要性分组的审查画布分类为 Developer Tools作者是 Cursor 官方。从 plugin.json 清单可以看到该插件的关键元数据字段值说明namepr-review-canvas插件唯一标识kebab-case清单规范见 schemas/plugin.schema.jsonversion0.1.0与 CHANGELOG.md 中的 “initial release” 一致descriptionRender PR diffs as review canvases grouped by importance.用于市场展示keywords/tagscursor-plugin、canvas、pr-review、code-review、diff、pull-request、workflow检索与过滤用categorydeveloper-tools市场分类skills./skills/技能目录声明实际指向 skills/pr-review-canvas/SKILL.md插件目录结构遵循仓库 README 描述的通用布局.cursor-plugin/plugin.json清单 skills/技能 README.md/CHANGELOG.md/LICENSEassets/avatar.png图标。该插件只有一个技能Skill即下文的核心文件 SKILL.md——整个插件的方法论全部编码在这 76 行的技能文档里没有附带脚本或代码文件。技能 Frontmatter 与触发方式SKILL.md 以 YAML frontmatter 开头包含两个字段--- name: pr-review-canvas description: - Render a PR diff review as a Cursor Canvas that groups changes by reviewer importance, separates boilerplate from core logic, and highlights tricky or unexpected code. Use when reviewing a pull request, summarizing a diff for review, or when the user asks for a PR review canvas, diff walkthrough, or change-set overview. ---这里的description遵循 Cursor 技能机制的常见写法前半段描述技能做什么后半段以 “Use when ...” 显式列出触发场景审查 PR、总结 diff、用户索要 PR review canvas / diff walkthrough / change-set overview。与仓库内一些设置了disable-model-invocation: true的技能不同例如 cursor-team-kit 下的同名技能 就设置了该字段该 frontmatter 未禁用模型自动调用——从技能结构看当用户意图命中 description 中的触发短语时模型可以自动选择该技能。插件 README 还给出了人话版的触发建议用 “PR review canvas”、“review this PR on a canvas”、“walk me through this diff on a canvas” 等措辞或者直接给 Agent 一个 PR URL / 分支引用。适用场景包括审查 PR 时想要一个“浮出真实风险”而非逐文件 diff 的导览为一位人类审查者总结一叠 PR索要 diff walkthrough、change-set overview或 “what actually changed here” 视角。前置约定先读 Canvas 生成规范技能正文第一条就是 Prerequisites前置条件先阅读~/.cursor/skills-cursor/canvas/SKILL.md。其中包含生成策略generation policy、设计指南、slop 规则、自检清单和文件路径约定——这些是你必须遵守的。完整的组件与 hook 接口声明在~/.cursor/skills-cursor/canvas/sdk/index.d.ts及其同目录的.d.ts文件中——阅读它们来发现确切的导出和 prop 结构而不是靠猜。注意这两处是Cursor 本地安装目录下的文件不是本仓库文件~/.cursor/skills-cursor/canvas/SKILL.md是 Canvas 能力的通用技能仓库中 docs-canvas 插件的前置条件与之完全一致~/.cursor/skills-cursor/canvas/sdk/index.d.ts是 Canvas SDK 的 TypeScript 类型声明。这一约定传递了两个工程原则规范分层通用 Canvas 生成策略设计、slop 规则、自检沉淀在 Cursor 全局技能里插件技能只声明“继承它”避免重复维护以类型声明为事实源要求 Agent 通过读.d.ts发现组件的确切导出名和 prop 形状而不是凭记忆或推测写组件属性——这直接降低了生成无效 Canvas 代码的概率。第一步收集 diff且“没链接就停下问”技能对 diff 来源的约定非常严格SKILL.md期望输入是一个GitHub PR 链接形如https://github.com/owner/repo/pull/n的完整 URL或等价的可用gh解析的引用使用gh pr diff pr收集每个文件的路径、增删行数additions/deletions和 hunk 内容如果用户没有提供 PR 链接停下来问。明确禁止三种“自作主张”猜测当前分支、从最近提交历史推断、退回到本地git diff。必须询问用户要审查哪个 diff具体 PR URL 或编号等回复后再继续。这条规则值得注意插件 README 在 “Requirements” 一节里把可接受的 diff 来源写得更宽——本地分支/refgit diff、GitHub PR URL 或编号gh pr diff、Graphite stackgtCLI /gh。而 SKILL.md 本身只采纳了其中 GitHub PR 这一条并在未提供链接时强制中止询问。可以推断这是把“审查对象必须无歧义”设为硬约束本地git diff的语义哪个 base、哪些暂存改动容易猜错错猜会导致整份 Canvas 建立在错误的 diff 上因此用一次澄清换取确定性。核心方法一按审查价值三层分组技能的核心主张是不要按字母序或文件树顺序呈现文件而是重组为按“审查者价值”排序的三个区段SKILL.md层级内容定义呈现方式1.Core logic核心逻辑新行为、算法变更、状态机转换、API 表面变化展示完整 diff 及周围上下文2.Wiring integration接线与集成路由注册、依赖注入、连接核心逻辑的配置管线压缩呈现——足以确认正确性即可3.Boilerplate mechanical样板与机械改动import 重排、重命名、生成代码、格式化、类型再导出总结为文件名 统计数字列表除非特别相关不内联 diff配套原则只有一句话但很关键“Lead with core logic. The reviewers attention is freshest at the top.”核心逻辑放最前——审查者的注意力在开头最新鲜。这套分组的本质是把 diff 的信息密度和审查注意力预算对齐完整上下文预算只花在核心逻辑上集成层降级为“正确性确认”机械层降级为一行统计。插件 README 的 “How its organized” 一节给出的三层定义与技能正文逐条对应Core / Wiring integration / Boilerplate可作为交叉印证。核心方法二把复杂逻辑蒸馏成伪代码当核心变更包含密集或精巧的逻辑——深层嵌套条件、状态机、重试/退避流程、多步变换——技能要求在 diff 旁附加一段伪代码摘要SKILL.md。伪代码的目标是“剥离语言语法、错误处理和样板用几行暴露本质算法或控制流”让审查者在读真实代码之前先确认意图。同时给出了明确的反触发条件只有当真实 diff 难以扫读时才做直截了当的改动不需要伪代码镜像。也就是说伪代码是条件动作而非默认动作避免把简单改动也包一层冗余。仓库中另一个同名技能提供了很好的对照实现cursor-team-kit/skills/pr-review-canvas/SKILL.md 用一个具体例子说明了这种模式的期望效果——150 行重试/退避/熔断代码其实质就是 “fetch with exponential backoff and circuit breaker”于是先展示 6 行伪代码fetch(url): if circuit breaker is open → fail fast; retry up to N times: ...真实 diff 折叠在下方卡片里。两处技能都体现了同一思路伪代码是“意图层”diff 是“实现层”二者分层展示。核心方法三用具体输入并排跟踪新旧代码路径伪代码展示的是变更的“形状”而**示例轨迹example trace**展示的是它在执行。技能的规则是SKILL.md适用条件某个 hunk 的行为改变是“从代码上难以预判”的——例如副作用被重排、新增短路short-circuit、边界条件被改动做法挑一个具体的、小而现实的输入把它并排走一遍旧代码路径和新代码路径高亮二者分歧的那一步并写清楚可观察的结果差异边界只用于真正出人意料的genuinely surprising行为变化不是每个核心 hunk 都要来一遍。这一条解决的是 diff 审查中一个真实的认知难题对于控制流改动读者往往无法仅凭 /− 行推断最终行为差异而一个具体输入的双重走查能把“新旧行为差”压缩到一个可直接验证的事实上。核心方法四Callout 标注易错点但克制使用当某个 hunk 含有令人惊讶、有风险或容易漏掉的东西时技能要求把它在视觉上与周围 diff 隔离并配一个短标签加一句话解释让审查者把“担忧”和“代码”放在同一视线里看。文档给出的标签示例包括Subtle微妙、Breaking破坏性变更、Race condition竞态、Perf性能SKILL.md。同样有明确的克制条款“Reserve these callouts for genuinely tricky items — overuse destroys signal.”只留给真正棘手的条目——滥用会摧毁信号。这与前两条条件动作伪代码、示例轨迹形成了统一的设计基调辅助手段都是“按信号密度触发”而不是无差别应用。评论语气写给审查者不是变更日志“Tone and content” 一节规定SKILL.md写面向审查者的评论而不是 changelog。焦点放在三点Whysomething changed, not just what changed为什么改而不只是改了什么文件之间的交互关系——例如 “The new validator incore.tsis invoked by the route added inroutes.ts.”core.ts里新增的校验器由routes.ts新增的路由调用任何仅凭 diff 本身看不出来的东西。并且要求评论保持简短每条注释一两句。创作自由度Canvas SDK 组件与“地板而非天花板”技能最后“Be creative”一节SKILL.md明确前面的规则是地板不是天花板目标是让审查者以尽可能快的路径理解眼前这一个变更。文档点名了一批 Canvas SDK 组件能力供选用图表charts、表格、diff 视图、DAG 布局、卡片、统计、交互式状态等。它给出的创意示例包括小型状态图、前后对比的调用图、输入→输出对表格、提交时间线、逐文件的置信度标注、把其余全部折叠进一个大 callout。结尾的设计哲学值得摘录A review of a refactor looks different from a review of a bug fix looks different from a review of a new feature — let the canvas reflect that.即重构审查、缺陷修复审查、新功能审查的 Canvas 应当长得不一样让呈现形式追随变更性质而不是套用固定模板。使用前提与运行环境综合插件 README 的 Requirements 一节使用该插件需要Cursor 已启用 Canvas 功能——技能产物是 Cursor Canvas 而非静态文档依赖~/.cursor/skills-cursor/canvas/下的 Canvas 技能与 SDK 类型声明可访问 diff 来源README 列举了本地分支/refgit diff、GitHub PR URL 或编号gh pr diff、Graphite stackgtCLI /gh三类来源。注意 SKILL.md 的执行约定更严格——默认走 GitHub PR gh pr diff路径且未提供 PR 引用时会停下来向用户要链接而不是自动回退到本地git diff。因此使用gh时应保证已完成认证且对目标仓库有读取权限。延伸阅读仓库内的两个近亲本仓库内还有两份与本文主题直接相关的材料适合对照阅读cursor-team-kit 的 pr-review-canvas同名技能的另一个实现。它产出的是静态 HTML 页面而非 Cursor Canvas——通过gh api拉取 PR 元数据、文件 patch 与评论配合自带的 renderer.js含 import 过滤、空白折叠、移动代码检测与 styles.css 组装页面并用固定端口的本地 HTTP 服务预览。它的 CSS/JS 工具表、data-diff占位符注入机制展示了“同一审查方法学”落到 HTML 技术栈时的具体形态docs-canvas插件面向文档而非 PR 的 Canvas 技能前置条件先读 Canvas 技能与 SDK 类型声明与 pr-review-canvas 完全一致二者共同体现了该仓库中 Canvas 类插件的统一分层通用规范在 Cursor 全局 Canvas 技能里各插件只声明领域特定规则。小结pr-review-canvas这个插件的技术含量不在于代码量它没有一行脚本而在于把一套 PR 审查方法学编码成了 Agent 可执行的流程约束以gh pr diff收集完整 diff、未提供 PR 引用时强制澄清、三层分组把注意力预算分配给核心逻辑、伪代码与具体示例轨迹按需触发、callout 克制使用、评论聚焦 Why 与跨文件交互最后以 Canvas SDK 的组件库支撑“呈现形式追随变更性质”的创作自由度。对想设计审查类技能的开发者而言这份 76 行的 SKILL.md 展示了技能文档的标准写法每个环节都同时给出“做什么”和“什么时候不做什么”。【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考