用途：在做出重大变更前，先进行一次结构化、协作式的实施前讨论，帮助评估拟议改动是否合适。
主要能力与原则：核心规则是在用户明确确认最终方案并说继续之前，不实施任何东西，包括“先在分支上试试”。讨论期间回复保持简短、聚焦当前问题，不在每条回复中重复完整计划；方案成熟后，再给出一次简洁的完整总结供最终审阅。遇到不确定的项目背景、约束或偏好要提问，而非假设；并鼓励质疑前提，提出更简单的替代方案。
使用方式按步骤进行：先理解现状，阅读相关配置、代码和文档，了解项目结构、已发布与私有部分、目标环境和既有约束，梳理受影响文件与系统，估算实施成本，此步不可跳过也不能靠假设；再彻底调研，查阅官方文档、变更日志、迁移指南和 issue，每个结论要有证据，不确定就说明，可并行批量查询以避免版本约束、路线图与实际发布状态混淆等陷阱；随后简要呈现发现，可用表格突出阻碍与未知项；接着列出需要用户决策的关键点，每项给出最多2—3个选项、各自代价、一句话倾向；之后进入迭代，按需调研、只回答被问的问题、根据反馈更新判断；讨论收敛后一次性给出完整计划，包含改动清单、影响面与工作量、明确不改变的范围、风险与待验证项，保持简洁、多用表格；最后停下等待确认，用户确认后才进入实施，用户追问则回到迭代，用户修改范围则更新计划再呈现。
适用场景：需要评估跨文件、跨包或跨系统的改动，或在实施前厘清版本兼容、依赖传递约束和影响范围时使用。
限制：这是讨论流程技能，不负责实施；具体命令、代码示例和平台信息暂未提供。