Magic Patterns

View saved version →

---
name: inspiration
description: Explore several distinct UI design directions for a screen or component in Magic Patterns (magicpatterns.com). First recreates the current UI as a faithful baseline, then creates a shareable magicpatterns.com/inspiration/<id> document and streams in four self-contained HTML concepts tuned to the kind of exploration wanted (entrypoint/discoverability, information architecture/navigation, or visual display). The hosted comparison link is the deliverable. Use when the user wants design inspiration, alternative directions, layout options, variations, or a "show me a few approaches" exploration before committing to an implementation.
---

# Inspiration

Explore **four parallel design directions** for a target screen or component. This skill recreates a faithful **baseline** of the current UI, **creates a placeholder `magicpatterns.com/inspiration/<id>` document up front**, then generates **four concepts** and **streams each one directly into the document** via subagents. The hosted comparison link is the deliverable, and publishing is required, not optional.

Concepts are pushed straight into the document through the `inspiration_add_variant` MCP tool as each subagent finishes — **no concept HTML files are written to disk, and the concept HTML never round-trips through the main agent's context.** This is what keeps the flow fast and avoids the timid "publish a placeholder concept and hope to fix it later" failure mode.

The goal is **bold, grounded divergence**. Pin the product down ONCE using its real content and its real design tokens (colors, fonts, spacing, SVGs), then make the four concepts **meaningfully different from each other**: different layout philosophies, arrangements, or product framings, not four shades of the same idea. Every concept inherits the baseline's tokens so it still looks like the same product; the design *direction* is the only axis that changes.

## Prerequisites

- The Magic Patterns MCP server must be connected (tools prefixed `magic-patterns`). Publishing uses two tools: `create_inspiration_document` (creates the placeholder document + returns the link and one id per concept) and `inspiration_add_variant` (fills a single concept in with its HTML). Iterating on an existing document (see "Iterating on an existing document" below) uses `get_inspiration_document` (loads the current concepts + baseline), `inspiration_clear_variants` (resets all concepts for a full replace), and `inspiration_update_variant` (revises one concept in place). If the tools are unavailable, tell the user to install/enable the Magic Patterns plugin or MCP server.
- Publishing requires a Magic Patterns account; an authentication error from either tool means the user needs to sign in / connect the MCP server.

## When to use

- **This skill (`inspiration`)**: the user wants several directions to compare before committing — layout/IA exploration, alternative visual treatments, "give me options".
- `prototype`: the user already knows what they want and wants to build/iterate one concrete idea.
- `upload-to-magic-patterns`: just mirror local UI into a hosted design, no concepts.
- `integrate-magic-patterns-design`: bring a chosen concept back into the codebase as production code.

## Output contract

The deliverable is a hosted **`magicpatterns.com/inspiration/<id>` link** that renders the four concepts side by side. You obtain the link **up front** by creating a placeholder document (Step 3), then each concept is filled in via `inspiration_add_variant` (Step 4) — the page shows a loading tile per concept until its HTML arrives, then flips to ready once all four are in.

The **only** local file this skill writes is the baseline, into a temporary working directory (create one with `mktemp -d`; refer to it below as `$TMP`):

```
$TMP/<Target>-inspiration/
└── baseline.html            # faithful recreation of the current UI (grounds the concepts; also uploaded as the document's baseline)
```

Concepts a

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: integrate-magic-patterns-design
description: Adapt code generated by Magic Patterns (magicpatterns.com) into an existing codebase. Use when the user shares a Magic Patterns design, prototype, exported zip, "Copy Code as Prompt" output, or a magicpatterns.com URL and wants it implemented, integrated, or productionized in their project. Treats the Magic Patterns code as a design spec, not as code to copy verbatim.
---

# Integrate a Magic Patterns Design

Magic Patterns generates **prototypes**. The code you receive is a high-fidelity design spec — it shows layout, hierarchy, spacing rhythm, interactions, and intent. It is NOT meant to be pasted into a codebase as-is.

**The golden rule: when the Magic Patterns code and the target codebase disagree, the codebase wins.** Reproduce the *design*, not the exact code. Always prefer the codebase's existing components, design tokens, styling system, data layer, and conventions over the literal values in the prototype.

## What Magic Patterns code looks like

Unless the design used a custom design system, expect:

- React 18 + TypeScript, styled with **Tailwind CSS v3** utility classes
- **lucide-react** icons, **framer-motion** animations, **react-router-dom** routing, **recharts** charts
- Named exports (`export function PricingSection`), flat or shallow file structure (`components/`, `pages/`, `utils/`)
- **Hardcoded mock data** — inline arrays/objects or a `utils/mockData.ts`
- Placeholder images as full URLs (often Unsplash)
- Stubbed interactivity: controlled inputs with local `useState`, `onSubmit` handlers that do nothing real, no API calls, no auth, no backend
- Zip/GitHub exports are wrapped in a standalone Vite project (`vite.config.ts`, `index.html`, `src/`)

Designs built on a design system preset (shadcn/ui, Chakra, Mantine, MUI) or a custom imported design system will use that library's components and theming instead of plain Tailwind.

## Workflow

### Step 1: Inventory the prototype

Read all the Magic Patterns files first. Identify:

- The actual design content: components, layout, screens, interactions, states (hover, empty, loading, error if present)
- Mock data shapes — these hint at the real data model the UI expects
- Which parts are scaffolding to discard (see checklist below)

**Discard checklist** — never port these:

- [ ] `index.tsx` / `index.html` / `vite.config.ts` / `tsconfig*.json` / `postcss.config.js` / `package.json` / `.eslintrc*` — Vite scaffolding; your project already has its own
- [ ] `tailwind.config.js` and `index.css` — merge any genuinely new tokens into your existing config instead of replacing it
- [ ] `canvas.manifest.js`, `useScreenInit.js` — Magic Patterns multi-screen plumbing; replace with your real router
- [ ] `ComponentPreview.tsx`, `components.config.json`, `context.md` — editor preview files
- [ ] `_designSystem/` folders and empty component stub files — precompiled design system bundles
- [ ] `data-id` props on elements — editor instrumentation
- [ ] `utils/mockData.ts` and inline mock data — replace with your real data layer

### Step 2: Survey the target codebase

Before writing anything, learn how this codebase builds UI. Find:

1. **Framework and routing** — Next.js App Router? Pages Router? Remix? Plain Vite + react-router? Match its conventions for pages, layouts, links, and navigation.
2. **Component library** — Look for an existing `components/ui/`, design system package, or shared component folder. List the available primitives (Button, Input, Card, Dialog, Select, Badge, Table...).
3. **Styling system** — Tailwind (which version? v4 syntax differs from the v3 the prototype uses), CSS Modules, styled-components, vanilla-extract, a token system? Find the theme: colors, spacing, radii, typography, breakpoints.
4. **Icons** — Which icon library is already installed? Do not add lucide-react if the project uses something else.
5. **Data and state** — How does this codebase fetch data (React Query, SWR, server compone

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: prototype
description: Prototype an idea in Magic Patterns (magicpatterns.com) starting from your local UI. Use when the user gives a prompt for something they want to prototype or explore and wants an iterable Magic Patterns design grounded in their existing code. Seeds a design by recreating the relevant local UI (recreate-as-react) and uploading it, then prompts Magic Patterns to design the new idea, returns the editor link, and opens it in the browser. Requires the Magic Patterns MCP server.
---

# Prototype an idea in Magic Patterns

Use this skill when the user has an idea they want to **prototype** and wants it grounded in the UI they already have. It seeds a Magic Patterns design from the relevant local UI, then prompts Magic Patterns to design the idea, hands back the editor link, and opens it in the browser.

It composes two mechanisms, used **in order, for different jobs** — not interchangeably:

- **Seed (deterministic):** recreate the relevant *existing* local UI with `recreate-as-react` and write it into a blank design (the `upload-to-magic-patterns` flow). This recreates what already exists — it does NOT build the new idea.
- **Prototype the idea (creative):** once seeded and published, use `send_prompt` to let Magic Patterns design the net-new idea. This is where the prototyping happens — let Magic Patterns do the creative heavy lifting; don't hand-build it.

Direct file writes *after* seeding are reserved for precise, deterministic tweaks (rename a label, swap a color, port one specific local component) — never for generating the new concept.

Magic Patterns renders **visual prototypes**, not production apps — local code must be ported to its constraints (handled by `recreate-as-react`; see `upload-to-magic-patterns`).

## Prerequisites

- The Magic Patterns MCP server must be connected (tools prefixed `magic-patterns`). If the tools are unavailable, tell the user to install/enable the Magic Patterns plugin or MCP server, and stop.
- Magic Patterns MCP usage requires a paid plan. A `Payment Required` / credits error means the user must upgrade at `magicpatterns.com/settings`.

## When to use

- **This skill (`prototype`)**: the user wants to prototype or evolve an idea grounded in their existing UI, and iterate on it.
- `upload-to-magic-patterns`: just mirror local UI into a hosted design, no iteration.

- `integrate-magic-patterns-design`: bring a Magic Patterns design back into the codebase as production code.

## Links: always hand back the editor link

Designs created via the MCP server use normal Magic Patterns access controls. Return the editor link and tell the user to open it in their browser; they may need to log in.

`create_design` returns two URLs:

- **`editorUrl`** (`…/c/<editorId>`) — the editor. **This is what you give the user to view or edit the prototype.**
- **`previewUrl`** (`project-<slug>.magicpatterns.app`) — an optional rendered preview URL. Do not rely on it as the primary no-login link.

Always return the `editorUrl`.

## Workflow

The two mechanisms are sequential and do different jobs: **seed** recreates existing UI deterministically, then **prompt** lets Magic Patterns design the new idea. Do them in this order.

### Step 1 — Clarify the goal and pick the seed (existing UI only)

From the user's prompt, work out (a) the idea they want to prototype and (b) the smallest existing screen/component it builds on. Keep the seed scope minimal — just enough existing UI to ground the prototype, not the whole app, and not the new feature.

### Step 2 — Seed: recreate the existing local UI in Magic Patterns

**Run the `upload-to-magic-patterns` skill** on the seed scope to mirror the relevant local UI into a fresh design. It does the whole seed for you — ports the UI with `recreate-as-react` (into a temp dir), then `create_design` → `get_design_status` → `write_artifact_files` → `publish_artifact`, and cleans up the temp dir. **Keep the `editorId` and `editorUrl` it returns** for th

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: recreate-as-raw-html
description: Recreate a component, screen, or pasted code from any codebase as a single self-contained raw HTML file (Tailwind Play CDN + web fonts) that faithfully reproduces its styling, colors, spacing, and fonts. Use when the user asks for a "raw HTML recreation", an "HTML version" of a component, "make an HTML copy of X", or references a component/screen by name (e.g. "Take the <ComponentName> and give me raw HTML").
---

# Recreate as raw HTML

Turn a component, screen, or pasted snippet into **one self-contained `.html` file** that opens standalone in a browser and reproduces the original's styling as faithfully as possible.

**Method: static.** Read the source and resolve its design tokens by inspection — do NOT run the app, Storybook, or a browser. Fidelity comes from carefully tracing whatever styling system the codebase uses down to concrete values, then re-expressing them in Tailwind.

This works for **any codebase**. The styling system varies (Tailwind, CSS/SCSS, CSS Modules, styled-components / Emotion, vanilla-extract, a design-system library like Radix/MUI/Chakra/Mantine/shadcn, or plain inline styles). Step 2 is about identifying which one is in play and following the chain to real pixel/color/font values.

## Output contract

Produce a single HTML document:

- Tailwind via the Play CDN: `<script src="https://cdn.tailwindcss.com"></script>`
- Font `<link>`s / `@import`s in `<head>` for the fonts the source uses
- Static markup only — no React/Vue/framework, no build step. Add JS only for trivial visual behavior if the user asks; otherwise omit it.
- Save as `./<ComponentName>.html` (or next to where the user is working) and hand back the path.

## Workflow

### Step 1 — Locate the source (use subagents to explore)

**First, harvest what's already in the parent agent's entire available thread context — don't re-explore what the agent already knows.** Reusable context can come from anywhere in the thread, not only this skill: previous user requests, manual exploration, earlier subagent results, pasted code, open/referenced files, or prior implementation work.

Build a concise in-memory resolved context brief for the target component source, imported SVGs/design-system rendering, theme tokens/colors, fonts, and image assets. Mark each concern **complete**, **partial**, or **missing**. Only count a concern as complete when the thread contains the concrete values it needs (verbatim `<svg>` markup, concrete hex, px/rem, font families/weights, real asset paths), ideally with source-file provenance. Reuse complete concerns directly without re-reading their files merely to verify them. For partial concerns, preserve the known values and investigate only the unresolved delta. Re-explore a complete concern only when there is evidence it became stale, such as relevant files being edited later in the thread. If everything needed is already in context, skip exploration entirely and go straight to Step 2 assembly.

For whatever remains partial or missing, you MUST delegate the codebase exploration to `explore` subagents via the Task tool — do not read/grep the files yourself. Subagents do not inherit the parent agent's thread context, so include the relevant resolved context brief, exact known values, and citations in every prompt, and ask only for the unresolved delta. Launch them with the `gpt-5.4-mini` model (fast, read-only), fanned out concurrently in a single batch, then do the HTML assembly yourself with what they return. Split the remaining work, e.g.:

- One subagent finds the target component file(s) and lists its subcomponents / styled wrappers.
- One subagent **follows the component's imports into design-system/workspace packages and `node_modules`** (monorepo sibling packages, `@scope/*` packages) and, for every imported UI symbol (icons, logos, illustrations, bespoke SVG components), opens its real source and returns the **exact `<svg>` markup / asset path** — not a description. F

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: recreate-as-react
description: Recreate a component, screen, or pasted code from any codebase as a self-contained React + TypeScript + Tailwind prototype (App.tsx / index.tsx / index.css, named exports, one component per file) that renders in the Magic Patterns prototype environment and faithfully reproduces the original's styling, colors, spacing, and fonts. Use when the user asks for a "React recreation", a "React version" of a component, "recreate X as React", or as the porting engine for the upload-to-magic-patterns and prototype skills.
---

# Recreate as React

Turn a component, screen, or pasted snippet into a **self-contained React + TypeScript + Tailwind prototype** — a small set of files that compiles and renders standalone (in the **Magic Patterns prototype environment** or any React sandbox) and reproduces the original's styling as faithfully as possible.

**Method: static.** Read the source and resolve its design tokens by inspection — do NOT run the app, Storybook, or a browser. Fidelity comes from carefully tracing whatever styling system the codebase uses down to concrete values, then re-expressing them in Tailwind (or the source's own props/tokens).

This works for **any codebase**. The styling system varies (Tailwind, CSS/SCSS, CSS Modules, styled-components / Emotion, vanilla-extract, a design-system library like Radix/MUI/Chakra/Mantine/shadcn, or plain inline styles). Step 2 is about identifying which one is in play and following the chain to real pixel/color/font values.

## Where this runs — the Magic Patterns environment

The file set this skill produces is exactly the scaffold Magic Patterns renders (`App.tsx`, `index.tsx`, `index.css`, `tailwind.config.js`), so it can be written straight into a Magic Patterns design. Conform to that environment so the upload compiles and renders:

- **React + TypeScript. No `any`** — define prop types/interfaces.
- **Named exports only** — never `export default` a React component.
- **One React component per file**; split large screens into sub-components rather than a monolith.
- **Tailwind CSS v3** — use it for net-new UI; for reproduced UI, prefer the source's own styling (see Step 2). Keep the `index.css` imports in the exact order below.
- **Icons:** `lucide-react` is available (import full names ending in `Icon`, e.g. `UserIcon`). For fidelity, inlining the **exact `<svg>` markup copied 1:1 from source** is preferred and also compiles in MP — never guess or redraw an icon.
- **Routing** (only if needed): `BrowserRouter` from `react-router-dom`.
- **Fonts:** `@import url(...)` in `index.css` — never `next/font`.
- **Images:** **absolute URLs only** (the original remote URL or the project's served URL) — app-relative paths won't resolve.
- **Package preferences when applicable:** `sonner` (toasts), `recharts` (charts), `@xyflow/react` (node/canvas), Leaflet (maps). Avoid `@react-three/fiber` / `@react-three/drei`.
- **The code must compile** — no unresolved imports, missing symbols, or type errors. If a dependency is unavailable, stub it locally so it still compiles.

## Output contract

Produce a **folder of React files** (default `./<ComponentName>/`). Keep it self-contained so it compiles and renders with no backend.

### Files to emit

```
<ComponentName>/
├── App.tsx              # entry component — renders the recreated UI
├── index.tsx            # standard mount (ReactDOM root → <App/>)
├── index.css            # Tailwind imports (exact order below) + fonts/tokens
├── tailwind.config.js   # any resolved custom colors/spacing/fonts
├── <ComponentName>.tsx  # the recreated component (named export)
├── components/          # sub-components, one per file (as needed)
└── mockData.ts          # hardcoded mock data (as needed)
```

`index.css` must keep these in **this exact order** — never reorder or remove them:

1. `@import url(...)` font imports (if any)
2. `@import 'tailwindcss/base';`
3. `@import 'tailwindcss/components';`
4. `@import 'tailwindcss

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: upload-to-magic-patterns
description: Upload UI you are building locally into Magic Patterns (magicpatterns.com) and return the editor link. Use when the user wants to push a component/screen they are working on in their codebase into Magic Patterns as a design — for review, stakeholder sign-off, or further iteration. Requires the Magic Patterns MCP server.
---

# Upload local UI to Magic Patterns

Use this skill to push UI from the current codebase into a **hosted Magic Patterns design** and hand back the editor link. You port the local UI into a Magic Patterns-ready React file set with the `recreate-as-react` skill, then **write those files into a blank design directly** — you do not prompt Magic Patterns to generate anything. The destination is a real Magic Patterns design, created through the Magic Patterns MCP server.

Magic Patterns renders **visual prototypes**, not production apps. Local production code will not run there as-is — it must be ported to Magic Patterns' constraints first. `recreate-as-react` does that port; this skill wires the result into a design.

**Keep the scope minimal.** Upload only what the user wants to prototype — the specific component or screen and the smallest set of files needed to render it. This is not a tool for mirroring the whole app; a tighter upload compiles more reliably and is faster to iterate on.

## Prerequisites

- The Magic Patterns MCP server must be connected (tools prefixed `magic-patterns`). If the tools are unavailable, tell the user to install/enable the Magic Patterns plugin or MCP server, and stop.
- Magic Patterns MCP usage requires a paid plan. A `Payment Required` / credits error means the user must upgrade at `magicpatterns.com/settings`.

## Workflow

### Step 1 — Pick the minimal scope to prototype

Identify the specific component(s) or screen the user wants to prototype, and the smallest set of files needed to render it. Do not pull in the whole app — keep the upload tight to what the user actually wants to see.

### Step 2 — Port to a Magic Patterns-ready file set (run `recreate-as-react`)

Run the **`recreate-as-react`** skill to turn the target into a self-contained React + TypeScript + Tailwind file set (`App.tsx`, `index.tsx`, `index.css`, `tailwind.config.js`, component files). That skill already targets the Magic Patterns environment and carries the fidelity rules that make the upload look right — follow it in full. In particular it:

**Emit into a temp dir, not the project.** Tell `recreate-as-react` to write the file set into a temporary working directory (`mktemp -d`, referred to as `$TMP`) so nothing is left behind in the user's repo — this skill reads those files and writes them into the design, then deletes `$TMP` (Step 4).

### Step 3 — Create a blank design and upload the files directly

Create a blank design and write the ported files into it. **Do not use `send_prompt` or any AI generation** — write the files yourself. Use the Magic Patterns MCP tools in this order:

1. `create_design` with no prompt → "start from scratch": returns `editorId`, the active `artifactId` (a blank scaffold: `App.tsx`, `index.tsx`, `index.css`, `tailwind.config.js`), and the `editorUrl`. This returns immediately.
2. `get_design_status(editorId)` → confirm the active `artifactId` and that `isGenerating` is false.
3. `write_artifact_files(artifactId, files)` → write the ported files from `$TMP` directly. Include `App.tsx` as the entry component and update `index.css` if you added fonts/tokens.
4. `publish_artifact(artifactId, editorId)` → compiles and activates the artifact so the preview renders.

If you need to preserve the original scaffold as a separate version, call `create_new_artifact(artifactId, name)` before writing and use the returned artifact ID for the writes.

### Step 4 — Hand back the link, open it, and clean up

Return the `editorUrl` to the user so they can keep iterating in Magic Patterns, and tell them they may need to log in. If `publish_art

Preview of the first 4,000 characters. Read full instructions →