用途：对提案（技术设计、产品规格、功能需求等）进行有条理的评审，将内容分块、预测可能的反馈，并为提案者生成可操作的输出。
主要能力与流程：
- 受理：通读整个提案，识别来源格式（本地文件、GitHub PR/issue/gist、Google Doc 导出等）、结构与长度，不先做总结或分享初步印象。
- 分块：采用智能混合分块——有清晰标题/小节时每个主要小节一块；超过500词的大节按自然段落拆分；相邻且各不足100词的小节合并；编号列表按3-5个相关项一组；无结构的散文按主题转换点约300-400词拆分。除明确依赖关系外，按文档顺序呈现。
- 评审循环：对每块展示内容（较长块引用关键句并概括其余），生成3-4条预测反应（澄清、担忧、认可、建议等类别），通过AskUserQuestion收集反馈，用户可选预设项或通过“Other”提供自定义反馈，随后记录块标识、所选选项或自定义文本及被引用的内容。
- 综合：按主题归并反馈，推断整体情绪（多为认可→正面但有小建议；混合→有条件支持需修改；多为担忧→存在需处理的重大问题），识别重复出现的模式，并询问是否加入给提案者的后续步骤。
- 输出：按来源适配格式——GitHub PR 用带引用行和线程化反馈的评审评论；GitHub Issue 用与 issue 结构匹配的评论；Markdown 文件生成伴生的 *-feedback.md 并带行内引用；Google Doc 用带小节引用的结构化评论列表；来源未知时用结构化 markdown。输出结构包含反馈摘要、逐节反馈、关键主题，以及（如请求）后续步骤。
语气准则：直接但有建设性，批评时引用具体文本，尽量把担忧表述为问题，既指出优点也指出不足。
限制与边界情况：不足300词的短提案跳过分块，作为整体评审并给出4-5条预测反应；超过3000词的长提案上限8-10块，可积极合并或提出聚焦特定小节；结构不清时先询问用户哪些小节最重要；多份提案一次评审一份，顺序不明显时询问偏好。
其他事实（如安装命令、收费、平台支持等）暂未提供。