proposal-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Proposal Review

提案审查

Methodically review proposals by chunking content, predicting feedback, and producing actionable output for the proposer.

通过拆分内容、预测反馈并为提案者生成可执行的输出，对提案进行系统化审查。

Workflow

工作流

┌─────────────────────────────────────────────────────────────┐
│  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. 接收：通读整个提案，识别来源格式                        │
├─────────────────────────────────────────────────────────────┤
│  2. 拆分：将内容拆分为可审查的模块（智能混合拆分法）        │
├─────────────────────────────────────────────────────────────┤
│  3. 审查循环：针对每个模块：                                │
│     • 展示模块内容                                         │
│     • 预测3-4种可能的反馈反应                              │
│     • 使用AskUserQuestion收集反馈                          │
│     • 记录反馈结果                                         │
├─────────────────────────────────────────────────────────────┤
│  4. 整合：汇总反馈，推断整体倾向                           │
├─────────────────────────────────────────────────────────────┤
│  5. 输出：生成与来源格式匹配的反馈文档                     │
└─────────────────────────────────────────────────────────────┘

Phase 1: Intake

第一阶段：接收

Read the entire proposal. Identify:

Source format: Local file, GitHub PR/issue/gist, Google Doc export, etc.
Structure: Headers, sections, numbered lists, or flowing prose
Length: Estimate chunk count (aim for 3-8 chunks for typical proposals)

Do not summarize or share initial impressions. Proceed directly to chunking.

通读整个提案，识别以下信息：

来源格式：本地文件、GitHub PR/议题/Gist、Google Doc导出文件等
结构：标题、章节、编号列表或连贯文本
长度：预估拆分模块数量（典型提案建议拆分为3-8个模块）

无需总结或分享初步印象，直接进入拆分环节。

Phase 2: Chunking Strategy

第二阶段：拆分策略

Use smart hybrid chunking:

Proposal Structure	Chunking Approach
Clear headers/sections	One chunk per major section
Large section (>500 words)	Split at natural paragraph breaks
Small adjacent sections (<100 words each)	Merge into single chunk
Numbered lists of items	Group 3-5 related items per chunk
Flowing prose without structure	Split at topic transitions (~300-400 words)

Chunk ordering: Present in document order unless there's a clear dependency (e.g., "Alternatives" before "Proposed Solution" if alternatives inform the solution review).

采用智能混合拆分法：

提案结构	拆分方法
清晰的标题/章节	每个主要章节作为一个模块
大章节（超过500词）	在自然段落分隔处拆分
小型相邻章节（每章少于100词）	合并为单个模块
编号列表项	每3-5个相关项分为一组模块
无结构的连贯文本	在主题转换处拆分（约300-400词）

模块排序：按文档顺序展示，除非存在明确的依赖关系（例如，若替代方案会影响方案审查，则先展示“替代方案”再展示“提议方案”）。

Phase 3: Review Loop

第三阶段：审查循环

For each chunk:

针对每个模块：

3.1 Present the Chunk

3.1 展示模块

Quote or summarize the chunk content. For longer chunks, quote key sentences and summarize the rest. Use a clear header like:

undefined

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

undefined

Chunk 2 of 5: Technical Architecture

第2/5模块：技术架构

undefined

undefined

3.2 Predict Reactions

3.2 预测反应

Generate 3-4 predicted reactions spanning these categories:

Category	Example Predictions
Clarification	"This is unclear—what does X mean?", "How does this interact with Y?"
Concern	"This scope seems too large", "Have you considered Z risk?"
Approval	"This approach makes sense", "Good tradeoff analysis"
Suggestion	"Consider alternative A", "This needs more detail on B"

Select predictions that feel most relevant to this specific chunk. Not every chunk needs all categories.

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

类别	预测示例
澄清疑问	“此处不明确——X指的是什么？”、“这与Y如何交互？”
担忧问题	“范围似乎过大”、“是否考虑过Z风险？”
认可支持	“这个方法合理”、“权衡分析做得很好”
改进建议	“考虑替代方案A”、“此处需要补充更多B的细节”

选择与当前模块最相关的预测反应，并非每个模块都需要覆盖所有类别。

3.3 Collect Feedback

3.3 收集反馈

Use AskUserQuestion with:

Predicted reactions as options (2-4 most likely)
User can select one OR provide custom feedback via "Other"
Keep option labels concise (under 10 words), use description for detail

Example:

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"

使用AskUserQuestion工具，需包含：

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

示例：

question: "你对这个技术架构章节的反应是什么？"
header: "架构"
options:
  - label: "看起来不错"
    description: "提议的架构合理且论证充分"
  - label: "范围担忧"
    description: "对于当前时间线来说，这个目标过于宏大"
  - label: "需要澄清"
    description: "部分技术细节不明确或缺失"
  - label: "考虑替代方案"
    description: "可能存在更简单或更好的方法"

3.4 Record Response

3.4 记录反馈

Store each response with:

Chunk identifier (number + title)
Selected option or custom text
Any quoted content the feedback references

存储每条反馈时需包含：

模块标识（编号+标题）
选中的选项或自定义文本
反馈涉及的任何引用内容

Phase 4: Synthesis

第四阶段：整合

After all chunks reviewed:

Group feedback by theme: Consolidate similar concerns across chunks
Infer overall sentiment: Based on feedback distribution:
- Mostly approvals → Positive with minor suggestions
- Mixed → Conditional support, needs revisions
- Mostly concerns → Significant issues to address
Identify patterns: Note if same concern appears multiple times

Then ask:

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"

完成所有模块审查后：

按主题分组反馈：汇总不同模块中类似的担忧
推断整体倾向：根据反馈分布情况：
- 多数为认可 → 整体积极，附带少量建议
- 正负混合 → 有条件支持，需要修订
- 多数为担忧 → 存在需解决的重大问题
识别规律：记录同一担忧是否多次出现

随后询问用户：

question: "是否需要为提案者添加建议的后续步骤？"
header: "后续步骤"
options:
  - label: "是，添加行动项"
    description: "根据反馈生成具体的后续步骤"
  - label: "否，仅保留反馈"
    description: "输出仅包含观察结果和反馈反应"

Phase 5: Output Generation

第五阶段：输出生成

Adapt output format to source:

Source	Output Format
GitHub PR	PR review comment with quoted lines and threaded feedback
GitHub Issue	Comment with sections matching issue structure
Markdown file	Companion `*-feedback.md` with inline references
Google Doc	Structured comment list with section references
Generic/unknown	Structured markdown with clear sections

根据来源格式调整输出格式：

来源	输出格式
GitHub PR	带引用行和线程化反馈的PR审查评论
GitHub 议题	与议题结构匹配的分段评论
Markdown文件	带内联引用的配套 `*-feedback.md` 文件
Google Doc	带章节引用的结构化评论列表
通用/未知格式	结构清晰的Markdown文档

Output Structure

输出结构

markdown

undefined

markdown

undefined

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]

[主题1]：[汇总的反馈内容]
[主题2]：...

Next Steps (if requested)

后续步骤（若用户要求）

[Action item 1]
[Action item 2]

undefined

[行动项1]
[行动项2]

undefined

Tone Guidelines

语气指南

Direct but constructive
Quote specific text when critiquing
Frame concerns as questions when possible ("Have you considered..." vs "This won't work")
Acknowledge what works, not just what doesn't

直接但具建设性
批评时引用具体文本
尽可能将担忧转化为问题（例如用“是否考虑过……”替代“这行不通”）
既要指出问题，也要认可合理之处

Edge Cases

边缘情况

Very short proposals (<300 words): Skip chunking, review as single unit with 4-5 predicted reactions.

Very long proposals (>3000 words): Cap at 8-10 chunks. Merge aggressively or offer to focus on specific sections.

Unclear structure: Ask user which sections matter most before chunking.

Multiple proposals: Review one at a time. Ask user for order preference if not obvious.

极短提案（少于300词）：跳过拆分环节，将整个提案作为单个单元审查，生成4-5种预测反应。

极长提案（超过3000词）：最多拆分为8-10个模块。可大幅合并内容，或询问用户是否专注于特定章节。

结构不清晰的提案：拆分前先询问用户哪些章节最重要。

多个提案：一次审查一个。若顺序不明确，询问用户的优先顺序。