FrancoStino/design-philosophy

Design philosophy

When to Use

Use this skill when you need visual philosophy and art-direction for frontend. Use when creating high-concept work, campaigns, or when the user asks for a visual philosophy, manifesto, or unmistakable art-like aesthetic.

Apply with design for high-concept work, campaigns, or when the user asks for a visual philosophy, manifesto, or art-like aesthetic. This skill guides creating a named movement and expressing it visually.

Visual philosophy (when creating "art" or high-concept work)

1. Name the movement (1–2 words): e.g. "Brutalist Joy," "Chromatic Silence," "Metabolist Dreams."
2. Articulate in 4–6 paragraphs how the philosophy manifests through: space and form; color and material; scale and rhythm; composition and balance; visual hierarchy. Avoid redundancy; each aspect once.
3. Craftsmanship: Stress that the work should look meticulously crafted, labored over with care, the product of deep expertise — "painstaking attention," "master-level execution." Repeat this framing.
4. Minimal text: Information lives in design, not paragraphs. Text sparse and essential; integrated as visual element.
5. Creative space: Be specific about direction but concise so the executor can make high-level interpretive choices with the same level of craft.

For philosophy examples, see reference.md. The numbered checklist above is the canonical generation procedure.

Deducing the subtle reference

Before building: identify one subtle conceptual thread from the request. The topic is a subtle, niche reference embedded in the work — not literal, always sophisticated. Someone familiar with the subject should feel it intuitively; others experience a strong abstract composition. Weave it into form, color, and composition. "Jazz quote" principle: only those who know catch it; everyone benefits.

Limitations

• Use this skill only when the task clearly matches its upstream source and local project context.
• Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
• Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.