Malevich

AI-Things / Prompts / Prompt/

Screen from brief

Compose a full Malevich screen — multiple sections, blocks, and elements — from a natural-language brief, choosing existing components first and flagging any genuine gaps.

generation · brief → screen · updated 2026-05-21

Use case: When you have a description of a whole screen or flow and want a Malevich-conformant layout to start from, not just one component.

When to use

You have a brief that spans more than one component:

"A settings page: a left sidebar with sections, a main panel with a profile form (name, email, avatar upload), a danger zone with a delete button that confirms in a modal, and a sticky save bar at the bottom."

Use this when the work is a screen or flow, not a single piece. If the brief is one component or one region, use component-from-brief instead — it produces tighter output for small scopes.

The prompt

Fill in the placeholders and send the text below.

You are working in the Malevich design system. Read these files before answering:

  • llm-wiki/architecture.md
  • llm-wiki/glossary.md
  • llm-wiki/playbook/semantic-html.md

Load the malevich-component-usage skill.

I want a Malevich-conformant screen for the following:

Brief: {{brief}}

Target framework: {{framework}}

Work in this order:

  1. Decompose. Break the screen into regions and name the component each maps to: sections (Hero, CTA, Site-header, Site-footer) and layouts (Block-, Split-, Grid-, Stack-layout) for structure, blocks for composites, elements for controls, overlays for anything that floats. Produce this map before any markup.
  2. Use existing components first. Reach for a new component only when no combination of existing ones fits — and if so, follow the malevich-new-component skill and call it out explicitly.
  3. Compose top-down. Page → sections/layouts → blocks → elements. Respect composition direction (an element never wraps a block; overlays don't nest in overlays).
  4. Layout with tokens. Use var(--space-gap-*) for gaps between regions and var(--space-inset-*) for padding. No raw pixels, no tier-1 references.

Constraints:

  • Standard HTML elements with BEM classes — no custom elements, no <m-*> tags (ADR-0004). Modals use native <dialog>.
  • Identity is a BEM short modifier (.block.-variant); presentation and behavior are data-{category} modifiers (data-surface, data-effect, data-behavior, data-rhythm), checked against each component's row in modifiers/applicability.json.
  • Every value via var(--token). Font tokens expand into five --font-<role>-* properties.
  • One accent action per region. State via attributes, not classes.
  • Accessibility: landmark elements (<header>, <nav>, <main>, <aside>, <footer>), real controls, visible focus.
  • If the screen needs interactive components (Dialog, Tabs, Tooltip) or any data-behavior modifier (sticky, dismissible…), note that the runtime init() must run once after mount.

Output format:

  1. Region map — the decomposition (region → component → layer).
  2. HTML — the full screen markup, top to bottom.
  3. CSS — only the layout glue not already provided by components, inside @layer malevich.components or a clearly-labelled page layer.
  4. Runtime note — which components / behaviors need init().
  5. New components needed — anything you couldn't build from existing components, with a one-line justification each.
  6. Decisions / open questions.

If two readings of the brief diverge materially, ask before writing the whole screen.

Variables

Placeholder What to fill in
{{brief}} The screen or flow description. The more you say about regions, hierarchy, and interactions, the better.
{{framework}} vanilla HTML/CSS, Astro, React, Vue. Vanilla is the default.

Tips for writing the brief

Example input

A pricing page: a hero with a headline and subhead, a three-column pricing row (cards with a feature list and a CTA each, middle card highlighted), an FAQ section using disclosure rows, and a footer.

Example output (abridged)

Region map:

hero            → Hero (section)                .hero
pricing row     → Grid-layout (section)         .grid-layout
  └ plan card   → Card (block) ×3               .card (.-feature on middle)
  └ CTA         → Button (element)              .button.-accent
faq             → Stack-layout (section)        .stack-layout
  └ row         → native <details>/<summary>    .accordion__item
cta band        → CTA (section)                 .cta
footer          → Site-footer (section)         .site-footer

HTML (abridged):

<main>
  <section class="hero">
    <h1 class="hero__title">Pricing that scales with you</h1>
    <p class="hero__lead">Start free. Upgrade when it pays off.</p>
  </section>

  <section class="grid-layout" data-rhythm="regular">
    <article class="card">…</article>
    <article class="card -feature" data-surface="elevated">
      <header class="card__header"><h3 class="card__title">Studio</h3></header>
      <div class="card__body"><!-- feature list --></div>
      <footer class="card__footer">
        <button class="button -accent">Choose Studio</button>
      </footer>
    </article>
    <article class="card">…</article>
  </section>

  <section class="stack-layout">
    <details class="accordion__item">
      <summary class="accordion__summary">Can I cancel anytime?</summary>
      <div class="accordion__panel">Yes — no contract.</div>
    </details>
  </section>

  <section class="cta">
    <h2 class="cta__title">Ready to start?</h2>
    <button class="button -accent">Create your canvas</button>
  </section>
</main>

Runtime note: the disclosure rows use native <details>, so they need no JS. Add init() if you swap them for the Accordion block's collapsible behavior, or attach any other data-behavior modifier.

New components needed: none — the screen composes entirely from Hero, Grid-layout, Card, Button, CTA, Site-footer, and native <details>.

Decisions / open questions:

Pairs with