Workflow

1 — Scope

• Look for a plan in session memory at /memories/session/plan.md first.
• If no session plan exists, check for a plan file the user points to, or a plan visible in the conversation context.
• If there is nothing to review, ask the user to run the Plan agent first or point at a plan file.

2 — Fan Out

Launch 2–5 parallel subagents using the area prompts below. Each subagent works in isolation — do not share one area's findings with another before synthesis.

Each gets a self-contained prompt with its area, the plan location, and the return format. Subagents read the full plan from session memory themselves. Subagents may surface findings their area doesn't explicitly list — don't constrain them to only the listed focus items.

3 — Synthesize

When all subagents return:

1. Deduplicate findings that overlap across areas (e.g., a feasibility gap that also shows up as a sequencing problem).
2. Order by severity: missing requirements > incorrect assumptions > sequencing errors > scope issues > weak verification > minor risks.
3. Apply the signal filter — drop anything that wouldn't actually cause problems during implementation.
4. If no blocking issues survive, say so and note any areas where the plan could be strengthened.

4 — Save Findings

Always save the synthesized findings to session memory at /memories/session/plan-review.md. This makes them available for follow-up turns, plan revision, and cross-referencing during implementation.

5 — Revise or Report

• Review-only: if the user said "only review", "just review", or "read-only", stop after reporting.
• Default (review-and-revise):
  1. For each actionable finding, propose a specific revision to the plan — what to add, remove, reorder, or clarify.
  2. Apply revisions to the plan in session memory (/memories/session/plan.md), preserving the plan's existing structure.
  3. After revising, re-read the updated plan to confirm the revisions are coherent.
  4. Report what was revised and any remaining items that need the user's input or a decision.

Signal Filter

Before reporting a finding, ask: Does this change what a developer would actually do — or how likely the plan is to succeed? Ground every finding in something observable: a file that doesn't exist, an API that behaves differently, a requirement the steps don't cover, a sequence that creates rework.

…

council-review

调用多模型交叉审查代码变更、PR与高风险修改，辅助发现缺陷与争议点

review

用于代码与分支审查，综合检查正确性、兼容性、架构、测试、性能与安全问题。