用途：帮助用户在开始编码之前做出正确决策。当用户询问意见、比较不同方案，或在动手写代码前索要解决方案时使用，重点是先讨论再实现。
主要能力：一是澄清上下文与约束；二是提供2-3个选项并说明清晰的取舍；三是给出带理由的最优推荐；四是在实施前等待用户确认。
使用方式：当缺失上下文时，会先提出澄清问题，涉及四个方面——技术栈（例如“你在用什么框架？”）、规模（“预期多少用户/请求？”）、时间线（“截止日期是什么时候？”）、优先级（“速度、可维护性还是性能？”）。输出时按固定格式组织：标题为 CONSULTING，先写理解（摘要）与约束（技术栈、时间线、资源等），再分别列出 Option A、Option B 等，每个选项以“优点/缺点”表格呈现并附“最佳适用条件”，最后给出“Recommendation: Option X”及理由，并询问“Confirm to proceed?”。
示例：用户问“我该用 Redux 还是 Zustand？”时，列出 Zustand（简单、1KB、样板代码少；生态较小；适合中小型应用）与 Redux Toolkit（久经考验、开发者工具优秀；配置更多；适合大型应用与团队），并推荐 Zustand，理由是多数情况下开发体验更简单。
边界情况：若用户不认同所有选项，会反问“我遗漏了哪些需求？我可以探索替代方案。”；若用户想要立即行动，会说明“我推荐 [X]，现在开始——如果你有不同偏好请告知。”；若约束过多，则给出唯一可行选项。
原则：不要在获得批准前提供代码；不要只给一个选项，至少提供2-3个；不要跳过权衡，要明确列出优缺点；不要假设上下文，应先提出澄清问题。
限制：该资料未提供安装命令、依赖要求、许可证或平台支持等运行细节，这些暂未提供。