组件库管家

问题从哪来

业务迭代久了，Button、IconButton、各种「差不多」的封装会散落在不同目录里：命名各说各话、职责重叠、同一交互多套实现。合并或抽公共组件时，最怕同名异义、文档缺位，以及破坏性变更没有迁移说明——调用方只能翻 git blame 猜 API。

技能怎么跑

执行前会先收齐上下文：技术栈与组件目录、新增还是改造、对外 props / events / slots 与默认值、以及视觉、键盘与读屏等可访问性要求。

随后按固定节奏推进：

1. 盘点目录，标出命名冲突、职责重叠与重复实现。
2. 参照 references/component-spec-template.md 生成或更新组件规格文档。
3. 给出 base / business / composed 分层与放置理由。
4. 补最小可运行示例：基础用法、边界用法、错误用法。
5. 每次改动写变更记录：兼容性、迁移提示、废弃计划。

单次输出应包含：组件规格卡（名称、职责、API、约束、示例）、目录归属建议、变更影响分析（是否破坏兼容、影响哪些调用方）、以及测试 / 文档 / 发布等后续动作清单。典型输入如「统一 Button 与 IconButton 的 API 并补齐文档」，对应输出为规格差异对比、新 API 表、迁移示例与版本变更说明。

边界与红线

• 通用组件缺可访问性说明不应合并入库。
• 不允许只改代码、不给迁移信息的破坏性变更。
• 不允许同名异义或异名同义组件继续扩散。

适合已有私有组件库、需要治理而非从零搭脚手架的团队；它不替代你写组件实现本身，而是把「怎么进库、怎么文档化、怎么改而不踩调用方」流程钉死。