用途：对提案（技术设计、产品规格、功能需求等）进行有条理的评审，帮助评审人给出结构化反馈。触发场景包括被要求“review this proposal”“give feedback on…”等。
主要能力与流程：
- 接收（Intake）：通读整份提案，识别来源格式（本地文件、GitHub PR/issue/gist、Google Doc 导出等）、结构（标题、章节、编号列表或散文）和长度，估算分块数量（典型提案 3-8 块）。
- 分块（Chunking）：采用智能混合策略——有清晰标题则每主要章节一块；单块超 500 词按自然段拆分；相邻小章节（各小于 100 词）合并；编号列表每 3-5 项一组；无结构散文按主题转换处（约 300-400 词）切分。除明确依赖关系外按文档顺序呈现。
- 评审循环：逐块呈现内容（长块引用关键句并概述其余），预测 3-4 条可能反应，覆盖澄清、担忧、赞同、建议四类；通过 AskUserQuestion 让用户选择预测项或自定义反馈，并记录块标识、选项或自定义文本及所引用内容。
- 综合：按主题归并跨块反馈，推断整体态度（多为赞同→正面含小建议；混合→有条件支持需修订；多为担忧→存在需解决的重大问题），识别重复出现的模式；随后询问是否加入给提案人的后续步骤。
- 输出：按来源适配格式——GitHub PR 用带引用行的评审评论；GitHub Issue 用与问题结构匹配的评论；Markdown 文件生成配套 *-feedback.md 并内联引用；Google Doc 用带章节引用的结构化评论列表；未知来源输出结构化 Markdown。输出结构含总体判断、逐节反馈、关键主题及（如请求）后续行动项。
语气规范：直接但建设性；批评时引用具体文字；尽量以问句表达担忧；同时肯定有效之处。
边界情况：低于 300 词的短提案不分块，整体评审并给 4-5 条预测反应；超过 3000 词的长提案上限 8-10 块，可积极合并或提出聚焦特定章节；结构不清时先询问哪些章节最重要；多份提案逐个评审，顺序不明时询问用户偏好。
限制：资料未提供具体安装命令、依赖环境、收费与平台支持信息，暂未提供。