用途
PR 质量检查清单技能是一份用于创建高质量 Pull Request 的综合指南，目标是让 PR 易于审查、文档完善并符合团队标准。它包含模板、大小指南，以及面向作者和审查者的最佳实践。
适用时机：
- 创建任何 Pull Request 之前
- 审查他人的 PR 时
- 建立团队 PR 标准时
- 新成员入职期间
- PR 审查耗时过长时
主要能力
快速检查清单（创建 PR 前）
- PR 标题遵循约定：type(scope): description
- 描述包含摘要、相关工单和测试计划
- 变更聚焦且相关（单一关注点）
- 代码已自查明显问题
- 测试已添加/更新并通过
- 无调试代码（console.log、debugger 等）
- TypeScript/类型错误已解决
- 必要时更新文档
- UI 变更包含截图
- 添加 changeset（面向用户的变更）
PR 标题格式
约定：{type}({scope}): {short description}
类型包括：feat（新功能）、fix（缺陷修复）、refactor（既不修复缺陷也不新增功能的代码变更）、docs（仅文档）、style（格式、缺失分号等，无代码变更）、test（添加或更新测试）、chore（维护任务、依赖更新）、perf（性能改进）、ci（CI/CD 变更）。
示例：feat(auth): add OAuth2 login support；fix(cart): resolve race condition in checkout；refactor(search): extract query param parsing logic；docs(api): update authentication examples；test(payment): add integration tests for Stripe；chore(deps): update Next.js to v15；perf(images): implement lazy loading for gallery；ci(deploy): add staging environment workflow。
Scope 指南：使用组件/模块名（auth、cart、search、api）；具体但不过于细碎（用 user-profile 而非 user-profile-settings-modal）；与代码库结构保持一致。
PR 描述模板
标准模板包含以下部分：Summary（1-3 条要点描述变更）、Related Tickets（关联 Linear/Jira/GitHub 工单）、Changes（Added/Modified/Removed 详细列表）、Screenshots（UI 变更必需，含桌面、移动端、Before/After 对比）、Testing（测试方式清单）、Breaking Changes（如有破坏性变更，含前后代码对比与迁移说明）、Checklist（代码风格、自查、注释、文档、changeset、无调试语句、无 TypeScript 错误、测试通过、构建成功）。
另提供最小模板（用于小改动）：Summary、Changes、Testing。
大小指南
理想 PR 大小：变更行数 < 300（不含生成文件）、变更文件 < 15、审查时间 < 30 分钟、提交 1-5 个逻辑提交。
大小分类：
- XS：< 50 行，1-3 文件，5 分钟，适合热修复
- S：50-150 行，3-8 文件，15 分钟，良好大小
- M：150-300 行，8-15 文件，30 分钟，考虑拆分
- L：300-500 行，15-25 文件，1 小时，应当拆分
- XL：500+ 行，25+ 文件，2+ 小时，必须拆分
拆分 PR 的方式：按功能阶段、按层次（数据库/后端/前端/测试文档）、按关注点（重构/新功能/测试）、按风险级别。
大小限制的例外：生成代码（迁移、API 客户端、类型）、重命名/移动文件（用 git mv 展示）、批量格式化变更（单独 PR、预先批准）、第三方库集成（文档完善）、重构 PR。
重构模板
包含 Summary（重构目标：不改变行为的前提下提升可维护性）、Motivation（减少重复、提升类型安全、移除死代码）、Related Tickets、Stats（增删行数、净变化、文件数）、Changes（Removed 死代码、Refactored 重构项、No Behavior Changes 确认）、Testing、Review Focus。
重构最佳实践：将重构与功能分离（绝不混合）；验证零行为变更（测试不应需要更新）；记录移除的代码（说明为何可安全移除）；彻底搜索（用 rg/grep 验证无使用）；庆祝负 LOC（突出代码减少）。
审查清单
面向作者（自查）：
- 代码质量：DRY、函数单一职责、变量命名清晰、无魔法数字、错误处理全面、边界情况已处理
- 测试：覆盖新功能、测试有意义、边界与错误条件已测、无脆弱测试
- 文档：复杂逻辑有注释、公共 API 有 JSDoc/docstrings、README 更新、迁移指南
- 性能：无明显性能问题、数据库查询高效、无 N+1 查询、大数据集处理得当
- 安全：无硬编码密钥、输入验证、授权检查、无 SQL 注入、敏感数据不记录日志
面向审查者：
- 第一遍（5 分钟）：PR 描述清晰、变更与目标一致、大小合理（< 300 LOC 优先）、无明显红旗
- 代码审查（15-30 分钟）：逻辑正确、边界处理、错误处理、可读可维护、无性能问题、安全考虑
- 测试审查：测试覆盖变更、测试有意义、无脆弱测试、边界已测
- 文档审查：PR 描述与变更匹配、注释解释"为什么"而非"什么"、破坏性变更已记录、迁移指南
批准标准：✅ Approve（代码良好，仅小问题）；💬 Comment（建议但非阻塞）；🔄 Request Changes（合并前必须修复）。
常见错误
- 模糊的 PR 标题（如 "Fix bug"、"Updates"、"WIP"）
- 缺少上下文（未说明原因、影响）
- 过大（2000 行、50 文件）
- 混合关注点（功能+依赖+重构+修复+格式化）
- UI 变更无截图
- 测试说明不完整（仅 "本地测试过"）
- 遗留调试代码（console.log、debugger、TODO、未使用导入）
- 面向用户变更无 changeset
红旗警示
- 无描述或 "WIP" 标题
- 变更超过 500 LOC
- 混合关注点
- 无测试或仅修改测试
- "相信我，它能工作"
- console.log/debugger 语句
- 忽略 TypeScript 错误
- UI 变更无截图
使用方式
该技能以清单和模板形式提供，可在创建 PR 前逐项对照检查，也可在审查他人 PR 时作为参考标准。技能内容本身即为可直接套用的模板与指南，无需额外安装步骤（资料未提供具体安装命令）。
适用场景
适用于任何使用 Pull Request 工作流的软件开发团队，尤其适合需要统一 PR 标准、提升审查效率、规范重构流程、加速新人入职的场景。
限制
资料未提供该技能的具体安装方式、平台依赖、收费信息或与其他工具的集成细节。