用途
analyze-plan-feedback 用于对一份计划（plan）收集来自多个 AI 评审者的同行评审反馈，并进行分析与优先级排序。它面向需要整合多方评审意见、判断哪些反馈应优先处理的场景。
主要能力
- 解析参数：识别计划文件路径（可选）与评审者数量（可选，1-10，默认3）。
- 自动检测计划候选：若未提供计划路径，会并行检测本会话中最近创建、读取或讨论过的计划文件，检查 git diff 与 git log 中最近新增/修改的 docs/plans//*.md，并查找匹配 docs/plans//*.md 的计划文件或目录。
- 交互式选择：始终通过 AskUserQuestion 多选 UI 呈现最多4个检测到的候选，用户也可选择“Other”输入自定义路径；若未找到候选，仍会提供浏览 plans 目录或最近修改 .md 文件等选项。
- 逐个收集反馈：按评审者数量逐个要求粘贴反馈，支持直接粘贴文本或提供文件路径（若像路径则读取文件），全部收集完成后才进入分析。
- 技术评估：对每条反馈判断技术点是否有效准确、是否适用于当前技术栈与代码库、是否基于当前最佳实践，并在相关时与代码库模式交叉比对。
- 优先级分类：将每条独立反馈归入 Critical（阻塞发布：安全漏洞、数据丢失风险、功能损坏）、High（合并前应修复：性能问题、缺少错误处理、测试缺口）、Medium（尽快修复：代码质量、命名、文档、次要 UX 问题）、Low（锦上添花：风格偏好、理论改进、未来考虑）。
- 冲突解决：当评审者意见不一致时，清晰陈述各方立场，评估哪一方更适用于当前上下文，并给出带理由的建议。
- 行动项：生成带编号的具体可执行任务列表，每项引用反馈来源、有明确的完成定义，并按受影响的计划章节分组。
- 实施时间线：为每个行动项估算工作量（1 至 5）、跳过的风险以及依赖关系。
使用方式
命令示例：
- /analyze-plan-feedback docs/plans/my-plan.md → 3 个评审者
- /analyze-plan-feedback docs/plans/my-plan.md 2 → 2 个评审者
- /analyze-plan-feedback 2 → 自动检测计划，2 个评审者
- /analyze-plan-feedback → 自动检测计划，3 个评审者
流程为：解析参数 → 交互式收集反馈 → 分析 → 输出。输出格式包含：Feedback Summary（按 Critical、High Priority、Medium Priority、Low Priority / Deferred 分组，每项带工作量估算与来源）、Recommended Next Steps（按顺序）、Reviewer Agreement Matrix（表格：Topic、Reviewer 1 至 Reviewer N、Verdict）。呈现分析后，会询问用户是否要将任何反馈直接应用到计划中。
适用场景
适用于需要对计划进行多评审者反馈汇总、优先级排序与冲突裁决的协作或评审流程，尤其是计划文件位于 docs/plans/ 目录、使用 git 管理且需要结构化输出行动项与时间线的场景。
限制
- 评审者数量限制为 1-10，默认 3。
- 必须收集完所有 N 个评审者的反馈后才进行分析。
- 自动检测依赖会话记录、git 命令与 docs/plans/**/*.md 路径模式。
- 其他功能、收费、价格、平台、效果或使用步骤等事实暂未提供。