← ClaudeAtlas

screenslisted

Two-way screen sync with Claude Design. "prompt <flow>" writes one wireframe-level design brief per platform (docs/prompts/screens/<project>/<NNN>-<flow>/<platform>.md) — always the flow's full screen blueprint, regenerated in place, never a change note, transcribing each screen's contract-pinned components and their rules — commissioning one interactive page per flow per platform on the claude.ai/design canvas under a strict naming contract (pages <flow>--<platform>, frames named by the pinned screen codes, happy paths stitched into index--<platform>); it also maintains each platform canvas project's conventions CLAUDE.md (CLAUDE--<platform>.md — one design project per platform, generated sections regenerated, canvas-owned section preserved); the files are the deliverable, never run against the canvas; "import [flow]" reads the designed pages back as data, diffs them against the Screens contracts (components included), folds canvas-discovered conventions back into the conventions file, and routes every accep
virajp/ai-plugins · ★ 1 · AI & Automation · score 78
Install: claude install-skill virajp/ai-plugins
# screens — Design-First Screen Sync (Claude Design ⇄ Blueprint) Screens are the surface where canvas iteration beats contract prose: Claude Design nails visual and interaction nuance the blueprint's tables cannot. `prompt` writes a **wireframe-level** brief that commissions a flow's page for one platform — structure, navigation, components, and behavior; the visual design itself is made in the canvas chat — and **the file is the deliverable**: the user pastes it into the canvas chat themselves; this skill never runs a brief against the Claude Design MCP. A brief is **always the flow's full screen blueprint**, regenerated in place — never a delta note; the canvas reconciles its existing pages against the latest brief (revise-in-place). `import` brings the designed pages back and folds what they decided into the contract — **through `/vwf:blueprint`, one confirmed delta at a time**. The blueprint stays the contract of record; the canvas is where screens get good. **The naming contract is the join key.** Three levels: - **Pages** — the canvas unit is **one interactive page per flow per platform**, at the project root, named `<flow>--<platform>` (`020-signin--mobile`, `100-home--auto`, …) — `<flow>` is exactly the numbered folder name under `docs/blueprint/flows/<project>/` for the registry project this canvas is pinned to, so the canvas sorts in execution order like the blueprint tree. The platform suffix (`mobile`, `tablet`, `desktop`, `web`, `auto`) is read **s