用途
frontend-design-system 是 design-system 的兼容性别名（compatibility wrapper）。它的存在目的是让旧有工作流和按精确名称集成的场景继续可用，同时避免让前端 UI 系统这一条线看起来像有两个同等优先的默认技能。
何时使用
- 用户或工具明确要求 frontend-design-system
- 某个 setup、sync 或 migration 流程期望旧文件夹/名称存在
- 需要在把真正的 design-system 工作路由到 design-system 的同时保持向后兼容
不要把它作为通用 UI 系统设计工作的默认选择。
使用方式
第一步：确认别名意图
仅当精确的旧名称确实重要时才使用该别名。合理理由包括：用户直接点名 frontend-design-system；脚本或平台按字面引用该文件夹/名称；在迁移或清理过程中保持兼容。否则应切换到 ../design-system/SKILL.md。
第二步：重定向到规范技能
先使用别名侧的资料包，然后跳转到规范技能进行实质性的 UI 系统工作：
- 别名路由说明：./references/alias-routing.md
- 紧凑/发现同步说明：./references/compact-surface-sync.md
- 规范技能：../design-system/SKILL.md
- 边界说明：../design-system/references/scope-boundaries.md
邻近技能：
- ../ui-component-patterns/SKILL.md，用于实现层面的组件模式
- ../responsive-design/SKILL.md，用于设备适配工作
- ../web-accessibility/SKILL.md，用于无障碍审计/修复
第三步：在输出中保留兼容性
如果通过别名名称激活，应说明规范指引现在位于 design-system，以便后续维护收敛到单一主入口。
示例
示例 1：明确要求旧名称
输入：“Use frontend-design-system to shape the UI system for our SaaS dashboard.” 输出：确认别名，然后应用规范 design-system 指引，处理 token、布局层级、动效规则和无障碍。
示例 2：通用 UI 系统问题
输入：“We need a design system for a landing page and dashboard that share components.” 输出：不要停留在别名中，直接路由到 design-system。
最佳实践
- 将其视为重定向层，而非独立知识库。
- 保持触发措辞狭窄，使 design-system 在普通提示中胜出。
- 底层 UI 系统指引变化时，先更新规范技能。
- 在 README/setup/manifest 层面明确标注规范与兼容状态。
参考资料
- ./references/alias-routing.md
- ./references/compact-surface-sync.md
- ../design-system/SKILL.md
- ../design-system/references/scope-boundaries.md
- ../ui-component-patterns/SKILL.md
- ../responsive-design/SKILL.md
- ../web-accessibility/SKILL.md