As many of you have been asking for them, here are the prompts we used for the “What’s New” demo in Release 2.15, focused on the MCP Server and AI Workflows.
Also available in peertube: Penpot MCP Server Explained | What's new | Penpot release 2.15 - Penpot Peertube
One important thing to keep in mind: the same prompt does not guarantee the same results. The agent itself plays a huge role in the outcome.
In the video, we used Sonnet 4.6 and Opus (you can check this in the video), with no skills enabled 
PROMPTS
1- Analyze the currently focused Penpot page
## Role
You are a Senior Product Designer specialized in design systems, Penpot workflows, Penpot MCP and accessibility (WCAG AA/AAA).
You have strong experience auditing UI for consistency, scalability, and design-to-code readiness.
You do not invent product decisions, visual styles, or components that are not present in the input.
-–
## Context
You are analyzing a currently focused page from a Penpot project.
The goal is to perform a structured UI audit before making any modifications.
-–
## Goal
Produce a concise but precise audit of the current design, identifying structural patterns, system inconsistencies, and opportunities for componentization.
Do NOT redesign or modify anything yet.
-–
## Inputs
- Penpot page or frame: via Penpot MCP
- Design tokens (if available) via Penpot MCP
- Component library (if available) via Penpot MCP
- Product context: [Add product type and user goal] via Penpot MCP
-–
## Visual References
- Analyze the provided Penpot file via Penpot MCP.
- Focus on layout structure, spacing, and repetition.
- Ignore branding judgment or subjective “modernization”.
- If multiple screens are provided, compare them for consistency.
-–
## Documentation and System Rules
- Use only existing tokens if they are provided.
- Do not invent new colors, typography scales, or spacing values.
- Assume an 8pt or 4pt spacing system unless explicitly defined.
- Prefer component reuse over duplication.
- Respect accessibility standards (WCAG AA minimum).
-–
## Required Transformations
Perform an audit and explicitly identify:
1. Main layout structure
- Grid system, alignment, hierarchy, containers
2. Repeated UI patterns
- Cards, lists, forms, navigation elements, etc.
3. Candidate components
- Elements that should be extracted into reusable components
- Include potential variants if visible
4. Visual system patterns
- Colors (token usage vs inconsistencies)
- Typography (scale, roles, hierarchy)
- Spacing (patterns vs arbitrary values)
5. Accessibility and consistency issues
- Contrast problems
- Missing states (hover, focus, disabled)
- Misalignment or inconsistency across similar elements
-–
## Constraints
- Do NOT redesign the UI
- Do NOT propose new features or flows
- Do NOT introduce new navigation patterns
- Do NOT invent tokens or styles
- Do NOT produce generic or Dribbble-style suggestions
-–
## Quality Criteria
- Findings are specific, not generic
- Issues are grouped logically (not scattered observations)
- Patterns are clearly identified and named
- Component candidates are actionable (not vague)
- Accessibility issues are concrete and testable
-–
## Output Format
Create all this documetation into a new file called “design-audit-v1.md”
### 1. Layout Structure
[Concise analysis]
### 2. Repeated Patterns
[Bullet list]
### 3. Candidate Components
[Bullet list with short descriptions]
### 4. Visual System (Color, Type, Spacing)
[Structured breakdown]
### 5. Accessibility & Consistency Issues
[Bullet list]
### 6. Top 5 Recommended Improvements (Next Actions)
[Prioritized, actionable steps]
-–
## Rationale
Explain briefly:
- Why the identified issues matter
- Trade-offs or assumptions made due to missing inputs
-–
## Iteration Flow
- Wait for feedback before proposing changes
- Next step will be: component extraction or layout improvements
-–
## Negative Instructions
- Do not hallucinate missing elements
- Do not assume business goals not provided
- Do not add visual trends or stylistic opinions
- Do not ignore the existing system in favor of aesthetics
2- Infer design tokens
## Role
You are a Senior Product Designer specialized in design systems, token architecture.
You have strong experience working with Penpot and design-to-code workflows using Penpot MCP
You do not invent product decisions or visual styles beyond what is present in the input.
-–
## Context
We are working with an existing dashboard UI.
The goal is to extract a consistent design token system from the current design and then apply it safely without redesigning the product.
The current design likely contains inconsistencies, hardcoded values, and implicit patterns that need to be normalized into tokens.
-–
## Goal
1. Infer a structured design token system from the current UI.
2. Propose a clean, scalable token architecture.
3. Apply only the approved semantic color and typography tokens back to the dashboard into Penpot with minimal, reversible changes.
-–
## Inputs
- Penpot file via Penpot MCP.
-–
## Visual References
When analyzing the UI:
- Focus on: colors (backgrounds, text, borders), typography hierarchy, spacing patterns, elevation.
- Ignore: content meaning, business logic, placeholder text.
- Pay attention to inconsistencies (e.g., slightly different grays, uneven spacing).
-–
## Documentation and System Rules
- Tokens must follow a clear hierarchy: primitives → semantic → component usage.
- Do not invent new visual styles not present in the UI.
- Normalize values (e.g., merge near-identical colors).
- Typography must map to a consistent scale (no arbitrary font sizes).
- Spacing must follow a consistent step system (e.g., 4px or 8px base) or use math operations (like {token.name}*2) if its needed.
- Respect accessibility (contrast ratios must remain valid or improve).
- Assume tokens will be implemented as design tokens (e.g., CSS variables or Penpot design tokens).
-–
## Required Transformations
### Phase 1 — Token Inference
Extract and define design token sets (primitives, semantic, component usage… and then the proper design tokens:
1. **Color Primitives**
- Raw palette (e.g., gray-50 → gray-900, brand colors)
- Deduplicate similar values
2. **Semantic Colors**
- background (default, surface, elevated)
- text (primary, secondary, disabled)
- border (subtle, strong)
- states (success, warning, error, info)
3. **Typography**
- font families
- font sizes mapped to a scale
- font weights
- line heights
4. **Spacing**
- base unit and scale (e.g., 4, 8, 12, 16…)
5. **Radius**
- small, medium, large, full
6. **Shadows**
- elevation levels (e.g., sm, md, lg)
7. **Theme Mapping**
- Light theme (default)
- Dark theme (mapped using same semantic tokens)
Return ONLY token names and values in this phase. Do not apply them yet.
-–
### Phase 2 — Application
Using ONLY approved semantic color and typography tokens:
- Apply tokens to the current dashboard
- Keep layout, structure, and components unchanged
- Replace hardcoded values with design tokens (color, border radius, etc…)
- Make small, reversible improvements:
- normalize text hierarchy
- fix contrast issues if present
- align typography usage
-–
## Constraints
- Do not redesign the layout
- Do not add new components or patterns
- Do not introduce new colors beyond normalized palette
- Do not use arbitrary (magic) values
- Do not change spacing unless required for consistency
- All changes must be easily reversible
-–
## Quality Criteria
- Tokens are consistent, scalable, and reusable
- No duplicated or near-identical values
- Clear separation between primitives and semantics
- Typography scale is coherent
- Accessibility is preserved or improved
- UI remains visually very close to original
-–
## Output Format
### Phase 1 Output
- Structured token list (grouped by category)
### Phase 2 Output
- List of applied changes (before → after)
- Token replacements used
- Notes on any improvements made
-–
## Rationale
For each major decision:
- Explain why values were merged or normalized
- Explain semantic naming choices
- Highlight trade-offs or rejected alternatives
-–
## Iteration Flow
1. Return Phase 1 (design tokens only)
2. Wait for approval
3. Proceed to Phase 2 (application)
4. Refine based on feedback
-–
## Negative Instructions
- Do not produce a full redesign
- Do not create Dribbble-style visuals
- Do not assume brand guidelines that are not present
- Do not invent missing states without evidence
- Do not change layout, spacing system, or structure unless explicitly required
3- Themes
Create a new visual direction for this dashboard called “Dark".
Keep the information architecture and components intact.
Change only the theme decisions:
- semantic colors
- background hierarchy
- card surfaces
- primary and secondary actions
- chart accents
Preserve accessibility contrast.
4- Components and variants
You are a senior product designer expert in Penpot, code and Penpot MCP.
Find repeated UI patterns in this page and convert them into reusable components.
Prioritize:
- primary and secondary buttons
- metric cards
- navigation items
- status badges
- table rows
Create meaningful component names and variants where appropriate.
Do not change the visual appearance unless needed for consistency.
—
For the Button component, create variants for:
- primary
- secondary
- ghost
- destructive
And states for:
- default
- hover
- disabled
Use the existing visual language from the file.
You are a senior product designer expert in Penpot, code and Penpot MCP.
Generate a DESIGN.md file from the current Penpot file.
Include:
- design principles
- color tokens and semantic usage
- typography scale
- spacing and layout rules
- radius and elevation
- component inventory
- component usage rules
- accessibility constraints
- examples of correct and incorrect usage
Optimize it for AI coding agents.
Use concise markdown tables where useful.
6- Code generation
You are a senior frontend developer expert in Penpot, code and Penpot MCP.
Generate semantic HTML and CSS for the selected dashboard screen.
Requirements:
- use the inferred design tokens as CSS variables
- preserve spacing, typography and hierarchy
- write accessible markup
- do not use arbitrary colors or spacing values
- include comments only where they clarify token usage
- Read and use the @DESIGN.md forme more design information
- Create a UI switch to switch between Dark and Light mode (dark mode colors are also available as design tokens)
7- Storybook
You are a senior frontend developer expert in Storybook, Penpot, code and Penpot MCP.
Using the components from this dashboard design, generate Storybook stories.
Also check the "components" page looking to reproduce the components.
Include:
- default stories
- variant stories
- edge cases
- accessibility notes
- token usage notes
- Create the whole environment and files for the Storybook setup in a new folder called "Storybook"
Keep the stories aligned with the DESIGN.md file.
