dills122 Hallmark Design
Adapted from Nutlope/hallmark, commit aeb42fb354ff4efa36ab475773a082315a3af2ce, MIT.
Use this as an opt-in creative-direction workflow. It complements the general frontend skills; it is not the default for ordinary application UI, dashboards, forms, or small component changes.
Modes
- Build: create a new page whose structure and visual language fit the actual brief.
- Audit: inspect existing UI and return a ranked visual/UX punch list. Do not edit.
- Redesign: preserve routes, copy intent, information architecture, and existing ownership; change only the visual and interaction layer in scope.
- Study: extract portable design DNA from a user-provided screenshot or a public reference URL. Describe structure, type, colour, spacing, imagery, and interaction patterns. Never pixel-clone, copy a paid template, or reproduce protected artwork.
If the user supplies only a screenshot or URL, ask whether they want a study or a fresh build inspired by it.
Before Editing
- Identify whether this is a page or a component. For a component, follow the existing project system and verify relevant states; do not invent a page-wide visual system.
- Inspect the repository for its framework, design tokens, type stack, spacing scale, component library, responsive conventions, and motion support.
- State the files expected to change. Do not delete routes, production components, or asset directories without explicit confirmation.
- Preserve the existing system unless the user explicitly asks for a new visual direction.
Build Principles
- Choose the layout from the content and user task. Do not default to the same hero, three-card grid, testimonial strip, and CTA sequence.
- Make one clear visual direction: establish a deliberate type hierarchy, palette, spacing rhythm, image treatment, and interaction tone before implementation.
- Use named project tokens. Add a named token before using a new colour, font, radius, shadow, or spacing value; do not scatter raw values through components.
- Do not fabricate metrics, testimonials, customer logos, awards, pricing claims, or product screenshots. Use supplied facts, clearly labelled placeholders, or a structure that does not require invented proof.
- Prefer real content and assets. Do not draw fake browser, phone, IDE, or code-window chrome around content.
- Avoid generic AI visual tells: arbitrary purple/indigo, decorative gradients or blobs, excessive rounded cards, uniform card grids, shadow-heavy surfaces, and ornamental motion without purpose.
- Keep headings upright; use hierarchy, weight, scale, colour, or decoration—not italic display text—for emphasis.
Quality Floor
- Verify 320 px, 375 px, 414 px, and desktop/tablet widths. No horizontal overflow; long words, images, grids, and buttons must remain contained.
- Use semantic HTML and visible keyboard focus. Interactive UI includes appropriate default, hover, focus, active, disabled, loading, error, empty, and success states when relevant.
- Respect
prefers-reduced-motion; motion must clarify state or hierarchy, not just decorate. - Check contrast, labels, keyboard access, and tap targets.
- For a design audit, rank findings by user impact and cite files or visible elements. For an implementation, verify in a real browser when available.
Final Review
Before handing off, assess:
- Does the page's structure fit this specific content rather than a familiar template?
- Is the hierarchy obvious at a glance and in the narrow layout?
- Are tokens, states, accessibility, and responsive behavior implemented rather than merely described?
- Did we avoid invented proof and decorative imitation UI?
- Would a second page for a different brief plausibly look structurally different?