用途：为规划文档、架构决策记录、设计规格等需要被多方引用的文档提供独立评审与闭环讨论，避免作者自审看不到盲点、一次性评审无法追踪问题是否真正解决。
主要能力：以持久化讨论线程记录全过程，每个阶段追加带时间戳的条目，不覆盖历史。评审者对每份文档按 1–5 分打分，4/5 为门槛：≥4 输出 APPROVED，<4 输出 NEEDS_WORK，流程据此决定是否循环。标准流水线为 critic → dev-response（最多 3 轮）→ arbitrator（僵局时）→ final-gate → reviser（SHIP 时）。仲裁者对每个未决点给出 OVERRULE CRITIC、UPHOLD CRITIC 或 THIRD PATH。final-gate 输出 SHIP 或 HOLD，HOLD 需给出具体阻塞项。
大文档流水线：当文档含 3 个以上自然章节或超过约 500 行时，改用 chunker → 并行 critic/dev 对 → aggregator → final-gate → reviser。chunker 按阶段、模块、章节切分并写上下文信封（已确定内容、后续内容、本块范围），aggregator 检查跨块矛盾、孤立依赖、范围重叠与顺序违规。若误用于小文档，chunker 应回退到标准流水线。
使用方式：将 critic-lens.md、dev-respond.md、planner-arbitrate.md、final-gate.md 等提示文件放入项目 .kiro/prompts/，并按资料中的 stages 配置子代理阶段与 loop_to 触发条件。讨论线程存放于 docs/planning/discussions/{topic}.md，大文档存放于 {topic}/chunks/ 下。入口有两种：由 planner 代理写文档后自动启动，或对已有文档说“Pass docs/planning/intake-design.md to the critic”。
适用场景：会约束实现工作的规划文档、将被引用的架构决策、多组件共同遵循的规格。不适用：快速参考笔记、开发日志、尚未到决策阶段的工作文档、评审成本高于风险的单文件改动。
限制：资料未提供具体模型可用性、收费、价格或效果保证；仲裁者不是第二评审者，目标是可用方案而非完美方案；reviser 在写文件前先向人展示变更摘要，且范围锁定在已达成一致的内容。