用途：在实现之前，通过自然协作式对话把想法转化为成型的设计与规格，避免因假设错位、范围蔓延、架构返工而付出高昂代价。简单项目同样适用，只是设计可以更简短（几句话），但仍需先确认再实现。
主要能力：先了解项目现状（文件、文档、近期提交），再逐一提问澄清目的、约束与成功标准；提出 2-3 种方案及权衡并给出推荐；按复杂程度分节呈现设计（架构、组件、数据流、错误处理、测试），每节获取用户确认；将确认后的设计写入文档并提交；随后转入实现规划。
使用方式：按流程依次推进——探索项目上下文、一次只问一个问题、提出多种方案、分节呈现设计、获得明确批准、写设计文档、调用 writing-plans 技能。设计文档保存路径为 docs/plans/YYYY-MM-DD-<topic>-design.md，目录不存在时可用 mkdir -p docs/plans 创建，并提交到 git。设计确认后不要直接调用其他实现技能，应先用 writing-plans 生成详细实施计划，其他技能（如前端设计、mcp-builder 等）在计划之后使用。
适用场景：新增功能（如深色模式）、工具函数（如电话号码格式化）、架构变更（如 REST 迁移 GraphQL）等各类开发任务的前期设计。
限制与注意：一次只问一个问题，尽量用选择题；坚持 YAGNI，去除不必要功能；必须获得用户的明确批准（如“可以”“就这么做”）再进入下一步，单个澄清提问意味着设计尚未定稿，应修改后重新呈现。设计应聚焦“做什么、为什么”，不要写成含代码片段、文件结构或分步指令的实施计划；设计需足够具体，避免实现者仍需追问。若用户坚持跳过设计，可先说明风险并提议限时确认、给出最小设计并取得批准。资料未提供该技能的安装方式、收费或平台支持信息。