adapt

adapt skill 概览

adapt skill 是做什么的

adapt skill 用来把现有界面重新设计到新的使用场景中：比如不同屏幕尺寸、设备、输入方式、平台，或不同的使用环境。实际使用中，adapt 特别适合 UI/UX Design 团队和借助 AI 工作的设计师，把一个以桌面端为主的方案扩展到 mobile、tablet、print、TV、touch、keyboard 或低带宽场景，而不是只把“响应式”理解成改几个断点。

谁适合使用 adapt

如果你已经有明确的设计方向、页面、流程或组件体系，只是需要让它在另一个场景里也成立，就适合用 adapt。它很适合 product designer、frontend designer、UX engineer，以及需要处理 responsive design、移动端适配、跨设备兼容或特定场景布局决策的 agent。

它真正解决的工作问题

大多数用户并不需要一个泛泛的“帮我做响应式”提示词。他们真正卡住的是更难的问题：哪些内容该保留，哪些该折叠，哪些交互在 touch 下会失效，哪些信息要降级，以及原始场景里的哪些前提在新环境里已经不成立。adapt skill 的价值就在于：它把适配视为“上下文切换”问题，而不只是一次 CSS 调整。

adapt 的差异点在哪里

它最大的区别，是有一个必须做的准备步骤。adapt 明确依赖 /frontend-design 提供更完整的设计上下文；如果这些上下文还没有准备好，它会要求你先运行 /teach-impeccable。这让它比普通 prompt 更有结构，但也意味着，只有当你需要“被引导的适配思考”而不是一次性的 responsive 改写时，adapt install 才真正值得装。

最适合与不适合的场景

最适合：

• desktop 到 mobile 的重设计
• web 到 tablet 或 touch 场景的适配
• keyboard、mouse、touch 交互方式变化
• print 或受限环境下的变体设计
• 快速判断跨场景必须改动的部分

不适合：

• 完全从零开始、还没有设计方向的产品构思
• 不需要 UX 判断、只做实现的纯开发任务
• 不涉及场景变化、只想做视觉润色的需求

如何使用 adapt skill

使用 adapt 前，先把上下文装好

这个 skill 位于 pbakaus/impeccable 仓库的 .claude/skills/adapt。它本身没有暴露独立 package 的安装流程，所以所谓 adapt install，本质上是把仓库里的这个 skill 加进你的环境，并确认相关的设计类依赖 skill 也可用。

如果你的工具支持远程安装 skill，就使用 pbakaus/impeccable 的仓库路径或 URL，并选择 adapt。安装后，确认 /frontend-design 和 /teach-impeccable 也能访问，因为这个 skill 默认会依赖它们。

先读这个文件

从这里开始看：

• SKILL.md

这个 skill 体量很小，也比较自包含。根据仓库里能看到的证据，没有额外暴露规则文件、参考资料、脚本或资源目录，所以大部分可用逻辑都集中在这一个文件里。好处是上手快；代价是你的 prompt 质量会更关键。

必需依赖：frontend design 上下文

调用 adapt 之前，先运行 /frontend-design，按它的上下文收集流程走一遍。如果你现在还没有足够的设计上下文，就先运行 /teach-impeccable。这是接入时最关键的一点，因为跳过它，对结果质量的伤害比你怎么措辞都更大。

说得直接一点：不要让 adapt 在真空里解决 responsive design。先把设计原则、产品背景和当前界面的核心假设提供给它。

adapt 需要什么输入

一条高质量的 adapt usage 请求，最好包含：

• 当前设计或源场景
• 目标场景
• 用户要完成的核心任务
• 跨场景变化的限制条件
• 必须继续成立的交互模型

skill 特别有用的细节包括：

• device type
• input method
• screen size 或 orientation 限制
• connection quality
• usage mode，比如 quick glance 还是 focused session
• platform expectations

如何把 adapt 请求写得更好

弱 prompt：

• “Make this responsive.”

更强的写法：

• “Use adapt for UI/UX Design. Source context: desktop web analytics dashboard optimized for mouse and large screens. Target context: mobile web on touch devices, portrait orientation, intermittent 4G, quick check-ins during commutes. Preserve top KPIs, recent alerts, and one-tap drilldown. Identify what to remove, collapse, reorder, or defer.”

为什么这样更有效：

• 它告诉 adapt 原始设计建立在哪些假设上
• 它明确了目标环境
• 它说清了用户优先级
• 它允许 skill 改变信息层级，而不只是把布局缩小

用参数提示快速调用

这个 skill 暴露了一个参数提示：

• [target] [context (mobile, tablet, print...)]

这意味着，如果当前对话里已经有足够的设计上下文，简短调用也能工作。比如：

• adapt checkout flow mobile
• adapt analytics dashboard tablet
• adapt settings page print

但前提是，这个 session 里已经有足够完整的源场景信息。

真实项目里推荐的 adapt workflow

一个实用的 adapt guide workflow 是：

1. 用 /frontend-design 收集产品和设计上下文
2. 明确原始页面或流程依赖的关键假设
3. 说明目标平台和实际使用场景
4. 让 adapt 识别 breakpoints、层级变化和交互变化
5. 审查哪些该保留、删除、合并或延后
6. 再把结果转成组件规范或实现任务

这套顺序比一上来直接改布局更稳，因为很多适配失败，本质上都来自“保留了太多原有东西”。

adapt 在评估时重点看什么

根据 skill 内容，adapt 会重点评估：

• 源场景中的假设
• 目标设备和平台限制
• 输入方式变化，比如 mouse 到 touch
• 使用场景变化，比如 desk 到 on-the-go
• 用户在新环境下的预期

所以它不只是适用于传统 responsive design，也适合处理 platform adaptation——有些场景需要改的是行为逻辑，而不只是间距和排版。

adapt 的实用示例：哪些用法更靠谱

比较好的使用案例包括：

• desktop 数据表格改成 mobile 的摘要 + 详情流
• 侧边栏很重的 admin UI 改成 tablet 分栏视图
• desktop 的 hover 交互改成 touch-safe 替代方案
• 内容量很大的页面做 print-friendly 版本
• kiosk 或 TV 场景下，放大点击目标并简化导航

在这些案例里，最好先问 adapt：原有假设最先会在哪些地方失效？通常这会比直接要求它“调视觉”得到更好的结果。

采用 adapt 前最常见的阻碍

主要阻碍通常不是技术安装，而是上下文缺失：

• 没有清晰的源设计可供适配
• 没有明确的目标平台
• 没有输入方式细节
• 没有给核心任务排优先级
• 期待一个 UX 适配 skill 直接产出可上线的 CSS

如果你最终需要代码，更好的做法是先用 adapt 做设计决策，再把结果交给偏实现的 workflow。

adapt skill 常见问题

adapt skill 只是一个响应式设计 prompt 吗？

不是。adapt 处理的不只是 breakpoints 和流式布局，它面向的是上下文适配，包括设备、输入方式、网络条件和使用模式变化。所以当行为和信息层级都需要调整时，它比泛泛的“make it mobile-friendly” prompt 更有用。

adapt 适合新手吗？

适合，但有一个前提：新手只有在提供足够上下文时，才能真正受益于它的结构化思路。如果你刚接触 UI 适配，adapt 很适合帮你挖出那些隐藏假设；但如果你只给一张截图再加一句“改成 mobile”，产出的可执行性会明显下降。

什么情况下不该用 adapt？

以下需求不建议用 adapt：

• 从零开始的 greenfield 产品概念
• 只做像素级视觉打磨
• 不经过设计推理、直接要 frontend code
• 与上下文切换无关的 design-system 审查

这些情况下，换一个 skill，或者直接走实现型 prompt，会更合适。

adapt 和普通 prompt 有什么不同？

普通 prompt 往往停留在“压缩布局”这一步。adapt skill 会逼你先定义源场景假设、目标限制和使用环境。也正是这层额外结构，让它比临时 improvising 更值得安装。

adapt 需要依赖其他 skill 吗？

实际上需要。这个 skill 明确要求 /frontend-design 上下文；如果当前还没有设计上下文，可能还要先跑 /teach-impeccable。如果你的环境只装了 adapt，没有这些支撑 skill，那结果大概率会更弱，或者需要你手动补很多前置准备。

如何改进 adapt skill 的使用效果

明确告诉 adapt：源设计建立在哪些假设上

想让 adapt 输出更快变好，最直接的方法，就是把当前设计依赖的假设写出来，比如：

• 大屏
• 精确指针
• 长时会话
• 稳定连接
• 高密度信息展示

这些假设能直接告诉 skill：到了新场景里，最可能先坏掉的是什么。

明确哪些能力必须在适配后保留下来

除非你真的想重做一遍，否则不要一句话就要求全面 redesign。最好列出 2-4 个在目标场景里必须依然优秀的点，比如：

• 一分钟内完成 checkout
• 一眼看到 alerts
• 快速对比两个产品
• 单手完成审批

这样能帮助 adapt for UI/UX Design 保住正确的 workflow，而不是盲目重排。

把目标场景写得像真实环境

输入越贴近现实，适配决策越靠谱。建议补充这些细节：

• portrait 还是 landscape
• touch 还是 keyboard
• 室内桌面使用，还是户外快速访问
• 低带宽，还是稳定 Wi‑Fi
• accessibility expectations
• native platform conventions

这些信息会实质性影响信息层级、控件形式和导航方式。

不只要方案，也要 tradeoff

一条高价值的 adapt guide 请求，应该主动追问：

• 什么应该删掉
• 什么应该延后到二级页面
• 哪些交互模式需要改变
• 在新场景里，什么会成为 primary action

这是提高结果质量的关键，因为适配通常不是“把所有东西都搬过去”，而是做减法和重新排序。

第一轮之后继续迭代

拿到第一版 adapt usage 结果后，最好用更聚焦的 follow-up 继续细化，比如：

• “Now adapt only the filtering workflow.”
• “Preserve comparison capability on tablet.”
• “Reduce thumb reach issues for one-handed use.”
• “Keep expert shortcuts for keyboard users.”

相比把所有要求一次性塞进一个超长请求里，这种小步迭代通常效果更好。

留意 adapt 的常见失效模式

以下情况很容易让输出变弱：

• 没有描述源设计
• 目标场景过于模糊
• 在 UX 决策前就要求实现方案
• 把当前所有功能都当成同等重要
• 忽略平台惯例

如果结果看起来很泛，通常问题不在于 prompt 不够长，而在于上下文不够强。

把 adapt 当成实现前的决策工具

想把结果做得更好，最佳方式是把 adapt 当作设计决策层来用：先让它产出适配逻辑，再把这些逻辑转成 wireframe、spec 或 frontend task。这样分层处理，能让 skill 聚焦在它最擅长的事情上：决定一个 UI 在不同上下文里应该如何变化。