Token导航 LogoToken导航TokenDH.com
研究检索只读github未标认证来源可访问许可证需确认审计通过

analysis-screenshot分析截图

Agent Skill

analysis-screenshot 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

315

周安装

13

GitHub Stars

26

下载量

103
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:analysis-screenshot(分析截图)
来源仓库:https://github.com/deepeshbodh/human-in-loop
仓库路径:skills/analysis-screenshot
安装命令:
npx skills add https://github.com/deepeshbodh/human-in-loop --skill analysis-screenshot
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/deepeshbodh/human-in-loop --skill analysis-screenshot

简介

从界面截图中提取设计元素与布局规范,生成可用于开发的组件定义与设计令牌。

  • 适用于构建设计系统、制作 UI 组件库或还原竞品交互细节等视觉分析任务。
  • 分八步解析截图内容,包括色彩、间距、字体与组件层级关系的量化抽取。
  • 每个提取项必须对应截图证据,缺失部分需明确标注而非猜测补全。
  • analysis-screenshot 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

Screenshot Analysis

Overview

Extract precise, implementation-ready design tokens, components, and layout structure from screenshot images through a systematic eight-phase process. Every extraction must trace back to something observed in the screenshot, and every gap must be explicitly acknowledged.

When to Use

  • Analyzing a screenshot image to extract a design system
  • Building a color palette from an existing interface
  • Cataloging components visible in a UI screenshot
  • Identifying typography scale and hierarchy from a reference app
  • Measuring spacing patterns and grid structure from a screenshot
  • Producing implementation-ready tokens from visual inspiration

When NOT to Use

  • Designing from scratch without reference screenshots
  • Working from design files (Figma, Sketch) where tokens are already exported
  • Pure interaction design without visual analysis
  • When the user provides a design system spec and needs implementation only

Phase 1: Initial Assessment

Before extracting any tokens, establish the context of the interface.

Identify and document:

AttributeWhat to Determine
PlatformMobile (iOS/Android), web (desktop/responsive), desktop app
Design languageMaterial, iOS HIG, custom, hybrid
Layout approachSingle column, multi-column, sidebar+content, dashboard grid
DensityCompact (data-heavy), comfortable (standard), spacious (marketing)
Color modeLight, dark, or mixed
Apparent eraCurrent design trends vs. dated patterns

Output format:

PLATFORM: [platform]
DESIGN LANGUAGE: [language]
LAYOUT: [approach]
DENSITY: [level]
COLOR MODE: [mode]
NOTES: [anything notable about the overall approach]

Phase 2: Color Extraction

Extract every distinguishable color. Organize by role, not by where it appears.

Extraction Process

  1. Backgrounds first -- Identify every distinct background color. Number them from darkest to lightest (or lightest to darkest in dark mode).
  2. Text colors -- Identify primary text, secondary text, muted/placeholder text, and any colored text.
  3. Interactive elements -- Buttons, links, toggles, active states. Separate primary actions from secondary.
  4. Semantic colors -- Success (green), warning (amber/yellow), error/destructive (red), info (blue). Note which are present and which are absent.
  5. Accent and brand -- The dominant brand color. Any secondary accent.
  6. Borders and dividers -- Often subtle. Zoom in mentally. Note opacity if borders appear semi-transparent.

Output Format

PRIMARY PALETTE:
  Brand Primary:    #XXXXXX  (observed in: [element])
  Brand Secondary:  #XXXXXX  (observed in: [element])

NEUTRAL PALETTE:
  Background Base:  #XXXXXX  (observed in: [element])
  Background Elevated: #XXXXXX  (observed in: [element])
  Surface:          #XXXXXX  (observed in: [element])
  Border Default:   #XXXXXX  (observed in: [element])
  Text Primary:     #XXXXXX  (observed in: [element])
  Text Secondary:   #XXXXXX  (observed in: [element])
  Text Muted:       #XXXXXX  (observed in: [element])

SEMANTIC PALETTE:
  Success:          #XXXXXX  (observed in: [element])
  Warning:          #XXXXXX  (observed in: [element])
  Error:            #XXXXXX  (observed in: [element])
  Info:             #XXXXXX  (observed in: [element])

ACCENT PALETTE:
  [role]:           #XXXXXX  (observed in: [element])

Every color entry MUST include the (observed in:...) attribution. If a semantic color is not visible in the screenshot, omit it and note its absence in the gaps section.

Phase 3: Typography Identification

Identify every distinct typographic treatment visible in the screenshot.

Extraction Process

  1. Scan top to bottom -- Note every text element, grouping by apparent visual hierarchy level.
  2. Font family -- Identify the typeface. If uncertain, provide the closest match (e.g., "appears to be Inter or similar geometric sans-serif").
  3. Size scale -- Measure relative sizes. Anchor to body text and express other sizes as ratios or estimated pixel values.
  4. Weight scale -- Note distinct weights visible (regular, medium, semibold, bold).
  5. Line height -- Estimate for body text and headings. Note whether headings use tighter line height than body.
  6. Letter spacing -- Note any visible tracking differences (tight headings, wider labels, uppercase with extra tracking).
  7. Special treatments -- Monospace for code, tabular numbers for data, italic for emphasis.

Output Format

FONT FAMILIES:
  Primary:    [family] (confidence: high/medium/low)
  Secondary:  [family] (confidence: high/medium/low)
  Monospace:  [family] (if present)

TYPE SCALE:
  Display:    ~[size]px / weight [N] / leading [N] (observed in: [element])
  Heading 1:  ~[size]px / weight [N] / leading [N] (observed in: [element])
  Heading 2:  ~[size]px / weight [N] / leading [N] (observed in: [element])
  Heading 3:  ~[size]px / weight [N] / leading [N] (observed in: [element])
  Body:       ~[size]px / weight [N] / leading [N] (observed in: [element])
  Caption:    ~[size]px / weight [N] / leading [N] (observed in: [element])
  Label:      ~[size]px / weight [N] / leading [N] (observed in: [element])
  Overline:   ~[size]px / weight [N] / leading [N] (observed in: [element])

LETTER SPACING:
  Headings: [value or "normal"]
  Labels:   [value or "normal"]
  Overline: [value or "normal"]

Mark all pixel values with ~ (approximate) unless the screenshot provides enough context for exact measurement. Note confidence level for font family identification.

Phase 4: Spacing Measurement

Extract the spacing system by identifying the base unit and its multipliers.

Extraction Process

  1. Find the base unit -- Examine the smallest repeated spacing value. Common bases: 4px, 8px. Look at icon-to-text gaps, input padding, and tight element pairs.
  2. Internal component spacing -- Padding inside buttons, cards, inputs, list items.
  3. Between-element spacing -- Gaps between sibling elements (button groups, form fields, list items).
  4. Section spacing -- Distance between major content sections.
  5. Page margins -- Outer padding of the main content area.
  6. Consistent vs. inconsistent -- Note whether spacing follows a strict scale or varies.

Output Format

BASE UNIT: [N]px

SPACING SCALE:
  2xs:  [N]px  ([base] x [multiplier]) — used for: [context]
  xs:   [N]px  ([base] x [multiplier]) — used for: [context]
  sm:   [N]px  ([base] x [multiplier]) — used for: [context]
  md:   [N]px  ([base] x [multiplier]) — used for: [context]
  lg:   [N]px  ([base] x [multiplier]) — used for: [context]
  xl:   [N]px  ([base] x [multiplier]) — used for: [context]
  2xl:  [N]px  ([base] x [multiplier]) — used for: [context]

COMPONENT PADDING PATTERNS:
  Buttons:     [top] [right] [bottom] [left]
  Cards:       [top] [right] [bottom] [left]
  Inputs:      [top] [right] [bottom] [left]
  List items:  [top] [right] [bottom] [left]

GAP PATTERNS:
  Form fields:    [N]px between fields
  Button groups:  [N]px between buttons
  Section gap:    [N]px between major sections

Phase 5: Component Cataloging

Identify and document every distinct UI component visible in the screenshot.

Extraction Process

For each component:

  1. Name it -- Use standard terminology (button, input, card, badge, avatar, tab, etc.).
  2. Count variants -- How many visual variants are visible? (primary/secondary/ghost button, filled/outlined input).
  3. Identify states -- Which states are visible? (default, hover, active, disabled, focused, selected, error).
  4. Measure it -- Height, padding, border-radius, font size, icon size.
  5. Note composition -- What sub-elements does it contain? (icon + label, avatar + name + subtitle).

Output Format

For each component:

COMPONENT: [Name]
  Variants observed: [list]
  States visible: [list]
  States NOT visible: [list — mark as gap]
  Dimensions:
    Height: ~[N]px
    Padding: [values]
    Border radius: [N]px
    Font size: ~[N]px
    Font weight: [N]
    Icon size: [N]px (if applicable)
  Colors:
    Background: #XXXXXX
    Text: #XXXXXX
    Border: #XXXXXX (if applicable)
    Icon: #XXXXXX (if applicable)
  Composition: [sub-elements]
  Notes: [anything unusual or distinctive]

Common Component Checklist

Scan for each of these. Mark present or absent:

  • Button (primary, secondary, ghost, icon-only)
  • Text input / search bar
  • Dropdown / select
  • Checkbox / toggle / radio
  • Card / panel
  • Navigation bar / header
  • Sidebar / drawer
  • Tab bar / segmented control
  • List item / row
  • Badge / tag / chip
  • Avatar / icon
  • Modal / dialog
  • Toast / notification
  • Tooltip / popover
  • Divider / separator
  • Loading / skeleton state
  • Empty state

Phase 6: Layout Structure

Document the spatial organization and visual hierarchy of the interface.

Extraction Process

  1. Grid system -- Identify columns, gutters, and margins. Note whether a standard grid (12-column) or custom layout is used.
  2. Content hierarchy -- Rank content areas by visual prominence (size, position, contrast, whitespace).
  3. Section mapping -- Divide the interface into named sections (header, sidebar, main content, footer, etc.).
  4. Visual weight -- Note where the eye is drawn first, second, third. Identify what creates that hierarchy (size, color, contrast, position).
  5. Alignment axes -- Identify the dominant alignment pattern (left-aligned, center-aligned, mixed).

Output Format

GRID:
  Type: [fixed/fluid/hybrid]
  Columns: [N]
  Gutter: ~[N]px
  Margin: ~[N]px
  Max width: ~[N]px (if constrained)

SECTION MAP:
  [Section name]: [position, approximate dimensions, role]
  [Section name]: [position, approximate dimensions, role]
  ...

VISUAL HIERARCHY (reading order):
  1. [Element/area] — draws attention via [mechanism]
  2. [Element/area] — secondary focus via [mechanism]
  3. [Element/area] — tertiary via [mechanism]

ALIGNMENT:
  Primary axis: [left/center/mixed]
  Notable breaks: [any deliberate alignment breaks]

CONTENT DENSITY:
  [Section]: [sparse/moderate/dense]

Phase 7: Border and Elevation

Document the depth strategy, border treatments, and shadow system.

Extraction Process

  1. Border radii -- Measure distinct radius values. Note which components use which radius.
  2. Border colors and widths -- Document border treatments. Note opacity if semi-transparent.
  3. Shadow values -- Identify distinct shadow levels. Estimate offset, blur, spread, and color.
  4. Elevation hierarchy -- Map which elements sit above which. Number the levels.
  5. Divider patterns -- How are sections separated? (borders, spacing, background shifts, shadows).
  6. Depth strategy -- Classify the overall approach: borders-only, subtle shadows, layered shadows, or surface shifts.

Output Format

DEPTH STRATEGY: [borders-only / subtle-shadows / layered-shadows / surface-shifts]

BORDER RADII:
  Small (buttons, inputs):  [N]px
  Medium (cards, panels):   [N]px
  Large (modals, sheets):   [N]px
  Full (avatars, pills):    [N]px (9999px / 50%)

SHADOWS:
  Level 1 (subtle):   [offset-x] [offset-y] [blur] [spread] [color]
  Level 2 (medium):   [offset-x] [offset-y] [blur] [spread] [color]
  Level 3 (elevated): [offset-x] [offset-y] [blur] [spread] [color]

BORDER TREATMENTS:
  Default: [width] [style] [color]
  Subtle:  [width] [style] [color]
  Strong:  [width] [style] [color]

ELEVATION MAP:
  Level 0: [elements at base level]
  Level 1: [elements floating above base]
  Level 2: [elements above level 1]
  Level 3: [highest elevation elements]

DIVIDER PATTERN: [description of how sections are separated]

Phase 8: Output Assembly

Compile all phase outputs into a single structured extraction document.

Assembly Process

  1. Compile all phases -- Gather outputs from Phases 1-7 into a single document.
  2. Cross-reference -- Verify color references in components match the color palette. Verify spacing values in components match the spacing scale.
  3. Resolve conflicts -- If a component's measured padding does not match the spacing scale, note the discrepancy.
  4. Document gaps -- Compile all acknowledged gaps into a single section.
  5. Add implementation notes -- For each token category, add CSS custom property suggestions or Tailwind config hints.

Gaps Section (Required)

Every extraction MUST end with an honest gaps section:

KNOWN GAPS:
  Cannot determine from static screenshot:
  - [ ] Hover states for [components]
  - [ ] Focus ring styles
  - [ ] Animation/transition properties
  - [ ] Responsive breakpoint behavior
  - [ ] Touch target sizes (if mobile)
  - [ ] Scroll behavior
  - [ ] [Other gaps specific to this screenshot]

  Low confidence extractions:
  - [ ] [Item] — reason for low confidence
  - [ ] [Item] — reason for low confidence

Never fabricate values for gaps. State what is unknown and suggest how to obtain the missing information (e.g., "inspect the live app," "request additional screenshots at different viewport widths").

Implementation Hints (Optional)

When the user intends to implement the extracted system, include a CSS custom properties mapping or Tailwind configuration snippet. See references/implementation-templates.md for starter templates.

Common Mistakes

MistakeFix
Guessing hex values instead of acknowledging approximationPrefix all color values with context; use ~ for uncertain sizes
Extracting colors without assigning rolesEvery color must have a named role (primary, secondary, border, etc.)
Listing components without measuring themEvery component needs dimensions, padding, and radius values
Ignoring the spacing systemIdentify the base unit first; express all spacing as multiples
Skipping the gaps sectionAlways document what cannot be determined from a static image
Treating all text sizes as a flat listOrganize into a hierarchical scale with named levels
Extracting shadows without noting the depth strategyClassify the overall approach before listing individual shadow values
Providing vague font identificationState confidence level; suggest closest known match

Quality Checklist

Before delivering any screenshot analysis:

Completeness:

  • All 8 phases addressed
  • Initial assessment establishes platform and context
  • Color palette organized by role with attributions
  • Typography scale uses named hierarchy levels
  • Spacing scale identifies base unit and multipliers
  • Every visible component cataloged with measurements
  • Layout structure includes grid, hierarchy, and alignment
  • Border and elevation system documented

Precision:

  • All colors include hex values
  • All sizes include pixel estimates (with ~ where approximate)
  • Font families include confidence level
  • Component specs include dimensions, padding, radius, and colors
  • Spacing values traceable to base unit

Honesty:

  • Gaps section present and populated
  • No fabricated hover/animation/responsive values
  • Low-confidence extractions flagged
  • Missing component states explicitly noted

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

33.95%
按下载量换算35

Claude

28.63%
按下载量换算29

Cursor

19.53%
按下载量换算20

Gemini CLI

8.78%
按下载量换算9

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills