proposal-review

提案审查

通过划分内容块、预测反馈并为提案者提供可执行的建议，系统地审查提案。

工作流

┌─────────────────────────────────────────────────────────────┐
│  1. INTAKE: Read entire proposal, identify source format    │
├─────────────────────────────────────────────────────────────┤
│  2. CHUNK: Split into reviewable sections (smart hybrid)    │
├─────────────────────────────────────────────────────────────┤
│  3. REVIEW LOOP: For each chunk:                            │
│     • Present chunk content                                 │
│     • Predict 3-4 likely reactions                          │
│     • Use AskUserQuestion for feedback                      │
│     • Record response                                       │
├─────────────────────────────────────────────────────────────┤
│  4. SYNTHESIZE: Compile feedback, infer overall sentiment   │
├─────────────────────────────────────────────────────────────┤
│  5. OUTPUT: Generate feedback document matching source      │
└─────────────────────────────────────────────────────────────┘

阶段 1：接收

阅读完整提案。识别：

• 来源格式：本地文件、GitHub PR/issue/gist、Google 文档导出文件等
• 结构：标题、章节、编号列表或连续行文
• 长度：估算内容块数量（典型提案以 3-8 个内容块为宜）

不要总结或分享初步印象。直接进入内容分块。

阶段 2：分块策略

使用智能混合分块：

提案结构	分块方式
标题/章节清晰	每个主要章节作为一个内容块
较大的章节（>500 个单词）	在自然段落边界处分割
相邻的较小章节（每个 <100 个单词）	合并为一个内容块
编号条目列表	每个内容块归为 3-5 个相关条目
没有结构的连续行文	在主题转换处拆分（约 300-400 个单词）

内容块顺序：按照文档顺序呈现，除非存在明显的依赖关系（例如，若“备选方案”会影响对提案方案的审查，则将其放在“提案方案”之前）。

阶段 3：审查循环

对每个内容块：

3.1 呈现内容块

引用或概述内容块。对于较长的内容块，引用关键句并概述其余内容。使用清晰的标题，例如：

### Chunk 2 of 5: Technical Architecture

3.2 预测反馈

生成 3-4 条预测反馈，涵盖以下类别：

类别	预测示例
澄清	“这里不清楚——X 是什么意思？”，“这会如何与 Y 交互？”
顾虑	“这个范围似乎太大了”，“你考虑过 Z 风险吗？”
认可	“这个方案很合理”，“权衡分析做得不错”
建议	“可以考虑备选方案 A”，“这里需要补充关于 B 的细节”

选择与当前内容块最相关的预测反馈。并非每个内容块都需要涵盖所有类别。

3.3 收集反馈

使用 AskUserQuestion，并遵循以下要求：

• 将预测反馈作为选项（最可能的 2-4 项）
• 用户可以选择一项，或通过“其他”提供自定义反馈
• 选项标签应简洁（少于 10 个单词），详细信息放在描述中

示例：

question: "What's your reaction to this technical architecture section?"
header: "Architecture"
options:
  - label: "Looks good"
    description: "The proposed architecture is sound and well-reasoned"
  - label: "Scope concern"
    description: "This feels too ambitious for the timeline"
  - label: "Need clarification"
    description: "Some technical details are unclear or missing"
  - label: "Consider alternative"
    description: "There may be a simpler or better approach"

3.4 记录回复

记录每条回复，包括：

• 内容块标识符（编号 + 标题）
• 所选选项或自定义文本
• 反馈所引用的任何内容

阶段 4：综合整理

审查完所有内容块后：

1. 按主题归纳反馈：汇总不同内容块中的相似顾虑
2. 判断整体态度：根据反馈分布判断：
   • 认可为主 → 整体积极，仅有少量建议
   • 反馈不一 → 有条件支持，需要修改
   • 顾虑为主 → 存在需要解决的重大问题
3. 识别模式：指出是否有相同顾虑多次出现

然后询问：

question: "Would you like me to include suggested next steps for the proposer?"
header: "Next Steps"
options:
  - label: "Yes, include action items"
    description: "Generate concrete next steps based on feedback"
  - label: "No, just the feedback"
    description: "Keep output to observations and reactions only"

阶段 5：生成输出

根据来源调整输出格式：

来源	输出格式
GitHub PR	PR 审查评论，包含引用的行和线程式反馈
GitHub Issue	评论，包含与 issue 结构对应的章节
Markdown 文件	配套的 *-feedback.md，包含行内引用
Google 文档	结构化评论列表，包含章节引用
通用/未知	结构清晰的 Markdown，包含明确的章节

输出结构

## Feedback Summary

**Overall**: [Inferred sentiment - 1 sentence]

## Section-by-Section Feedback

### [Section Name]
[Feedback with quotes where relevant]

### [Section Name]
...

## Key Themes
- [Theme 1]: [Consolidated feedback]
- [Theme 2]: ...

## Next Steps (if requested)
- [ ] [Action item 1]
- [ ] [Action item 2]

语气指南

• 直接但有建设性
• 提出批评时引用具体文本
• 尽可能将顾虑表述为问题（“你考虑过……吗？”而不是“这行不通”）
• 肯定有效之处，而不只指出问题

特殊情况

非常短的提案（<300 个单词）：跳过分块，将其作为一个整体审查，并预测 4-5 条反馈。

非常长的提案（>3000 个单词）：将内容块数量限制为 8-10 个。积极合并内容块，或提议重点审查特定章节。

结构不清晰：分块前询问用户最关注哪些章节。

多个提案：一次审查一个。如果顺序不明显，询问用户希望按什么顺序审查。