---
description: Generate a hand-drawn wireframe mockup using wired-elements and push it to launch-deck for review. Use when the user wants to sketch a UI/page layout before any real implementation — sign-off material for discussion, not production HTML. Calls deck's rich-html block with framework=wired.
when_to_use: |
  Auto-fire when the user wants to SKETCH a UI/page layout as a low-fi visual artifact for review or sign-off. Trigger phrases: "wireframe", "sketch the UI for X", "mock up a page", "rough layout for X", "low-fi mockup", "what could this screen look like", "give me a sketch of the settings page", "sign-off on this layout". Deck is required because the deliverable is a rendered visual artifact the user will look at — text in the terminal cannot substitute. Do NOT auto-fire for: plain-text layout descriptions the user can read in the terminal, production component code (use /fe:* flows), polished pixel-perfect mockups (use /kit:prototype with proper styling), ASCII-art layouts in chat, or any request where the user is asking ABOUT a wireframe rather than asking FOR one.
allowed-tools:
  - mcp__launch-deck__server_status
  - mcp__launch-deck__start_server
  - mcp__launch-deck__deck
  - mcp__launch-deck__await_feedback
  - mcp__launch-chart__read_graph
  - Bash
---

# /kit:wireframe

Sketch a UI screen as a low-fi wired-elements wireframe and push it to launch-deck. The output is intentionally sketchy (the wired-elements aesthetic) — it communicates structure and information density, not final visual design.

Parse `$ARGUMENTS`:
- **description** (required) — free-form description of the screen, e.g. "settings page with three tabs: profile, billing, integrations; right rail shows recent activity". If absent, ask the user.
- **--session=<id>** — deck session name. Default `wireframe-<slugified-description-first-3-words>`.
- **--feedback** — push in `feedback` mode with `prompt: "What's missing from this layout?"` and call `await_feedback` afterward.
- **--theme=light|dark** — only set when the wireframe ONLY makes sense in one mode. Default: omit (deck's sun/moon toggle wins).

Examples:
- `/kit:wireframe settings page with three tabs: profile, billing, integrations`
- `/kit:wireframe org dashboard with KPI strip on top, project grid below --feedback`

## Preflight

1. Confirm `mcp__launch-deck__server_status` returns running. If not, call `mcp__launch-deck__start_server` first.
2. If the description is shorter than ~8 words OR mentions a real page in this repo, run `mcp__launch-chart__read_graph(type: "page", search: <hint>)` to find a similar existing page first — confirm with the user whether to mirror that page's structure or design new layout from scratch. (This is a courtesy to avoid wireframing something that already exists; skip on `--no-chart`.)

## Build the wired markup

Translate the description into a wired-elements page body. Use these elements:

| Need | Use |
|---|---|
| Container | `<wired-card elevation="2">` |
| Heading | plain `<h1>` / `<h2>` (wired-card text inherits) |
| Buttons | `<wired-button>Label</wired-button>` |
| Input | `<wired-input placeholder="…"></wired-input>` |
| Checkbox | `<wired-checkbox>Label</wired-checkbox>` |
| Dropdown | `<wired-combo>` with `<wired-item value="…">…</wired-item>` children |
| Tabs | `<wired-tabs>` with `<wired-tab name="…">…</wired-tab>` children |
| Slider | `<wired-slider min=… max=…>` |
| Divider | `<wired-divider>` |

Layout rules:
- Wrap the page in a top-level `<wired-card>` so it gets the sketched border.
- Use CSS grid (`display:grid; grid-template-columns: …;`) for multi-column layouts — inline `<style>` is fine, the deck rich-html block renders it.
- Pad generously (`padding: 24px; gap: 16px`) — the wired-elements aesthetic looks cramped without space.
- Annotate non-obvious regions with comments like `<!-- right rail: activity feed -->` so the reviewer can navigate the markup.

Do NOT include real production CSS, no Tailwind utility classes, no shadcn primitives. This is on-purpose a sketch.

## Push to deck

Call `mcp__launch-deck__deck` with:
- `session: <session>`
- `mode: "show"` (or `"feedback"` if `--feedback` was passed; also set `prompt`)
- `blocks: [{ type: "rich-html", framework: "wired", label: <short-title>, content: <body-html>, theme: <theme?> }]`

If `--feedback` was passed, immediately call `mcp__launch-deck__await_feedback` with the same session and surface the user's response back.

## Open in browser

After the push (and after `await_feedback` if `--feedback`), open the per-session URL so the user lands directly on this wireframe:

```
open "<deck-url>/#<session>"          # macOS
xdg-open "<deck-url>/#<session>"      # Linux
```

`<deck-url>` is the `url` returned by `mcp__launch-deck__server_status` (typically `http://localhost:52829`). The `#<session>` hash deep-links to this exact session — the deck-client picks it up on load and on hashchange.

## Output

```
wireframe pushed — deck session "<session>" — <deck-url>/#<session>
elements: <N> cards, <M> buttons, <K> inputs, <T> tabs
```

If `--feedback`: also print the feedback comment + any option selections, then ask what to change.

## Constraints

- **No production assets.** Don't pull real images, real fonts, real brand colors — the wired sketch IS the point. If the user asks for a "polished" mockup, suggest `/kit:prototype` instead.
- **Single block per push.** Don't split one wireframe into multiple deck blocks; one screen = one rich-html block.
- **Iterate via re-push.** Re-running with the same `--session` overwrites; that's the iteration loop.
