reverse-wireframe-ui

Files (3)

• SKILL.md
• openai.yaml · agents/
• evals.json · evals/

SKILL.md (first lines)

# Reverse Wireframe UI

Create structured draw.io wireframes from existing app screenshots by identifying UI elements, cross-referencing with source code (any framework), and producing annotated `.drawio` + `.png` deliverables.

Works with any UI framework: React Native, SwiftUI, Flutter, Vue, Angular, web apps, etc. The drawio output is framework-agnostic — only the code cross-reference phase is framework-specific.

## When to Use

- User provides screenshots/mockups and wants wireframe diagrams
- Documenting an existing app's UI structure for handoff or re-implementation
- Creating visual specs from a running app or design screenshots
- Need to map screenshot elements to actual component names in code
- Migrating between frameworks (e.g. React Native → SwiftUI) and need a visual spec as bridge

## Workflow

```dot
digraph wireframe_flow {
  rankdir=TB;
  "1. Inventory screens" -> "2. Vision analysis";
  "2. Vision analysis" -> "3. Code cross-reference";
  "3. Code cross-reference" -> "4. Build drawio XML";
  "4. Build drawio XML" -> "5. Export PNG";
  "5. Export PNG" -> "6. Visual comparison";
  "6. Visual comparison" -> "4. Build drawio XML" [label="differences found"];
  "6. Visual comparison" -> "7. Done" [label="matches"];
}
```

## Phase 0: Pre-flight Checks

Before processing screenshots, verify they fit within Claude's vision limits:

1. **Check dimensions**: Run `identify -format "%wx%h  %f\n" *.png` (ImageMagick) on all screenshots
2. **Resize if needed**: If any dimension exceeds **1568px**, resize: `mogrify -resize "1568x1568>" *.png`
   - Claude's recommended max is 1568px on the longest side
   - 2000px is the hard limit for multi-image requests
   - iPhone @3x screenshots (1170x2532) **always** need resizing
3. **Verify**: Re-check dimensions after resize to confirm all are within limits

Skip this phase only if you've confirmed all images are already ≤1568px.

## Phase 1: Inventory Screens

Glob the screenshot directory. Name each screen by its file name pattern:
- `Screen - Main.png` = main/default state
- `Screen - Main - Filter Active.png` = variant with a filter selected
- `Screen - Detail Popup.png` = popup/modal overlay

Group screens by base state vs. variants vs. overlays. Variants share most elements with the base — only document the delta.

## Phase 2: Vision Analysis

Read each screenshot with the `Read` tool (LLM vision). For each screen, identify **top-to-bottom**:

1. **Status bar** (OS chrome)
2. **Navigation bars** (utility bar, header)
3. **Scrollable content sections** (cards, lists, filters)
4. **Floating elements** (FABs, overlays)
5. **Tab bars** (bottom navigation)

For each element, note:
- **Visual role**: pill, card, badge, text label, icon button, separator
- **Content**: actual text/values shown
- **Color**: fill, border, text colors (use hex from the screenshot)
- **State**: active/inactive, selected/unselected, expanded/collapsed
- **Grouping**: which elements are visually contained in panels/cards

## Phase 3: Code Cross-Reference

**If no codebase is visible in the current working directory, ask the user:** "Is there source code available for this app? If so, where?" — the wireframe is much more useful when element names map to real component names.

If code is available, search for component names that map to visual elements. This phase is framework-agnostic — adapt the search strategy to the tech stack. If no code exists, use generic descriptive names (e.g. `category-filter-pills`, `provider-bar`, `stats-card`).

### Searching large files

App entry points can be enormous (2MB+). Never try to read the whole file — it will exceed token limits. Instead:

1. **Grep for imports first** — find component names used on the screen
2. **Grep for render functions / template sections** — search by visible text strings from the screenshot
3. **Read targeted offsets** — once you find the line number, read ±40 lines around it
4. **Read the imported component files** — they're usually small and self-contained

**React / React Native example:**
```bash
grep "import.*from" app/(tabs)/index.tsx | head -30
grep "ITEMS FOUND\|FEATURED\|renderHeader\|renderMainTabs" app/(tabs)/index.tsx
```

**Vue / Nuxt example:**
```bash
grep "<template>\|<script.*setup>\|defineComponent" pages/index.vue
grep "ITEMS FOUND\|FeaturedCard\|CategoryFilter" components/**/*.vue
```

**SwiftUI example:**
```bash
grep "struct.*View\|var body" Sources/Views/*.swift
grep "Text(\"ITEMS FOUND\")\|NavigationStack" Sources/Views/HomeView.swift
```

**Flutter example:**
```bash
grep "class.*Widget\|build(BuildContext" lib/screens/*.dart
grep "'ITEMS FOUND'\|FeaturedCard\|CategoryFilter" lib/screens/home_screen.dart
```

### Build a mapping table

| Visual Element | Component/Function | File |
|---|---|---|
| Category filter pills | `renderCategoryTabs()` / `CategoryFilterBar` | `app/(tabs)/index.tsx` |
| Provider chips | `<ProviderBar compact />` | `src/components/ProviderBar.tsx` |
| Metric card | `<MetricCard compact />` | `src/components/metrics/MetricCard.tsx` |
| Bottom tab bar | Tab layout config | `app/(tabs)/_layout.tsx` |

This mapping goes into the annotation panel of the wireframe.

**CRITICAL — This mapping also drives Phase 4 layer definitions.** Each component/function in the mapping table becomes a drawio layer. Do NOT proceed to Phase 4 without this table complete. When dispatching sub-agents for parallel wireframe generation, the mapping table must be completed first and included in each agent's prompt.

From DimmKirr/skills, MIT.

More from DimmKirr/skills