用途
drive-code-review 是一个面向本地 PR / 分支审查的技能（skill），用于为当前分支与其基线分支生成一套可落盘的审查产物。其核心前提是：代码审查必须锚定在“期望”之上，而期望来自显式的意图来源（PR 描述、关联工单、设计文档）以及一份规范文件（canonical spec）——若分支内已有作者提供的规范文件则使用之，否则由审查方推断并写出一份 review 用的 spec.md，使期望显式化、可审查。
该技能明确约束：不修改实现代码，只写审查产物。
主要能力与产物
每次运行都必须在同一个产物目录下并排产出以下文件：
- system-design-review.md（架构师视角的阶段产物）
- code-review.md（首席工程师视角的阶段产物）
- walkthrough.md（技术负责人视角的阶段产物）
spec.md 仅在分支内不存在规范文件时才写出。若已存在规范文件，则不在审查产物中重复，改为引用它。
使用方式
-
确定审查范围：默认审查当前分支，基线为 PR 的 base 分支，否则为仓库默认分支（通常为 main）。若用户显式指定基线分支，则严格按该分支确定审查范围，不用 origin/HEAD 或 origin/main 替换。证据采集包括 git log、变更文件列表、完整 diff 以及 PR 信息（gh pr view / gh pr list）。
-
建立期望来源：优先使用显式意图来源，包括规范文件、用户提供或 PR 链接的外部规范、PR 标题/描述、Linear 工单、分支内新增文档；diff 本身仅作为最后手段。若分支内无规范文件，则推断并写出 review 用的 spec.md，需在开头显著声明作者身份与推断来源，并列出意图、功能需求、非目标、约束/不变量、验收标准、风险等，模糊处记为显式假设或开放问题。
-
确定产物目录规则：若分支内存在规范文件，写到其所在目录下的 reviews/pr-<PR号>/ 或 reviews/；否则写到 wip/review-code/pr-<PR号>/ 或 wip/review-code/branch-<分支名>/。
-
依次执行三个角色阶段（架构师、首席工程师、技术负责人），每个阶段为独立的角色加载，分别产出对应文件。
各阶段要点
-
系统设计阶段：关注所解决的问题、新增的保证/不变量、子系统契合、边界正确性、命名与类型学完整性、ADR 评审、架构层面的测试策略充分性。对识别出的限定前缀、消费者编码命名、以机制命名的概念进行探查。
-
代码审查阶段：关注失败模式、可操作性与影响范围、成本与复杂度、约束与假设。要求先读仓库约定（至少 AGENTS.md 及相关 .cursor/rules、README）。产物需包含摘要、值得肯定之处、发现列表、延后项（需说明属于范围外）、已解决项、验收标准验证。发现项按唯一 ID（如 F01）编号，按安全 > 正确性 > 性能 > 可维护性 > 风格排序，不使用 blocking/non-blocking/nits 分级。是否延后仅以“范围”为理由。
-
验收标准验证：若规范含验收标准，则逐条对照实际实现验证，要求读实现代码与测试断言，给出 PASS / FAIL / NOT VERIFIED / WEAK 判定，并避免“只做映射不验证”等常见陷阱。
适用场景与限制
适用于本地分支或 PR 的代码审查与系统设计审查。限制包括：不修改实现代码；审查产物默认落盘；子代理需具备写权限以直接落盘产物（通过 Task 工具委派时不应设置 readonly: true）；若因预算失败，可收紧提示或由编排者在会话内联执行。若反复失败，建议收紧提示复用已完成产物或改为内联执行。
暂未提供
该技能的具体收费、价格、平台支持范围、安装命令、运行所需的具体模型或工具版本等信息，资料中暂未提供。