用途：在动手写代码或改配置之前，通过结构化对话把粗略想法变成经过验证的设计。技能明确要求：在呈现设计并获得用户批准前，不要开始实现，无论任务看起来多简单。
主要能力与流程：
- 探索上下文：先查看项目状态，包括文件、配置、近期改动和既有模式，再提问。
- 澄清提问：一次只问一个问题，避免堆砌问题清单；有已知选项时优先用多选题，空间真正开放时才用开放式问题；聚焦目的、约束、成功标准和用户最在意的事。
- 提出方案：给出 2-3 个带取舍的方案，先讲推荐项并说明理由，诚实说明缺点；若只有一个方案合理，就直说并解释其他方案为何不可行，不要编造选项。
- 呈现设计：按复杂度分节呈现，简单部分几句话，存在真实取舍的部分更详细；每节获得批准，便于用户及早纠偏；覆盖哪些会变、哪些不变、用户需要验证什么、哪些决定留到实现阶段。
- 转入实现：设计获批后进入实现；迁移场景进入相应迁移阶段，其他工作直接开始执行。
适用场景：迁移前探索站点结构并讨论可编辑性取舍（页面构建器与静态页面、哪些内容可编辑、内容重构决策）；为现有站点添加片段、可视化编辑或配置前；重组内容、集合或配置前；需求含糊时，例如用户只说“让它支持 CC”而未说明范围。
不适用场景：单一且实现方式明确的任务（如向 _editables 添加 snippet: true）；问题与解法都清晰的缺陷修复；用户明确说“直接做”或已提供详细规格。
后续衔接：设计获批后由负责该工作的技能继续实现，包括 migrate-to-cloudcannon（完整迁移，从 Phase 1 进入）、cloudcannon-configuration（集合、输入、结构、集合 URL）、cloudcannon-visual-editing（可编辑区域）、cloudcannon-snippets（内容中的 MDX 组件或内联 HTML）、make-site-multilingual（Rosey 与 CloudCannon 连接器）。
关键原则：一次一个问题；已知选项时优先多选；YAGNI，去掉设计中不必要的复杂度；始终考虑是否有更简单的替代方案；诚实指出过度复杂之处并抵制范围蔓延；分节增量验证。
常见误区：认为“太简单不需要设计”——简单任务恰恰是假设造成最多浪费的地方，设计可以很短；认为“我已经知道怎么做”——你知道的是自己会怎么做，用户可能有不同优先级或约束；认为“提问会拖慢进度”——错误假设拖得更慢；认为“用户会告诉我哪里不对”——用户往往看到错误结果才知道要指出什么；认为“边做边想”——这会导致返工，应先探索空间。
限制：该技能为单文件，没有深入子文档；具体命令、安装方式与收费信息暂未提供。