一个编辑器只有两个开关时还容易理解，继续加入回复、转发、只读和紧凑模式后，调用方很难知道哪些组合有效。这个 Skill 关注组件的公共接口：把场景表达成清楚的组合，而不是继续向一个大组件塞配置。
安装与首次使用
在项目根目录、已具备 Node.js 与 npm 的终端运行以下命令，给 Claude Code 安装这一项技能。使用 Codex 时，把 --agent claude-code 换成 --agent codex。这是项目级安装；安装完成后刷新或重开 Agent 会话，并在任务里明确写出技能名。
npx skills@latest add vercel-labs/agent-skills --skill vercel-composition-patterns --agent claude-code
从一个真实调用场景开始
以下是可按项目调整的首次输入：
使用 vercel-composition-patterns 审查 src/components/Composer.tsx 及其调用处。它同时处理新建、回复和编辑三种模式。先列出布尔属性与合法组合，再提出保持现有行为的拆分方案；确认后只迁移一种模式。项目使用 React 18，不引入 React 19 专属 API。
先让 Agent 找齐调用位置，记录每种模式实际展示的输入、按钮和提交行为。不要只根据组件文件中的条件分支猜用途；有些开关虽然名字接近，承担的权限或保存逻辑并不相同。第一次只处理一个有代表性的场景，可以保持其他调用方继续工作。
拆的是责任，不只是文件
官方规则展示了 Frame、Input、Footer 等部件组合，以及新建、回复、编辑各自明确的组件。共享结构留下，场景专属按钮放回对应变体。状态需要跨兄弟组件共享时，再由共同 Provider 管理；向消费者暴露状态和动作，比让每个子组件知道内部存储方式更容易替换实现。
让 Agent 同时给出旧调用与新调用的对照。你要能一眼看出编辑模式为何有取消和保存、回复模式为何增加目标选择，而不是在多个深层组件中继续寻找同一串条件。没有共享状态的小部件也不必为了遵守模式强行加 Context。
看行为是否保留下来
合适的产物是一组明确变体、稳定的共享接口和逐步迁移的调用点。用已有测试检查提交参数、禁用条件、焦点与取消行为，再检查类型和构建；只通过类型检查不足以证明交互没有改变。如果旧接口被其他团队使用，应保留过渡包装或明确迁移清单。
这套建议中包含 React 19 的 API 写法，不能直接套进旧项目。重构目的也不是让组件数量最多：只有两个稳定用途的小组件，可能只需要更清楚的命名。先解决当前已经出现的条件组合问题，再决定是否需要更大的组件家族。
用一个变体表决定接口
重构前先列出每种场景真正需要的内容。例如编辑器有“新建、回复、编辑”三种用途，可写一张小表：每种用途是否显示目标对象、取消按钮、保存提示，以及提交时要传什么。若旧组件有 isReply、isEdit、showCancel 三个开关，理论组合有八种，但产品可能只允许三种。先把合法组合说清楚，再设计显式变体，否则只是把条件分支换了文件位置。
迁移第一个调用处时，保留旧 API 的测试或临时适配器，比较提交载荷、焦点顺序、键盘操作和禁用状态。共享 Provider 只承载确实需要跨子组件共享的状态；静态标题或单个按钮没必要进入 Context。React 19 特有建议需要先确认项目版本，不能因为规则文件写了就升级整个项目。
什么时候暂时别重构
如果只是两个固定页面、没有增长中的条件组合，清楚的命名和少量拆分可能已经够用。这个 Skill 提供判断接口复杂度的方法，不要求所有组件都变成 compound component。交付应说明新接口为什么减少非法组合、哪些调用点仍待迁移，以及现有行为如何验证。
用真实调用检验组合接口
组件库场景尤其适合从一个“属性越加越多”的组件入手。一个 shadcn registry 作者把这个 Skill 用在组件创建流程中，目的是避免出现十几个布尔开关，改用更清楚的组合接口。你可以先列出现有调用方式和有效组合，再要求 Agent 保留旧行为、设计 compound API，并用真实调用代码检查新接口是否更容易读。
安装后为什么没触发
安装后如果 Agent 从不启用它，核对目录 composition-patterns 和 Skill 内声明的 vercel-composition-patterns。有用户报告这种名称不一致会让某些运行环境把已安装 Skill 挂载后仍无法解析。先确认当前 Agent 实际识别的名称与文件路径，再谈重构效果；仅在项目目录看见文件并不能证明调用成功。