← ClaudeAtlas

plan-reviewlisted

A plan, design doc, spec, RFC, or ADR to review before anything is built from it — read from the requirements first, the way a senior architect would. Use when the user asks for that review, says "審一下這份計畫", "is this over-engineered", "does this match the requirements", "is this spec precise enough to build from" — and on your own plans before handing them over.
millerlai/claude-all-in-one · ★ 0 · Code & Development · score 59
Install: claude install-skill millerlai/claude-all-in-one
> `<cai>` is the cai-codex command line that `$setup` wrote into your instructions (the cai-codex block in AGENTS.md). `<cai-root>` is what `<cai> --root` prints. # plan-review — read the plan the way a senior architect would The expensive mistake in a plan is rarely a wrong detail. It is building something the requirements never asked for, and discovering the requirement it actually missed after the code exists. So this review runs in one direction first: **from the requirements**. Anything the requirements don't reach is not automatically wrong — but it is a decision someone made silently, and silent decisions are what this skill exists to surface. Review your own plans with it too, before handing them over. That is the harder case and the more valuable one. ## Step 0 — Is it reviewable? Two things must be present. Nothing else gates the review: 1. **The requirement** — what problem this solves, for whom. 2. **The acceptance criteria** — how anyone will know it worked. Missing either one, stop. Say which is missing and ask for it, or offer the matching skeleton at the bottom of this file. Reviewing a plan with no stated requirement means inventing the requirement yourself — and every finding after that is your opinion wearing a suit. Everything else being thin (no diagrams, no file list, rough steps) is a finding, not a blocker. ## Step 1 — Trace it both ways Build the table before forming any opinion. Read the plan and the code it touches; a traceability claim