Ui flow agent skills
Professional Agent Skills for analyzing UI flows from annotated screenshots and markdown documentation. Generate automation-ready specifications for AI agents. Compatible with Cursor, Claude, and custom AI systems.
npx -y skills add boweneos/ui-flow-agent-skillsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Analyze annotated UI screenshots and markdown documentation to generate agent-consumable UI flow specifications. Use when processing web app UI flows described via markdown + screenshots into structured, automation-ready knowledge.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
6.4 KB, as published. Nobody here has run it
Multimodal UI Flow Analyzer
This skill enables you to analyze static web app UI flows described via markdown + annotated screenshots and output agent-consumable knowledge for downstream AI code agents.
When to Use This Skill
Activate this skill when:
- Processing UI documentation that includes annotated screenshots
- Converting visual UI flows into structured automation specs
- Generating test automation guidance from UI walkthroughs
- Creating machine-readable UI interaction sequences
Core Workflow (7 Steps)
Step 1: Normalize Input Markdown
Before analysis, ensure each UI step follows this structure:
## Step N: <Short Title>
**Intent:**
What the user is trying to accomplish.
**User Action (Text):**
Plain-language description of the interaction.
**Visual Reference:**

**Visual Annotations:**
- Box / arrow / highlight descriptions
If the input doesn't follow this format, restructure it first.
Step 2: Apply Vision-Aware Analysis Rules
When analyzing screenshots:
- Identify interactive UI elements (buttons, inputs, menus, links)
- Map visual annotations (boxes, arrows, highlights) to UI elements
- Infer user intent from both text and visual cues
- Ignore decorative elements that are non-interactive
- Assume static UI (no animations or runtime state changes)
Step 3: Process Each Step Atomically
Analyze one step at a time, never the entire document at once.
For each step, extract:
- The UI element being interacted with
- Its visual characteristics and location
- Its technical role in the web application
- Preconditions and resulting state
Step 4: Treat Annotations as Ground Truth
Annotation Priority Rules:
- Highlighted areas are authoritative targets
- Prefer annotated elements over textual ambiguity
- If text and image conflict, image evidence wins
Map annotations explicitly:
{
"annotation_mapping": {
"red_box": "Primary action button",
"arrow": "Cursor movement direction",
"highlight": "Target input field"
}
}
Step 5: Generate Structured Output
Produce output in the canonical format (see templates in assets/templates/).
Per-Step JSON Format:
{
"step_id": "step-N",
"intent": "Description of user goal",
"action": "click|type|select|scroll|hover",
"ui_element": {
"type": "button|input|link|menu|dropdown",
"label": "Visible text or aria-label",
"visual_location": "Position description",
"identification_strategy": [
"visible text equals 'X'",
"role=button",
"data-testid='element-id'"
]
},
"precondition": "Required state before action",
"resulting_state": "Expected state after action"
}
Flow Markdown Format:
# UI_FLOW: <flow_name>
## Metadata
- App: <Application Name>
- Flow Type: Static UI Interaction
- Source: Annotated screenshots + human-authored text
---
## Step 1
**Intent:** <goal>
**Action:**
- type: <action_type>
- target:
- role: <element_role>
- text: "<visible_text>"
- location: <position_description>
**Preconditions:**
- <required_state>
**Postconditions:**
- <resulting_state>
**Automation Notes:**
- <selector_recommendations>
Step 6: Add Automation Hints
For each step, include:
-
Stable DOM selectors (prefer semantic)
role=button+ visible textdata-testidattributesaria-labelvalues
-
Brittle selectors to avoid
- Pixel-based positions
- Absolute CSS selectors
- Dynamic class names
-
Wait conditions
- Elements to wait for before action
- Loading states to handle
Step 7: Validate the Output
Before finalizing, verify:
- All steps have clear preconditions
- Step ordering is logical and complete
- No ambiguous UI references remain
- Each action has a defined resulting state
- Selectors are stable and semantic where possible
Output Templates
Use templates from assets/templates/:
| Template | Purpose |
|---|---|
step-output.json | Single step structured output |
flow-output.md | Complete flow specification |
automation-hints.md | Test automation guidance |
Example Interaction
Input: User provides markdown with annotated screenshot showing a "Create Project" button highlighted with a red box.
Analysis Process:
- Parse step structure from markdown
- Identify red box annotation → maps to button element
- Extract button text: "Create Project"
- Determine location: "top-right of main content area"
- Infer action type: click
- Define precondition: "User is on Projects dashboard"
- Define postcondition: "Project creation modal opens"
Output:
{
"step_id": "step-2",
"intent": "Create a new project",
"action": "click",
"ui_element": {
"type": "button",
"label": "Create Project",
"visual_location": "top-right of main content area",
"identification_strategy": [
"visible text equals 'Create Project'",
"role=button"
]
},
"precondition": "User is on Projects dashboard",
"resulting_state": "Project creation modal opens"
}
Edge Cases
Ambiguous Annotations
If multiple elements are highlighted, process them in visual reading order (top-to-bottom, left-to-right).
Missing Screenshots
If a step lacks a visual reference, flag it and proceed with text-only analysis. Note reduced confidence in output.
Complex Multi-Element Interactions
For drag-and-drop or multi-select, describe both source and target elements with separate identification strategies.
Dynamic Content
If the UI shows dynamic content (lists, tables), describe the interaction pattern rather than specific instances.
Constraints
- DO NOT assume backend logic or API behavior
- DO NOT infer state beyond what's visible
- DO NOT generate pixel coordinates as primary selectors
- ALWAYS prefer semantic selectors over structural ones
- ALWAYS document uncertainty when present