Plan Mode Review Checklist

A structured prompt for reviewing plans before making code changes. For every issue, explain concrete tradeoffs, give an opinionated recommendation, and ask for input before assuming a direction. Source: AGENTS.md (Downloads/Dedalus)

Engineering Preferences

• DRY is important -- flag repetition aggressively.
• Well-tested code is non-negotiable; too many tests is better than too few.
• Code should be "engineered enough" -- not under-engineered (fragile, hacky) and not over-engineered (premature abstraction, unnecessary complexity).
• Err on the side of handling more edge cases, not fewer; thoughtfulness over speed.
• Bias toward explicit over clever.

Pre-Review: Code Review Graph

Before starting any review, ensure Code Review Graph is built and current. Use get_review_context_tool to get the token-optimized structural context and detect_changes_tool to see risk-scored change impact. This narrows the review to only affected files and their blast radius.

Four Review Sections

1. Architecture Review

Evaluate: overall system design and component boundaries, dependency graph and coupling, data flow patterns and bottlenecks, scaling characteristics and single points of failure, security architecture (auth, data access, API boundaries).

2. Code Quality Review

Evaluate: code organization and module structure, DRY violations (be aggressive), error handling patterns and missing edge cases (call out explicitly), technical debt hotspots, areas over-engineered or under-engineered relative to the preferences above.

3. Test Review

Evaluate: test coverage gaps (unit, integration, e2e), test quality and assertion strength, missing edge case coverage (be thorough), untested failure modes and error paths.

4. Performance Review

Evaluate: N+1 queries and database access patterns, memory-usage concerns, caching opportunities, slow or high-complexity code paths.

Issue Resolution Protocol

For every specific issue (bug, smell, design concern, risk):

1. Describe the problem concretely with file and line references
2. Present 2-3 options, including "do nothing" where reasonable
3. For each option specify: implementation effort, risk, impact on other code, maintenance burden
4. Give recommended option and why, mapped to the engineering preferences above
5. Explicitly ask whether to agree or choose a different direction before proceeding

Workflow

Before starting, offer two modes:

BIG CHANGE: Work through interactively, one section at a time (Architecture -> Code Quality -> Tests -> Performance) with at most 4 top issues per section.

SMALL CHANGE: Work through one question per review section.

For each stage: output explanation and pros/cons, give an opinionated recommendation, number issues, letter options, and make the recommended option always the first choice. Pause after each section for feedback before moving on.

Review Traps

Display vs spend queries

When a view reads a balance or quota, identify which question is being answered:

• "How much can this user spend right now?" -- call the spend-gate RPC (e.g. billing.get_total_available). Fail-closed on un-mirrored grants or pending holds.
• "What is actually on this user's account?" -- read the source table (e.g. billing.credit_grants). Do not use the spend-gate.

Using the spend-gate on a display surface silently hides pending credits and makes the user think their claim failed. Using a raw table read on the spend path lets them overspend against un-provisioned balance. Wrong direction on either side is a bug. See Billing Ledgers.

Concept Position

---

Timeline

• 2026-07-01 | Concepts category refresh added this page to the Agent harness and runtime primitives family, linked it to Concept System Map, and kept it standalone because it owns this reusable mental model: A structured prompt for reviewing plans before making code changes. For every issue, explain concrete tradeoffs, give an opinionated recomm... Source: User request, 2026-07-01