pma-cr

PMA 代码审查

使用此技能，以高信噪比、低噪声的流程审查代码和工程质量。它独立于 PMA 开发工作流运行。

此技能适用于：

• 提交或合并前审查本地差异
• 审查拉取请求中的变更行及其上下文
• 对现有代码库进行全仓库审计
• 根据项目要求进行基于技术栈的审查

范围

此技能只有一个入口，并包含多个内部审查包：

• 通用审查策略和工程基线
• TypeScript 前端审查
• TypeScript 后端 / Bun 审查
• Go 审查
• Rust 审查
• Python 审查

保持入口技能精简。只加载检测到的技术栈所需的参考文件。

快速开始

本地审查：

/pma-cr

PR 审查：

/pma-cr <PR-number-or-URL>

代码库审计：

/pma-cr audit
/pma-cr repo
/pma-cr --repo

工作流

遵循自然语言请求中明确指定的审查意图，包括仅审查已暂存的内容或指定比较基准。以下参数规则用于消除简写调用的歧义。

1. 按以下顺序检测审查模式：
   • 首先检查 PR 引用：单独的 PR 编号，或包含 /pull/ 或 /pulls/ 的 URL -> PR 审查
   • 否则，检查是否存在独立参数 audit、repo 或 --repo（绝不能将单词、路径或 URL 中的子字符串视为独立参数——.../audit-service/pull/12 是 PR，而非审计）-> 代码库审计
   • 否则，若参数命名的是现有本地分支或 origin/ 分支 -> 分支审查；将其精确分支引用解析为提交，并使用本地模式的基准确定流程
   • 否则，若参数命名的是现有文件或目录 -> 仅针对该路径进行本地差异审查
   • 其他任何参数 -> 询问其意图；绝不猜测模式
   • 没有参数 -> 本地差异审查
2. 收集适用的代码库指引和验收标准。阅读 references/core-review-policy.md 和 references/engineering-baseline.md。
3. 确定快照、范围、预期行为和受影响的使用方。对于代码库审计，还需阅读 references/repository-audit.md。
4. 根据审查文件和清单检测技术栈及支持的版本。在审计模式下，使用代码库清单。记录此快照相关的质量门及其实际结果；不要仅仅因为工具捕获了失败就忽略它们。
5. 只阅读匹配的技术栈审查包：
   • references/typescript-frontend.md
   • references/typescript-backend.md
   • references/go.md
   • references/rust.md
   • references/python.md
6. 审查意图和设计，然后追踪受影响边界之间的行为并检查测试的有效性。在相关时执行兼容性和运维检查；扩展上下文，充分验证相关结论。
7. 证伪并去重审查发现。报告证据、检查结果、覆盖范围，以及适当的结论或审计优先级。仅进行审查并不授权修复或向远程写入。

技术栈选择

使用以下启发式规则：

• TypeScript 前端：tsx、React、Next.js、Vite、路由、UI 组件、浏览器状态、客户端表单
• TypeScript 后端 / Bun：Hono、Express、Fastify、Nest、Bun 服务端代码、API 路由、数据库访问、工作进程
• Go：go.mod、*.go
• Rust：Cargo.toml、*.rs
• Python：pyproject.toml、setup.py、requirements.txt、*.py

Next.js Route Handlers / Server Actions -> 同时加载 TS 前端和 TS 后端工具包。

如果更改涉及多个技术栈，请加载所有相关工具包，并依据对应工具包检查每个更改区域。

技术栈工具包示例是检查提示；共享策略决定其证据和影响是否足以构成问题。

对于未列出的语言或仅涉及配置的更改，请应用共享基线和相关项目规则；如有专业知识或工具方面的限制，请予以说明，不要声称已完成特定语言的审查。

pma-cr 负责审查工作流和问题发现。PMA 技术栈技能提供实现验收基线；仅当项目采用该基线时，才将其作为辅助策略加载。不要启用其开发流程，也不要将其他组织的建议视为项目的强制规则。

审查优先级

审查顺序、证据要求和置信度筛选：参见 references/core-review-policy.md。

本地审查模式

使用本地模式获取确定性的快照。明确指定的暂存区、分支、基准或路径请求优先于默认设置。

• 检查 git status --short、已暂存和未暂存的差异，以及相关的未跟踪文件，包括测试和配置。仅包含未跟踪文件的更改属于工作树审查；检查其完整内容，但不要读取无关的机密信息或依赖项输出。
• 存在本地更改且未明确指定快照时，审查相对于 HEAD 的最终工作树（git diff HEAD -- 加上相关未跟踪文件）。不要将已暂存和未暂存的补丁拼接起来，造成相互矛盾的问题发现。如果索引内容与工作树内容不同，请说明审查的是哪一方。
• 对于仅审查已暂存内容的请求，使用 git diff --cached，并从索引读取上下文和清单（git show :path），而不是读取较新的工作树版本。对于分支审查，使用已解析的 HEAD 提交中的文件；不要混入本地编辑。
• 如果仓库没有 HEAD，请将相关新增内容作为新的快照审查，不要臆造基准。
• 对于干净的工作树或明确指定的分支审查，按以下顺序解析基准：用户明确指定的基准、已知的 PR 目标分支、远程默认分支（refs/remotes/origin/HEAD），然后是明确无歧义且存在的 origin/main 或 origin/master。仅当 upstream 已确认为预期的集成基准时才使用；不能仅因为它是功能分支的跟踪副本就使用。
• 将 HEAD 和基准解析为提交 ID，并比较合并基准与 HEAD（git diff <merge-base-sha> <head-sha> --）。引用和路径参数应加引号，并使用 -- 分隔路径规格。如果没有可信的基准或候选项不明确，请询问缺少的基准，同时继续完成独立检查。
• 已解析的空比较意味着该范围内没有更改。绝不要用任意的近期提交窗口或未经请求的仓库审计来替代。
• 跟踪重命名、删除及其使用方。对于限定路径的审查，可使用范围外的上下文作为证据，但不要擅自扩大请求的问题发现范围。
• 阅读用户要求审查的人工编写更改。如果更改规模或上下文缺失导致无法完成，请报告部分覆盖情况和未审查区域。
• 如果审查期间本地内容发生变化，请刷新受影响的问题发现，或说明报告针对的是哪个较早的快照。
• 先列出问题发现，然后说明范围、检查、覆盖情况，以及 references/core-review-policy.md 中定义的结论。

PR 审查模式

在 GitHub 或已确立的 Gitea 实例中使用 PR 模式。

• 从 origin 确定代码托管平台，并验证提供的 PR URL 是否指向该仓库；不要向仅根据用户提供的 PR 文本推断出的主机发送凭据
• github.com 使用 gh；适用的用户/项目说明已声明某主机为 Gitea 时，使用 gitea 技能，无需重新发现
• 对于未知的非 GitHub 主机，解析 SSH 主机别名，并使用不带 SSH 端口的 HTTPS 主机；探测 https://<host>/api/v1/version：HTTP 200 响应中的 JSON 含有 version 字段即可确认其为 Gitea；401/403 表示需要身份验证，因此在有可用于该主机的凭据时使用这些凭据重试；对于无法确定的响应，应请求澄清代码托管平台，而不是猜测
• 使用选定的代码托管客户端检查 PR 状态、目标分支、base/head SHA、变更文件、差异以及相关检查结果；根据该 head 读取上下文，并披露任何 API 截断或缺失的文件
• 已合并或已关闭的 PR → 报告其状态并停止，除非用户明确要求回顾性审查
• 草稿 PR → 正常审查并说明其状态；不得将草稿审查视为批准合并
• 只审查变更的行为及其附近上下文，不审查无关的遗留代码
• 仅当用户明确要求委派时才使用 agents/code-reviewer.md；否则在当前会话中完成审查
• 默认在本地呈现审查结果；只有在用户明确授权时才发布，并遵守本会话中已授予的授权
• 在 GitHub 上，默认使用 gh pr review --comment；仅在用户明确要求时使用 --approve 或 --request-changes（注意：对自己的 PR 使用 --approve 会失败）
• 在 Gitea 上，使用已确立的基础 URL 和 gitea 技能的 PR 审查或 issue 评论端点；通过结构化正文或安全写入的临时文件发送自由格式的审查文本

仓库审计模式

当目标是评估当前仓库，而非差异时，使用仓库审计模式。

• 清点清单文件、入口点、CI、测试和技术栈标记
• 梳理重要契约、模块边界、状态归属、关键测试和运维路径，以及安全热点
• 优先检查风险最高的模块
• 按根本原因去重发现，而非按文件数量去重
• 将已确认的问题与覆盖缺口和建议的后续操作分开；报告优先级和已审计的范围，而非给出合并结论

输出规则

• 关于应报告和应跳过的内容（置信度筛选）：参见 references/core-review-policy.md。
• 本地差异和 PR 的输出模板：参见 references/core-review-policy.md 的 “Output Format” 部分。
• 仓库审计报告模板：参见 references/repository-audit.md 的 “Report Skeleton” 部分。

参考资料包

• references/core-review-policy.md：证据、严重性、决策、检查结果和输出格式
• references/engineering-baseline.md：适用于所有技术栈的意图、设计、正确性、测试质量、兼容性和运维检查
• references/repository-audit.md：全仓库审计工作流、热点选择和报告框架
• references/typescript-frontend.md：React / Next.js / Vite / 浏览器 UI 审查规则
• references/typescript-backend.md：Node / Bun / API / 验证 / DB / 异步审查规则
• references/go.md：Go 审查规则，涵盖上下文、错误、并发、HTTP 和资源安全
• references/rust.md：Rust 审查规则，涵盖 panic 边界、异步阻塞、unsafe、文档和 API 契约
• references/python.md：Python 审查规则，涵盖验证、反序列化、异步、类型安全和命令注入
• agents/code-reviewer.md：可选的子 Agent 提示词；仅在用户要求并行或隔离审查时使用
• evals/review-cases.md：行为回归场景；维护此技能时阅读，常规审查无需阅读

这些资料包有意收纳了详细规则，以便让此文件保持精简且加载成本低。