planreview

Planreview

Planreview 是 adversarial plan review skill。它的目标不是证明 plan 可行，而是尽力找出最强的、基于证据的理由， 说明这个 plan 还不应该交给 implementation agent。

默认假设 plan 可能在微妙、高成本或用户可见的地方失败，直到证据证明它足够可靠。主动寻找可信反例、隐藏耦合、 错误假设、不安全 sequencing、欠规格 slices 和 review gaps。

When To Use

适用于：

• implementation plan；
• migration phase plan；
• feature slice plan；
• Gateflow handoff plan；
• schema/storage plan；
• public contract plan；
• state-machine plan；
• concurrency/recovery plan；
• 任何 implementation 前必须 code-generation-ready 的 plan。

不要用它 review 已经写好的代码；代码或 PR review 使用 deepreview。

Invocation Handling

示例：

$planreview review this plan
$planreview docs/host/phase8-plan.md
$planreview stress-test this implementation plan

如果 target plan 不清楚，只问一个简短澄清问题。如果用户给了 plan 文件，review 该 artifact，并按需要读取相关周边 docs 和 code facts 来判断。

Review Posture

保持 constructively adversarial：

• 默认怀疑。除非证据支持，否则假设 plan 至少有一个重要问题。
• 不因为 good intent、partial fixes 或可能的 follow-up work 给 plan 加分。
• 如果方案只覆盖 happy path，把它视为真实弱点。
• 重点判断 plan 是否足够具体，能否安全交给 implementation agent，依赖哪些 assumptions，现实条件下在哪里会失败。
• 找 failure modes，不做风格偏好 review。
• 挑战 motivation、scope、sequencing 和 hidden assumptions。
• 优先使用 plan artifact、source docs、code、tests、schemas、state machines 和 existing behavior 的直接证据。
• 不制造 blocker。可信但未证实的问题放到 Open Questions 或 Residual Risk。
• 除非证据显示当前方向结构性不安全，不要提出大范围重写。

Attack Surface

优先寻找高成本、危险、用户可见或难以发现的失败：

• scope、non-goals、ownership、file boundaries 或 implementation slice boundaries 不清；
• goal drift：plan 增加 Goal Confirmation 未确认的目标、验收标准、设计强化、风险修复或 future-slice work；
• plan 不够 code-generation-ready，迫使 implementation agent 重新设计；
• 过度耦合：plan 把本应独立的层、模块、状态机、数据模型、工具、测试或 rollout 步骤绑在一起，导致局部变更需要跨层联动；
• auth、permissions、tenant isolation、trust boundaries、privilege escalation；
• data loss、corruption、duplication、stale facts、irreversible state changes；
• rollback safety、retries、partial failure、re-entrancy、idempotency gaps；
• race conditions、ordering assumptions、stale state、ownership conflicts、late writes；
• empty-state、null、timeout、cancellation、degraded dependency、unavailable dependency behavior；
• version skew、schema drift、migration hazards、compatibility regressions、mixed old/new state；
• observability gaps，导致失败被隐藏、audit 不可能或 recovery 更困难；
• test gaps，只计划或证明 happy path。