2026-10-13 16:40:07 +08:00
|
|
|
---
|
|
|
|
|
name: junior-to-senior
|
|
|
|
|
description: >
|
2026-10-30 12:40:16 +08:00
|
|
|
Review and improve a proposed plan or architecture when asked for a senior review, a staff-engineer review, or review of the plan.
|
|
|
|
|
scope: global
|
2026-10-13 16:40:07 +08:00
|
|
|
---
|
|
|
|
|
|
2026-10-30 12:40:16 +08:00
|
|
|
# Plan review
|
2026-10-13 16:40:07 +08:00
|
|
|
|
2026-10-30 12:40:16 +08:00
|
|
|
1. Identify the plan and its intended outcome. Inspect the relevant code, callers,
|
|
|
|
|
dependency versions, and prior decisions. Cite file/line evidence for code claims.
|
|
|
|
|
2. Find consequential gaps: vague goals, unstated contracts, unowned failure cases,
|
|
|
|
|
scope mismatch, migration risk, or detail concentrated on easy parts.
|
|
|
|
|
3. Verify load-bearing external assumptions against primary sources for the installed
|
|
|
|
|
versions. Research only what can change a material decision; unavailable evidence
|
|
|
|
|
stays unverified rather than becoming a blocker.
|
|
|
|
|
4. Classify demonstrated defects, material improvements, and optional polish.
|
|
|
|
|
Do not invent findings to look adversarial or copy the whole plan into the response.
|
|
|
|
|
5. Provide concrete remedies. Rewrite the plan when requested or when a short revision
|
|
|
|
|
makes the recommendations actionable; preserve sound choices and user intent.
|
2026-10-13 16:40:07 +08:00
|
|
|
|
2026-10-30 12:40:16 +08:00
|
|
|
Use the [research playbook](references/research-playbook.md) and
|
|
|
|
|
[rubric](references/review-rubric.md) only for relevant questions. A review can be
|
|
|
|
|
brief when the plan is sound. Do not force this workflow onto a direct implementation
|
|
|
|
|
request; focused risk inspection can be part of implementing it. Follow
|
|
|
|
|
[shared workflow](../../protocols/workflow.md).
|
