用途：在动手实现前完成技术方案设计，强调不能只列出要改哪些文件，还要说明为什么改、改动顺序和风险边界。
主要能力与工作流：第一步建立现状模型，先调用 context-analyzer 确认现有模块、依赖与约束，并识别是否有可复用实现以避免重复造轮子；第二步设计变更方案，把需求拆成模块职责、数据流和接口边界，输出要新增、修改、删除的文件及原因；第三步风险预判，标记鉴权、安全、迁移、兼容性和回滚风险，区分可并行与必须串行的步骤；第四步交接实现，给出最小可执行方案而非抽象大图，并说明适合交给哪个专业技能继续执行。
适用场景：架构设计、design plan、file mapping、implementation plan、技术方案、模块拆分、接口设计等。项目特化提示要求明确 composables、服务层、API 路由、数据模型和测试文件的对应关系，接口设计要说明 REST 或调用契约以及输入校验和错误语义，涉及实体关系或数据库读写时同步考虑迁移、权限和测试影响。
反模式：只输出抽象架构词汇不给文件级落点；不解释为何新建模块或重构现有模块；不预判兼容性和迁移成本。
交付前检查：方案包含文件映射、职责拆分和执行顺序；已说明关键风险和约束；已指出复用点和避免重复实现的依据；方案足以交给实现技能继续执行。
限制：资料未提供具体收费、价格、平台或效果信息。