mcpbeat

Mobile Adaptation

kangarooking/mobile-adaptation

| 当系统提示面向移动端(手机、平板)场景时调用。适用于 iOS/Android 应用内 AI 助手、移动端聊天界面、响应式输出的系统提示设计。不适用于桌面端优先的场景,不适用于移动端 UI 开发(非提示层),不适用于语音场景(语音场景使用 voice-optimization)。

1k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
146
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/kangarooking/system-prompt-skills --skill mobile-adaptation

The instruction itself

9 sections, as written by the author

移动端适配

R — 原文 (Reading)

> Claude Mobile iOS 基于屏幕尺寸设定响应层级:手机一次显示 6-8 句话,简单问题 1-2 句、操作指南短列表、实质问题 2-3 段、复杂问题不超过 2 屏。集成移动原生工具(日历、提醒、位置、图表)。Claude for Word 禁止管道分隔的 Markdown 表格(任务窗格太窄)。Gemini 实现移动端专项输出压缩。核心模式:屏幕尺寸响应分级、移动原生工具集成、格式限制、答案优先策略。

I — 方法论骨架 (Interpretation)

  • 屏幕尺寸感知分级:根据目标设备屏幕容量将回答分为 4 个层级,每个层级有明确的长度上限(句数、段数或屏数)。
  • 答案优先策略:移动端用户注意力碎片化,回答结构必须"结论先行、细节后置",禁止铺垫性开场白。
  • 格式限制清单:在窄屏场景中禁用特定格式——管道表格、深层嵌套列表、宽代码块、大段引用。
  • 移动原生工具集成:利用移动设备独有能力(日历、提醒事项、地理位置、本地时间、图表显示)增强交互。
  • 扫描友好结构:使用短列表、加粗关键词、分段标题等格式,使用户在 3-5 秒内定位核心信息。

A1 — 案例分析 (Past Application)

案例: Claude Mobile iOS 的四层响应分级

  • 问题: 移动端屏幕一次只能显示 6-8 句话,过长的回答需要大量滚动,严重影响移动场景下的信息获取效率。
  • 设计模式的使用: Claude Mobile iOS 将回答分为四个层级并设定严格长度约束——简单问题 1-2 句话直接回答,操作指南用最短列表,实质性问题 2-3 段,复杂问题不超过 2 个屏幕。所有层级均遵循"先给答案、无前言"原则。
  • 结论: 基于物理屏幕约束的量化分级比模糊的"尽量简短"指令有效得多,为模型提供了可执行的长度标准。

案例: Claude for Word 的表格格式禁令

  • 问题: Word 插件的任务窗格宽度极窄(约 300-400px),管道分隔的 Markdown 表格会溢出或折行混乱。
  • 设计模式的使用: Claude for Word 明确禁止在聊天中使用管道分隔的 Markdown 表格("No pipe-delimited markdown tables in chat"),改用结构化列表或自然语言描述替代。
  • 结论: 格式限制需要具体到特定的 Markdown 语法元素,泛化的"注意格式"指令无法精准解决窄屏适配问题。

A2 — 触发场景 (Future Trigger) ★

用户在什么情境下需要?

  • 设计手机 App 内嵌 AI 助手的系统提示
  • 优化现有桌面端系统提示以适配移动端
  • 构建跨平台 AI 产品,需针对不同屏幕尺寸差异化输出
  • 开发集成移动原生功能(日历、位置)的 AI 助手

语言信号

  • "移动端用户"
  • "手机屏幕上显示"
  • "小屏幕适配"
  • "需要集成日历/提醒/定位"
  • "App 内的 AI 助手"

与相邻 skill 的区分

  • voice-optimization 区别:语音优化关注听觉通道,移动适配关注视觉通道的物理约束;但两者共享简洁优先理念
  • citation-system 区别:引用在移动端需要特殊展示(如简化标记、折叠引用),但移动适配不涉及引用格式设计本身

E — 可执行步骤 (Execution)

  • 步骤 1:定义屏幕响应分级表 - 完成标准:基于目标设备屏幕容量,定义 4 级响应策略(简单/操作/中等/复杂),每级规定最大句数、段数或屏数,并附具体示例。
  • 步骤 2:编写格式限制清单 - 完成标准:列出在移动端禁止使用的格式类型(管道表格、深层嵌套列表、超过 60 字符的代码行等),并为每种禁止格式提供替代方案(表格→结构化列表、嵌套列表→扁平列举)。
  • 步骤 3:设计答案优先输出结构 - 完成标准:在系统提示中声明"结论先行"原则,规定回答结构为:直接答案 → 关键细节 → 可选扩展,并禁止铺垫性开场白。
  • 步骤 4:规划移动原生工具集成点 - 完成标准:列出可调用的移动原生能力(日历创建、提醒设置、位置查询、时间获取),为每个能力定义触发条件和调用格式。
  • 步骤 5:添加扫描友好格式规范 - 完成标准:规定移动端输出的格式增强规则——关键信息加粗、列表项不超过一行、段落间空行分隔、使用 emoji 前缀(如适用)提升视觉扫描效率。

B — 边界 (Boundary) ★

不要在以下情况使用

  • 桌面端优先的系统提示设计,屏幕空间不是主要约束
  • 移动端 UI/UX 设计(属于前端开发,非提示层)
  • 纯语音交互场景(无屏幕显示,应使用 voice-optimization)
  • 后端 API 设计(与输出展示层无关)

常见失败模式

  • 量化标准缺失:仅说"尽量简短"而不给出具体句数或屏数限制,模型无法精确控制输出长度
  • 一刀切压缩:将所有问题都压缩为一两句话,复杂问题信息丢失,应按复杂度分级处理
  • 忽视原生能力:仅优化文本输出但未利用移动设备独有的日历、位置、提醒等能力,错失交互增强机会
  • 格式限制过于笼统:说"注意移动端格式"而不具体指出禁止管道表格等特定语法,模型可能仍输出不适配格式

How to use it

Copy the folder

Take kangarooking/mobile-adaptation from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.