Review Research Plan

If the user explicitly names a command (e.g., "/full-review"), use it directly. Otherwise, assess maturity first and route accordingly.

Context Detection (Run Alongside Maturity)

If the user provides a codebase path, paper directory, or documentation links, note them:

Context: Codebase at [path], papers at [path] Technical claims will be grounded against code and literature where possible.

This context is used during adversarial review — technical claims about existing systems should be verified against actual implementations, not assessed through reasoning alone. If no external context is provided, the review proceeds as pure plan analysis.

Maturity Detection (Always Run First)

Before routing to a command, quickly assess the plan's maturity. This takes ~30 seconds of reading — do not load any reference files for this step.

Scan the plan for four signals:

1. Structural completeness — Does it have: problem statement, approach, evaluation plan, related work, timeline? Count how many are present and substantive.
2. Claim specificity — Are contributions vague ("use diffusion for X") or precise ("inject identity embeddings at cross-attention layers with contrastive loss")?
3. Empirical grounding — Any preliminary results, pilot experiments, or proof-of-concept?
4. Risk awareness — Does it mention limitations, failure modes, or alternatives?

Classify:

State the detected level in your first line of output so the user can override:

Maturity: Mid-stage — routing to full-review (balanced). Say "switch to quick/aggressive" to override.

Severity Definitions (Used Across All Commands)

• 🔴 FATAL — Direction needs reconsideration (e.g., core novelty already published)
• 🟠 SERIOUS — Reviewer would likely reject if unaddressed
• 🟡 CONCERN — Worth noting, won't determine acceptance alone

Key Principles (Apply to All Commands)

1. Every critique must come with at least one path forward.
2. Match the language of the input plan (Chinese plan → Chinese review).
3. Do not manufacture problems when the plan is strong — say so and move on.
4. Flag your own uncertainty honestly rather than asserting false confidence.
5. When the user pushes back with valid arguments, downgrade or close the finding.