用途
ponytail-review 是一个代码变更质量审查技能。它的定位是：像那位在代码出问题时会被叫去处理的资深开发者一样，审查一次改动。
审查按重要性排序：正确、安全、在负载下稳定、有测试、快、精简。精简仍然重要——每一行多余的代码，将来都要被阅读、测试和修复。
主要能力
审查会覆盖以下方面：
- Bug：错误结果、崩溃、遗漏的边界情况（空值、零、最后一项、舍入、时区）、被改动破坏的调用方、只在某个调用方修复而共享函数仍然有问题。
- 风险：安全漏洞（注入、弱随机、密钥、对用户输入缺少检查）、数据丢失（错误被吞掉、写入顺序错误、没有事务）。
- 规模：对单用户没问题但对多用户错误的情况，例如先检查后写入的竞态、每个进程重复做同样的工作、只增不减的内存或列表、逐项查询、大输入上的 O(n^2)、本应共享的进程内状态。
- 缺失测试：有风险的新逻辑（分支、解析器、金额、安全、数据写入、bug 修复）没有能在出错时失败的测试。一个好测试即可，不追求覆盖率。
- 速度：大幅变慢是问题；小的优化（热循环中重复的工作）作为建议。
- 精简：本不该存在或可以更小的代码，包括删除死代码、未使用的选项、投机性功能；复用仓库已有的辅助函数；使用标准库或平台原生能力；避免只有一个实现的抽象和没人设置的配置；合并必须一起改的近似重复代码；按职责拆分一个函数做多件不相关事情的情况。
使用方式
审查用户指定的对象：未提交或已暂存的改动、一个分支、一个 PR 链接，或若干文件。如果什么都没指定，就审查未提交的改动；如果没有未提交改动，则审查最后一次提交。
流程是：先阅读 diff，再阅读它触及的代码——每个被改动函数的调用方、它调用的函数、测试、README。追踪真实流程：数据从哪里进来、存了什么、什么出去。改动可能破坏它没有触及的代码；当签名、返回值或行为变化时，要 grep 每一个调用方。从仓库（README、部署配置）中找出预期负载：是一个人跑脚本，还是许多用户和进程同时运行。据此判断规模，并说明假设的负载。
报告前会检查：每条发现都需要具体案例——“这个输入或情况会导致这个错误结果”。没有案例就没有发现。会重新阅读相关行并确认：调用方存在、值确实可能为空、代码确实未被使用。带有 shortcut:（或旧版 ponytail:）注释并说明其限制的捷径属于决策，不是发现，除非预期负载已经越过该限制。会提出能起作用的最小修复，优先选择删除代码的修复，绝不添加问题不需要的层、框架或配置。不涉及风格偏好、不写“考虑”、不写模糊担忧。
输出格式
输出使用非常简单的英语：短句、日常词汇。技术术语第一次出现时解释。读者可能从未见过这段代码。
开头是“What this change does:”，用两三句话说明。
然后是分三组的发现，空组跳过：
- Must fix：bug、安全、数据丢失、在预期负载下会坏。
- Should fix：有风险但没测试的代码、真实的缓慢、重复、职责混杂的函数、本不该存在的代码。
- Nice to have：小的加速、更短的写法。
所有组统一编号，方便用户说“修 2 和 5”。每条发现包含四个部分，每部分一到两句短句：标题（含文件与行号）、What this is（这是什么）、Problem（问题）、Fix（修复）、If we skip it（跳过的后果）。
结尾是：Verdict: Ship. 或 Verdict: fix 1 and 3 first.；如果有精简发现，附上 Lean: -<N> lines possible.；如果有重要内容无法检查，用一行 Not checked: 说明。
如果什么都没发现：先写 What this change does:，然后 Looks good. Ship.，再用一行说明检查了什么。
适用场景
适合在提交代码前、合并分支或 PR 前，对一次改动做结构化质量审查。尤其适合需要判断改动是否安全、是否在真实负载下稳定、风险逻辑是否有测试、是否有可精简之处的场景。
限制
该技能只列出发现，不修改代码。它不做风格审查，不写“考虑”或模糊担忧。每条发现必须有具体案例支撑。带有说明限制的 shortcut 注释被视为决策而非问题，除非预期负载已越过该限制。关于收费、价格、平台支持等具体信息，资料中暂未提供。