用途：处理宽泛、含糊或涉及多个方面的前端设计请求（如“让它更好”“看起来很业余”“规划设计系统”）。它是调度器而非讲解者：检查代码库、依据证据（而非问卷）诊断设计成熟度，选定一条实现路径，再按依赖顺序交给具体技能，并说明每步为下一步产出什么工件。原则是先修基础再修表面。
不适用：请求只涉及单一问题时，应直接路由，如缺令牌/令牌漂移→design-foundation，间距/对齐/响应式→layout-system，字体→typography-system，配色/暗色模式→color-system，杂乱→visual-hierarchy-refactoring，错误/加载/动画/无障碍/性能→skills/frontend-design/ 下对应技能。
主要能力：
- 检查代码库：查找 tailwind.config.{js,ts,cjs,mjs}、globals.css、index.css、tokens*、theme；统计散落的十六进制与 rgb/rgba/hsl 颜色数量；查找任意 Tailwind 值与一次性 px；判断组件是否复用；检查暗色模式与 aria/sr-only/prefers-reduced-motion；查看 transition/animation/@keyframes。
- 最多只问两个代码看不出的问题：当前首要目标、最重要的页面或流程。
- 依据证据把成熟度定为 1（功能性 MVP）至 5（卓越），并给出 2–3 条含文件路径或计数的具体证据。
- 按顺序规则选定唯一条路径：无障碍投诉/法律风险/审计失败→E；用户抱怨慢或 Core Web Vitals→D；1 级→A；2 级→B；3–4 级→C。若并列则按用户目标择一并给一句理由。
- 路径 A（从零构建）：design-foundation → layout-system → typography-system → color-system → visual-hierarchy-refactoring → component-architecture → loading-states → error-handling-recovery → interaction-physics → performance-optimization → accessibility-excellence。 路径 B（形式化既有设计）：design-foundation（抽取令牌+迁移映射）→ visual-hierarchy-refactoring → component-architecture → 按漂移程度排 typography-system、color-system、layout-system → accessibility-excellence → 按痛点安排其余。 路径 C（精炼成熟系统）：interaction-physics → visual-hierarchy-refactoring → loading-states + error-handling-recovery → performance-optimization，必要时再动 typography/color。 路径 D（性能优先）：performance-optimization（产出指标基线）→ loading-states → interaction-physics → accessibility-excellence。 路径 E（无障碍优先）：accessibility-excellence（产出问题清单）→ color-system → typography-system → error-handling-recovery + loading-states → component-architecture → interaction-physics。
- 按固定格式输出诊断、推荐路径、路线图表格与“从哪开始”，然后询问是否立即执行第一步。
限制：不得只靠问卷判断；每条成熟度结论必须有代码出处；无代码（全新项目）则说明并默认路径 A；只呈现一条已选定路径而非五个选项菜单；按依赖而非日历排序，不列周计划；积极裁剪与目标无关步骤；不得编造 Lighthouse 分数或用户数等指标，只引用实测或用户所述。