AI apps · Prompts and creative workspaces

# Design reference: Leonardo — Creative home
Source: https://app.leonardo.ai/
Swipefile reference: https://swipefile.design/ref/ai-leonardo-home/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- surface: A signed-out creative home with a prompt composer, tool shortcuts and visual discovery cards.
- nav: A narrow left sidebar lists creation tools and library routes.
- layout: A wide prompt area sits above featured tools and a community-image gallery.
- density: Moderate density with image-led cards and compact controls.
- color: Dark surfaces with varied colorful artwork.
- typography: Bold introductory text and small functional labels.
- pattern: Combine a prominent prompt composer with examples that help users choose a creative task.
- states: Public signed-out home; no generation submitted or private library accessed.
- dont: Adapt the layout to your own product and supported capabilities; write your own examples and keep important actions clearly labeled.

Useful for: Combine a prominent prompt composer with examples that help users choose a creative task.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Adobe Firefly — Creative home
Source: https://firefly.adobe.com/
Swipefile reference: https://swipefile.design/ref/ai-adobe-firefly-home/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- surface: A signed-out creative dashboard with a multimodal prompt composer and visual tool cards.
- nav: A persistent left sidebar groups media types and workspace features.
- layout: A wide composer shows upload, media type, model and output controls above a row of large tool tiles.
- density: Moderate density with a clear central creation area.
- color: White and light grey with colorful media thumbnails and dark action buttons.
- typography: Bold heading and compact sans-serif control labels.
- pattern: Keep model and output controls inside the composer while offering visual shortcuts to related tasks.
- states: Public signed-out starting state; no image uploaded or generation submitted.
- dont: Adapt the layout to your own product and supported capabilities; write your own examples and keep important actions clearly labeled.

Useful for: Keep model and output controls inside the composer while offering visual shortcuts to related tasks.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Bolt — Prompt entry
Source: https://bolt.new/
Swipefile reference: https://swipefile.design/ref/ai-bolt-start/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- surface: An AI app-builder starting screen with a central prompt and project-type shortcuts.
- nav: Top navigation covers product resources and account entry.
- layout: A centered headline leads into a dark prompt panel and compact starter shortcuts.
- density: Low density, focused on the first task.
- color: Dark surfaces over a luminous blue background.
- typography: Bold sans-serif headline and small prompt controls.
- pattern: Give the main prompt visual priority and offer concrete starting categories underneath.
- states: Public starting screen; no prompt submitted or project created.
- dont: Adapt the layout to your own product and supported capabilities; write your own examples and keep important actions clearly labeled.

Useful for: Give the main prompt visual priority and offer concrete starting categories underneath.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: v0 — Prompt entry and templates
Source: https://v0.app/
Swipefile reference: https://swipefile.design/ref/ai-v0-start/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- surface: An AI builder pairs an empty prompt composer with suggested tasks and a template gallery.
- nav: Slim top navigation provides templates, enterprise and account entry.
- layout: Centered composer above a row of starter ideas, followed by a three-column template gallery.
- density: Sparse at the top, more visual and dense in the gallery.
- color: White and light grey with black controls and varied template imagery.
- typography: Small sans-serif labels and a concise bold heading.
- pattern: Offer both a freeform prompt and template-based starts on the same entry screen.
- states: Signed-out public entry; templates are visible, but no generation or deployment was initiated.
- dont: Adapt the layout to your own product and supported capabilities; write your own examples and keep important actions clearly labeled.

Useful for: Offer both a freeform prompt and template-based starts on the same entry screen.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Gemini — New conversation
Source: https://gemini.google.com/app
Swipefile reference: https://swipefile.design/ref/ai-gemini-start/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- surface: A signed-out assistant entry screen with a single centered composer and model control.
- nav: Minimal links and sign-in action occupy the top edge.
- layout: A centered greeting sits above a compact rounded prompt field in an otherwise open viewport.
- density: Very low density with one dominant input.
- color: White with soft blue and pastel atmospheric gradients.
- typography: Simple sans-serif greeting and small control labels.
- pattern: Make the first input unmistakable and keep secondary controls inside the composer.
- states: Empty signed-out conversation; no message sent.
- dont: Adapt the layout to your own product and supported capabilities; write your own examples and keep important actions clearly labeled.

Useful for: Make the first input unmistakable and keep secondary controls inside the composer.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Grok — New conversation
Source: https://grok.com/
Swipefile reference: https://swipefile.design/ref/ai-grok-start/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- surface: An assistant’s public starting screen uses a compact composer beneath a short invitation.
- nav: Small account actions stay in the upper corners.
- layout: A narrow centered composer is surrounded by generous whitespace.
- density: Very low density.
- color: White and pale grey with dark text and controls.
- typography: Small restrained sans-serif text.
- pattern: Reduce the initial chat screen to a clear prompt field and a few contextual controls.
- states: Signed-out new-conversation state; no prompt submitted.
- dont: Adapt the layout to your own product and supported capabilities; write your own examples and keep important actions clearly labeled.

Useful for: Reduce the initial chat screen to a clear prompt field and a few contextual controls.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.

# Design reference: Luma Dream Machine — Sign in
Source: https://dream-machine.lumalabs.ai/
Swipefile reference: https://swipefile.design/ref/ai-luma-dream-machine/
Captured: 2026-09-05. This is a dated reference, not a claim about the current live product.
Capture scope: one viewport. Do not infer unseen page sections or a complete user flow.

## Objective
Adapt the interaction and layout patterns below to my project. Use my own content and identity. Do not reproduce logos, proprietary copy, or brand assets.

## Reference notes
- surface: A creative-AI sign-in screen pairs immersive media with a compact authentication panel.
- nav: A small brand mark precedes the entry options.
- layout: Large cinematic imagery fills the left side; a black right column holds a short introduction and provider buttons.
- density: Sparse, with three clearly grouped sign-in options.
- color: Warm cinematic footage, black background and white buttons.
- typography: Simple sans-serif heading and compact supporting copy.
- pattern: Use product imagery to establish context while keeping authentication choices easy to scan.
- states: Public Google, Apple and enterprise sign-in choices; no authentication performed.
- dont: Adapt the layout to your own product and supported capabilities; write your own examples and keep important actions clearly labeled.

Useful for: Use product imagery to establish context while keeping authentication choices easy to scan.

## Acceptance criteria
- Existing project conventions, design tokens, working functionality, and unrelated changes are preserved.
- Two or three reference principles clearly support the user's task; conflicts are resolved in favor of usability and the existing product.
- Reusable components and semantic HTML express the interface. Available licensed assets are used; important UI text is never rendered as a bitmap.
- Every visible control has a defined behavior. Loading, empty, error, success, disabled, and long-content states are specified where relevant. Demo data is clearly labeled.
- Navigation and content adapt at 375px, 768px, and 1440px without horizontal page overflow. Keyboard use, visible focus, labeled inputs, at least 44px touch targets, readable contrast, and reduced motion are supported.
- Verification distinguishes rendered behavior from proposals and identifies anything still requiring a backend or external service.

## Quality bar
Clear hierarchy, consistent spacing, restrained surfaces, and purposeful motion. Avoid decorative gradients, excessive cards, placeholder buttons, and invented metrics unless the project calls for them. Do not claim a feature is connected or tested without evidence.