kev-pr-description 是一项 Pull Request 写作技能，来自 jaredpalmer/kev 仓库，用于指导如何在 Kev 项目中撰写 PR 标题与正文。其核心主张是：Kev 的 PR 有三类读者——当天的评审者、明年查 git log 弄清某个数字为何变化的人，以及并非机器学习研究者的读者（集成 API 的工程师、学生、好奇的普通人）。写作应面向第三类读者；如果描述只有写 diff 的人能看懂，那它只是变更日志，不是 PR。
用途与定位 技能面向“在 Kev 项目上开启、编辑或评审 PR”的场景，提供一套写作范式与检查清单，帮助作者把 PR 写成解释“变更为何存在、如何运作”的短文，而非罗列文件改动的清单。
写作原则
- 从现状写起：第一段用现在时描述变更前的行为或缺口，不提 diff；读者读完这一段就应知道存在什么问题。
- 把机制作为论证来解释，而非编辑列表：采用“我们做 X 因为 Y；这成立是因为 Z”的写法，每个观点配一个具体证据（改变含义的那行代码、小表格、请求/响应、一个数字）。
- 首次出现时定义变更所依赖的那一个术语（如 pointer head、temperature、permutation flip rate 等），一句说明即可；不必定义所有内容，只定义读者评估本 PR 所需的部分。
- 写明变更所依赖的假设，例如“行是独立的，因此答案不会改变”“Score 选项是有序量表，因此不旋转”“temperature 在开发集上拟合，从不用于测试分区”。
- 说明不确定之处及何种结果可证伪，并在数字到来之前写下判定规则（哪个指标、哪个分区、哪个阈值）。
- 明确列出刻意不在本 PR 中的内容及其去向（后续 PR、PLAN 条目，或永不做）。范围说明清楚，评审范围才清晰。
- 数字须附来源：检查点、套件与分区、设备、样本量 n，以及已提交报告或运行目录的指针；裸写“提升准确率”无法在日后核验。
- 篇幅随新颖度而定：新的损失函数或服务路径值得分节（动机、机制、未纳入内容），一行修复只需一句理由；只有文本足够多时才用标题分节。
Kev 项目特有要求
- 标题即 squash commit subject，应写成一句变更说明，若有 PLAN 条目则一并带上，例如“benchmark --rotations: test-time cyclic option averaging for Choice (round 4.4)”，而非“Add rotations flag”。
- 在末尾保留 Test plan 清单，用于承载 kev-verify 的一致性证据（与 main 逐字节一致的 rows.json、权重支撑的套件、实测延迟）；写证据，而非“测试通过”。
- 若变更移动了已发布的数字，应指明 README 或模型卡将引用的文件。
- 禁止只有一个条目的脚手架式标题（如“## Changes”下只列文件名，那等于重复 diff）；禁止代替读者做判断的形容词（robust、comprehensive、clean，或无 CI 支撑的 significant）。
- 使用平实的技术英语，面向读者说话：项目决策用“we”，作者个人判断用“I”。
示例说明 资料以同一变更的两个版本作对比：弱版本逐行复述 diff，未说明为何旋转选项、为何用旋转而非随机打乱、为何对 logits 而非概率取平均、为何排除 Score、成本多少、何种结果才能使其成为服务选项；强版本则先说明模型存在位置习惯并以 permutation flip rate 度量，再解释旋转机制、为何旋转能使纯位置偏差精确抵消、为何平均 logits、哪些题型不适用、成本为每题 K 次前向，并给出 PLAN 中登记的判定门槛与冒烟检查点上的实测数字（如 4 次旋转下平均最大差 0.81 降至 0.38、翻转率 0.83 降至 0.50），最后附可复跑的 Test plan。小改动示例则展示一句问题、一句设界理由的写法。
提交前检查 资料给出五个自查问题：仅凭第一段，项目外的人能否说出变更前哪里不对；每个观点是否有一个具体证据；正确性所依赖的假设是否写下；判定规则是否先于结果写下；Test plan 是否包含评审者可重跑的证据；是否删掉了所有只重复 diff 的句子。
限制 资料未提供该技能的安装命令、代码实现、收费信息、支持平台或自动化校验方式，这些内容暂未提供。