ui-ecosystem

把已经确定的前端方向变成可执行的生态方案，让界面复用成熟组件和范式，减少重复手写。

什么时候用它

推荐界面工具

我的框架、样式方案、页面类型和设计方向已经明确，希望获得与技术栈匹配的组件库、工具、skill、插件或官方示例。

使用生态实现

我希望实现或打磨页面，并要求把已批准的生态选择真正用进代码，而不是只得到一张推荐清单。

检查生态使用

我已有可运行界面，想找出哪些自制控件、图标、动效、表单、表格或图表更适合改用成熟且兼容的基础组件。

不接

产品形态或前端方向尚未确定时先做策略设计。只审查无障碍、通用设计规范、后端问题、极小的样式修复，或只安装一个已选包时，应使用更直接的流程。

它会产出什么

修改前端代码或安装依赖之前，必须先产出 UI_ECOSYSTEM_PACKET。

• 环境摘要：记录框架、样式、设计系统、页面类型、现有约束和已检查的本地文件。
• 决策清单：为每个候选标记采用、启用、借鉴、试验或拒绝，并说明适配理由、风险和动作。
• 实施方案：列出准备安装或启用的内容、仍需定制的部分、验证方法和未确认事项。
• 模式副作用：只推荐模式不改文件；实施模式可以修改界面并安装已授权依赖；审计模式只在用户要求修复时编辑。
• 验证证据：按项目情况运行类型检查、代码检查、测试、构建，并在可见界面变化时使用浏览器检查。
• 绝不会做：不编造工具名，不越权安装，不复制许可不明的模板，也不让外部生态覆盖项目、无障碍或设计系统约束。

前置条件与边界

前置条件

必须已经确定前端框架、样式方案、页面或应用类型，并具备足够设计背景。项目规则、依赖清单、组件、样式配置和当前官方文档需要可检查。

发现与采用要求

• 在声称某个 MCP、插件或 skill 可用之前，必须先完成工具发现。
• 优先使用项目已有依赖和设计系统基础组件，再考虑增加新依赖。
• 采用前检查许可、兼容性、体积、运行影响和无障碍风险。

相邻流程分工

需要做的事	交给
决定产品形态或前端技术栈	strategy-first-development
应用 TranFu 品牌规则	tranfu-website-design
审查无障碍或设计规范	web-design-guidelines

微妙边界

只说“推荐工具”时，产出方案后停止；说“实现”“打磨”或“提升界面”时继续落地，但安装依赖仍需要明确授权。