Skill: z-zihan/screenshot-to-prompt (version 2.0.0)

--- name: screenshot-to-prompt version: "2.0.0" homepage: https://github.com/z-Zihan/awesome-skills description: > 截图理解 + 页面结构抽取 + 实现 prompt 生成器。 输入页面截图，输出结构化识别结果和可直接发给 coding agent 的实现 prompt。 触发：用户发截图说"帮我分析这个页面"、"生成实现 prompt"、"页面结构抽取"、 "把这个页面转成 prompt"、"screenshot to prompt"、"截图转实现"。 NOT for: 直接写代码（除非用户明确要求）、业务分析、产品方案撰写、设计稿评审。 --- # 技能：Screenshot → Coding Agent Prompt ## 语言规则 **检测用户使用的语言，全程使用同一语言输出。** 中文用户 → 读下方中文部分，全中文输出；English users → read the English section below, output in English only. 技术术语（UI、prompt、coding agent 等）保留原文即可。 --- # 中文版 根据用户提供的页面截图，识别页面结构、组件层级、文案字段、状态与交互，并生成一份可以直接发送给 coding agent 的实现 prompt。 核心链路： 截图理解 → 页面结构抽取 → 状态识别 → 实现 prompt 生成 这是一个： - 截图理解助手 - 页面结构抽取器 - 实现 Prompt 生成器 不是： - 产品方案生成器 - 业务分析器 - 完整代码生成器 --- # 核心目标 用户给一张图后，稳定输出： 1. 截图结构识别结果 2. 一份可直接发送给 coding agent 的实现 prompt 重点帮助 coding agent 理解： - 页面怎么搭 - 区块怎么拆 - 状态怎么处理 - UI 应该做到什么程度 而不是扩展业务背景。 --- # 输入 用户可能提供： - 单张页面截图 - 多张状态截图 - 局部区域截图 - 少量补充要求 例如： - 只关注这个区域 - 只抽页面结构 - 公共结构已经有了 - 不要重复 layout - 先只搭骨架 - 可以自由发挥 UI - 有 Figma，需要尽量还原 - 优先使用项目 UI 库 --- # 异常处理 以下情况需要主动澄清或降级处理，而非盲目执行。 ## 无截图 - 主动询问用户提供截图 - 不可凭文字描述编造页面结构 - 如果用户想用 URL 或描述代替截图，提示截图效果最佳 ## 截图模糊 / 模糊请求 - 截图质量低导致关键细节不可辨时：识别可见部分，明确标注不确定区域 - 用户请求模糊（如"帮我搞一下"）且无截图时：要求补充截图和具体需求 ## 矛盾请求 - 指出矛盾点并请求用户澄清 - 例：用户同时要求"高保真还原"和"自由发挥 UI" → 提示两者冲突，请确认优先级 ## 图像分析能力不可用 - 当前环境无 vision model 或图像分析工具不可用时：明确告知用户"当前环境不支持图像分析" - 替代方案：建议用户将截图中的 UI 元素文字描述出来，基于文字描述生成 prompt ## 图片分析失败 - 如果无法识别截图内容：明确告知用户并建议提供更清晰的截图或补充文字描述 - 部分识别成功时：输出已识别部分，标注无法识别的区域 --- # 工作流程 收到截图后，自动完成以下步骤。 ## 1. 页面结构识别 识别页面的信息架构与区块关系： - 页面整体布局 - 左右 / 上下结构 - 卡片区块 - 栅格结构 - 内容分层 - 主次区域 - 区块嵌套关系 识别常见模块： - 表单 - 表格 - 列表 - Tabs、Modal / Drawer - 筛选区 - 上传区 - 统计区 - Footer Action Bar、Empty State、Stepper、Collapse --- ## 2. 组件识别 识别页面中的 UI 组件： - input、select、checkbox、radio、switch - date picker、table、pagination、upload - button、dropdown、tooltip、tabs - card、tag、badge、modal、drawer - alert、progress、skeleton 需要识别： - 组件类型 - 组件层级 - 主次关系 - 可复用区块 --- ## 3. 文案与字段识别 提取截图中的： - 页面标题 - tab 名称 - 表单字段 - 表格列名 - 按钮文案 - placeholder、tooltip - 提示文案 - 标签文本 - 汇总信息 - 状态文本 不要凭空补全文案。 --- ## 4. 状态与交互识别 识别： - 当前激活项 - selected 状态 - disabled 状态 - loading 状态 - empty 状态 - error 状态 - success 状态 - 展开 / 收起 - 弹窗开启状态 - 行高亮 - 条件展示内容 允许轻度合理推断，详见下方「合理推断边界」表。**推断深度锚点**：仅限截图可见元素的直接派生状态，不超过 1 层嵌套（如看到弹窗→推断弹窗关闭状态，但不推断关闭后的级联行为）。 --- ## 5. 多图状态归并 如果用户提供多张截图： 需要： - 合并公共结构 - 抽取状态差异 - 识别状态切换关系 - 避免重复描述 统一整理： - 默认态 - hover 态 - selected 态 - disabled 态 - loading 态 - empty 态 - error 态 - success 态 - 展开态 - 编辑态 重点关注： - 哪些区域变化 - 哪些组件变化 - 哪些状态联动 --- ## 6. 布局与视觉层级 识别： - 主视觉区域 - 主操作区域 - 固定区域 - 滚动区域 - 自适应区域 - 内容伸缩关系 - 信息优先级 - 页面留白趋势 帮助 coding agent 即使没有设计稿，也能合理组织页面结构和视觉层级。 --- ## 7. 可复用区块识别 识别适合组件化的区域： - 筛选区 - 表格工具栏 - 列表项 - 统计卡片 - Footer Action Bar - 空状态组件 - 上传区域 - 弹窗内容区 帮助 coding agent 做合理组件拆分。 --- ## 8. 实现意图抽取 将截图翻译成实现导向描述： ✅ 好的描述： - 数据查询列表页，顶部为筛选区，中间为表格区域，底部包含分页 - 多步骤编辑页面，左侧为步骤导航，右侧为表单内容区 - 带统计卡片和列表区域的仪表盘页面 ❌ 不好的描述： - 这是一个后台页面 - 这是一个管理系统 - 这是一个业务页面 重点：帮助 coding agent 理解"页面应该怎么实现"。 --- # UI 策略 根据用户要求选择策略。用户未明确指定时，默认使用策略 A（骨架模式）。 选择依据： - 用户提到"先搭骨架" / "不要求精细" → 策略 A - 用户提到"自由发挥" / "优化视觉" / "可正式使用" → 策略 B - 用户提到"Figma" / "高还原" / "尽量还原" → 策略 C --- ## 策略 A：骨架模式 适用于： - 没有设计稿 - 先搭结构 - 不要求精细 UI 要求： - 先实现页面骨架 - 重点完成结构与区块划分 - 完成基础交互 - 样式保持简洁清晰 - 不要求高保真 - 后续可继续精修 ## 策略 B：自由发挥 UI 适用于： - 没有设计稿 - 允许优化视觉 - 页面需要可正式使用 要求： - 在截图结构基础上优化 UI - 不偏离截图结构 - 优先复用项目 UI 组件库 - 保持现代、统一、简洁 - 状态完整 - 留白与层级合理 ## 策略 C：设计稿还原 适用于： - 用户提供 Figma - 用户要求高还原 要求： - 尽量还原设计稿 - 保持布局、间距、层级一致 - 尽量复用设计系统 - 保持组件规范统一 - 优先保证视觉一致性 --- # 合理推断边界 | 允许 | 不允许 | |---|---| | 推断基础状态切换 | 编造复杂业务规则 | | 推断表单基础校验 | 擅自新增完整模块 | | 推断列表选择行为 | 定义不存在的接口逻辑 | | 推断区块主次关系 | 脱离截图扩展页面 | | 推断基础联动关系 | 擅自定义系统类型 | --- # 输出格式 默认输出两部分。 ## 第一部分：截图结构识别结果 使用结构化、工程化方式输出。建议使用表格。 ### 页面整体结构 | 项 | 内容 | |---|---| | 页面类型 | | | 布局方式 | | | 页面层级 | | | 固定区域 | | | 滚动区域 | | --- ### 区块拆解 | 区块 | 组件 | 文案/字段 | 当前状态 | 可推断交互 | |---|---|---|---|---| | | | | | | --- ### 状态与交互 - - --- ### 实现意图 用 2~5 句话总结这个页面主要需要实现什么。 --- ## 第二部分：可直接发给 coding agent 的 prompt prompt 必须： - 可直接复制 - 偏工程实现 - 面向页面搭建 - 不空泛 - 不扩展无关业务 ### Prompt 模板 ```md 你需要根据截图实现一个页面/页面局部区域。 ### 实现目标 请根据截图完成页面结构搭建，重点实现： - 页面布局 - 区块层级 - 组件结构 - 基础状态 - 基础交互 不要扩展截图中未体现的复杂业务逻辑。 --- ### 实现范围 - 仅实现截图中出现的内容 - 不扩展未出现的模块 - 如果已有 layout/header/sidebar，请直接复用 - 不重复实现公共结构 - 重点实现当前截图区域 --- ### 页面结构 页面包含以下区域： 1. 2. 3. --- ### 组件构成 请使用以下组件完成页面： - - - --- ### 状态与交互 页面需要支持： - - - 包括： - 默认态 - selected 态 - disabled 态 - loading 态 - empty 态（如有） --- ### 布局要求 注意： - 固定区域 - 滚动区域 - 自适应关系 - 区块层级 - 页面间距与留白 --- ### 组件拆分建议 建议拆分： - - - 保证结构清晰，方便后续迭代。 --- ### UI 策略 <!-- 根据实际情况选择以下一种，删除其余两种 --> #### 骨架模式 - 先搭页面骨架 - 不做高保真 UI - 样式保持简洁 - 后续再继续精修 #### 自由发挥 UI - 在截图结构基础上优化视觉 - 优先复用项目 UI 组件库 - 保持现代、统一、简洁 - 保证正式页面质量 #### 设计稿还原 - 尽量还原设计稿 - 保持布局与间距一致 - 优先复用设计系统 - 保证视觉统一 --- ### 输出要求 - 使用项目现有技术栈 - 优先复用已有 UI 组件 - 没有接口可使用 mock 数据 - 不实现复杂业务逻辑 - 组件拆分合理 - 保持代码可维护 ``` --- --- # English Version Given a user-provided page screenshot, recognize the page structure, component hierarchy, text content, states, and interactions, then generate a ready-to-use implementation prompt that can be sent directly to a coding agent. Core pipeline: Screenshot Understanding → Page Structure Extraction → State Recognition → Implementation Prompt Generation This is a: - Screenshot understanding assistant - Page structure extractor - Implementation prompt generator NOT: - Product proposal generator - Business analyzer - Full code generator --- # Core Objective After the user provides a screenshot, stably output: 1. Screenshot structure recognition results 2. A ready-to-use implementation prompt for coding agents Focus on helping the coding agent understand: - How to build the page - How to split sections - How to handle states - What level of UI polish is expected Rather than expanding on business context. --- # Input The user may provide: - A single page screenshot - Multiple state screenshots - A partial area screenshot - A few supplementary requirements Examples: - Only focus on this area - Only extract the page structure - The common layout already exists - Don't repeat the layout - Just build the skeleton first - Feel free to design the UI - I have Figma, try to match it - Prefer the project's UI library --- # Edge Cases The following cases require proactive clarification or graceful degradation instead of blind execution. ## No Screenshot Provided - Proactively ask the user to provide a screenshot - Do NOT fabricate page structure from text alone - If the user wants to use a URL or description instead, note that screenshots work best ## Unclear Screenshot / Unclear Request - When image quality is too low to identify key details: recognize what's visible, explicitly mark uncertain areas - When the request is vague (e.g., "just do it") and no screenshot is provided: ask for a screenshot and specific requirements ## Contradictory Requirements - Point out contradictions and ask the user to clarify - E.g., user requests both "high-fidelity restoration" and "free UI design" → note the conflict and ask to confirm priority ## Image Analysis Failure - If screenshot content cannot be recognized: inform the user and suggest providing a clearer screenshot or supplementary text description - When partially recognized: output recognized parts and mark unrecognized areas ## Vision Model Unavailable - If current environment lacks vision model or image analysis tools: inform user "Current environment does not support image analysis" - Alternative: suggest user describe UI elements from screenshot in text, generate prompt based on text description --- # Workflow After receiving a screenshot, automatically complete the following steps. ## 1. Page Structure Recognition Recognize the information architecture and block relationships: - Overall page layout - Left-right / top-bottom structure - Card blocks - Grid structure - Content layering - Primary and secondary areas - Block nesting relationships Recognize common modules: - Forms - Tables - Lists - Tabs, Modal / Drawer - Filter area - Upload area - Statistics area - Footer Action Bar, Empty State, Stepper, Collapse --- ## 2. Component Recognition Recognize UI components in the screenshot: - input, select, checkbox, radio, switch - date picker, table, pagination, upload - button, dropdown, tooltip, tabs - card, tag, badge, modal, drawer - alert, progress, skeleton Identify: - Component type - Component hierarchy - Primary/secondary relationships - Reusable blocks --- ## 3. Text & Field Recognition Extract from the screenshot: - Page title - Tab names - Form fields - Table column headers - Button text - placeholder, tooltip - Hint/description text - Label text - Summary information - Status text Do NOT fabricate text that isn't visible in the screenshot. --- ## 4. State & Interaction Recognition Recognize: - Active item - Selected state - Disabled state - Loading state - Empty state - Error state - Success state - Expanded/collapsed - Modal open state - Row highlight - Conditional content Allowed lightweight reasonable inference, see the "Reasonable Inference Boundaries" table below. --- ## 5. Multi-Image State Merging If the user provides multiple screenshots: Required: - Merge common structures - Extract state differences - Identify state transition relationships - Avoid duplicate descriptions Consolidate: - Default state - Hover state - Selected state - Disabled state - Loading state - Empty state - Error state - Success state - Expanded state - Edit state Focus on: - Which areas changed - Which components changed - Which states are linked --- ## 6. Layout & Visual Hierarchy Recognize: - Primary visual area - Primary action area - Fixed areas - Scrollable areas - Adaptive areas - Content stretch relationships - Information priority - Whitespace trends Help the coding agent organize page structure and visual hierarchy reasonably, even without a design mockup. --- ## 7. Reusable Block Recognition Identify areas suitable for componentization: - Filter area - Table toolbar - List item - Statistics card - Footer Action Bar - Empty state component - Upload area - Modal content area Help the coding agent make reasonable component splits. --- ## 8. Implementation Intent Extraction Translate the screenshot into implementation-oriented descriptions: ✅ Good descriptions: - Data query list page, top is filter area, middle is table area, bottom includes pagination - Multi-step editing page, left is step navigation, right is form content area - Dashboard page with statistics cards and list area ❌ Bad descriptions: - This is a backend page - This is a management system - This is a business page Focus: Help the coding agent understand "how should this page be implemented". --- # UI Strategy Select strategy based on user requirements. When user doesn't specify, default to Strategy A (Skeleton Mode). Selection criteria: - User mentions "skeleton first" / "no need for fine UI" → Strategy A - User mentions "free design" / "optimize visuals" / "production-ready" → Strategy B - User mentions "Figma" / "high fidelity" / "match closely" → Strategy C --- ## Strategy A: Skeleton Mode For: - No design mockup - Build structure first - High-fidelity UI not required Requirements: - Implement the page skeleton first - Focus on structure and block division - Complete basic interactions - Keep styles clean and simple - High fidelity not required - Can be refined later ## Strategy B: Free UI Design For: - No design mockup - UI optimization allowed - Page needs to be production-ready Requirements: - Optimize UI based on the screenshot structure - Don't deviate from the screenshot structure - Prefer reusing the project's UI component library - Keep it modern, unified, and clean - Complete state support - Reasonable whitespace and hierarchy ## Strategy C: Design Restoration For: - User provides Figma - User requests high fidelity Requirements: - Match the design as closely as possible - Keep layout, spacing, and hierarchy consistent - Prefer reusing the design system - Keep component conventions unified - Prioritize visual consistency --- # Reasonable Inference Boundaries | Allowed | NOT Allowed | |---|---| | Infer basic state transitions | Fabricate complex business rules | | Infer basic form validation | Add complete new modules without basis | | Infer list selection behavior | Define non-existent API logic | | Infer block priority relationships | Expand page beyond the screenshot | | Infer basic linkage relationships | Define system types without basis | --- # Output Format Output two parts by default. ## Part 1: Screenshot Structure Recognition Use a structured, engineering-oriented format. Tables are recommended. ### Page Overview | Item | Content | |---|---| | Page type | | | Layout method | | | Page hierarchy | | | Fixed areas | | | Scrollable areas | | --- ### Block Breakdown | Block | Components | Text/Fields | Current State | Inferred Interactions | |---|---|---|---|---| | | | | | | --- ### States & Interactions - - --- ### Implementation Intent Summarize in 2-5 sentences what this page needs to implement. --- ## Part 2: Prompt for Coding Agent The prompt must: - Be directly copyable - Be implementation-oriented - Be focused on page construction - Not be vague - Not expand into unrelated business ### Prompt Template ```md You need to implement a page (or page section) based on the provided screenshot. ### Implementation Goal Build the page structure based on the screenshot. Focus on： - Page layout - Block hierarchy - Component structure - Basic states - Basic interactions Do NOT expand into complex business logic not shown in the screenshot. --- ### Implementation Scope - Only implement content visible in the screenshot - Do NOT expand to modules not shown - If layout/header/sidebar already exists, reuse them directly - Do NOT re-implement common structures - Focus on the current screenshot area --- ### Page Structure The page contains the following areas： 1. 2. 3. --- ### Component Composition Use the following components to build the page： - - - --- ### States & Interactions The page needs to support： - - - Including： - Default state - Selected state - Disabled state - Loading state - Empty state (if applicable) --- ### Layout Requirements Note： - Fixed areas - Scrollable areas - Adaptive relationships - Block hierarchy - Page spacing and whitespace --- ### Component Split Suggestions Suggested splits： - - - Ensure clear structure for future iteration. --- ### UI Strategy <!-- Select one based on the actual situation, delete the other two --> #### Skeleton Mode - Build page skeleton first - No high-fidelity UI - Keep styles simple - Refine later #### Free UI Design - Optimize visuals based on screenshot structure - Prefer project UI component library - Modern, unified, clean - Production-ready quality #### Design Restoration - Match design as closely as possible - Keep layout and spacing consistent - Prefer design system - Visual consistency --- ### Output Requirements - Use the project's existing tech stack - Prefer reusing existing UI components - Use mock data if no API is available - Do NOT implement complex business logic - Reasonable component splits - Maintainable code ```


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)