com um clique
design
// Enforces precise, minimal design for dashboards and admin interfaces. Use when building SaaS UIs, data-heavy interfaces, or any product needing Jony Ive-level craft.
// Enforces precise, minimal design for dashboards and admin interfaces. Use when building SaaS UIs, data-heavy interfaces, or any product needing Jony Ive-level craft.
Selects and applies professional journalistic story structures (WSJ Formula, Inverted Pyramid, Hourglass, Tick-Tock, etc.) based on the content being written. Use when writing articles, blog posts, features, essays, long-form content, news stories, trend pieces, investigative reports, profiles, or any narrative prose longer than a few paragraphs. Also use when the user asks for help structuring a piece, choosing a story framework, organizing a draft, outlining an article, or wants to know which article format fits their content. Trigger on requests like "help me structure this," "what format should I use," "write a feature about," "draft a blog post on," or any mention of story structure, article architecture, or narrative frameworks. Complements the writer skill (which handles tone and anti-AI rhetoric) by providing the structural blueprint.
Writing style and tone guide for human-sounding content. Use when writing documentation, READMEs, commit messages, PR descriptions, blog posts, LinkedIn posts, social media content, or any user-facing content.
Guides clean, scalable system architecture during the build phase. Use when designing modules, defining boundaries, structuring projects, managing dependencies, or preventing tight coupling and brittleness as systems grow.
Executes implementation plans with smart task grouping. Groups related tasks to share context, parallelizes across independent subsystems.
Prevents silent failures and context loss in error handling. Use when writing try-catch blocks, designing error propagation, reviewing catch blocks, or implementing Result patterns.
Guides database architecture decisions for PostgreSQL, DuckDB, Parquet, PGVector, and Neo4j. Use when designing schemas, choosing storage strategies, optimizing queries, tuning maintenance, configuring vector search, modeling graph data, or diagnosing performance issues across OLTP, OLAP, similarity search, and graph workloads.
| name | design |
| description | Enforces precise, minimal design for dashboards and admin interfaces. Use when building SaaS UIs, data-heavy interfaces, or any product needing Jony Ive-level craft. |
Core philosophy: Every interface should look designed by a team that obsesses over 1-pixel differences. Not stripped, crafted. And designed for its specific context.
AI-generated UIs have a recognizable "median of the internet" feel. Polished but generic, like everything was designed by the same committee. Break out of that by making deliberate choices instead of reaching for defaults.
AI default patterns to actively avoid:
| AI default | Why it happens | Do this instead |
|---|---|---|
| Indigo/purple gradients | Tailwind's bg-indigo-500 saturated training data | Choose an accent color that fits the product's emotional job |
| Inter or system fonts everywhere | Statistically safest choice | Pick typography that matches the product personality (see Choose Typography below) |
| Three-column icon grid | Every SaaS landing page template uses this | Vary card layouts by content type. Metric cards, feature cards, and testimonial cards should look different from each other |
| Centered hero + CTA button | The default starting point for every landing page | Consider what the user actually needs first. Maybe it's a dense dashboard, a split layout, or content-forward with no hero at all |
| Uniform border-radius on everything | rounded-lg applied without thinking | Pick a radius system and vary it by component role (sharp for data, softer for interactive) |
| White/light gray background + subtle shadow cards | The safest possible surface treatment | Commit to a depth strategy that matches the product (see Depth Strategy below) |
| Decorative gradients on hero sections | Looks "modern" without communicating anything | If using gradients, make them functional (show hierarchy, direct attention) not decorative |
The test: If you swapped your brand name with a competitor's and the design still works, it's too generic. Something about the color foundation, typography, spacing rhythm, or layout density should feel specific to this product.
Controlled imperfection creates character. Perfect symmetry and uniform spacing everywhere reads as machine-generated. Human-designed interfaces have intentional asymmetry: a sidebar slightly narrower than expected, a headline that breaks the grid for emphasis, whitespace that breathes unevenly to create visual rhythm. These are deliberate choices, not sloppiness.
Before writing code, commit to a direction. Don't default. Think about what this specific product needs to feel like.
| Direction | Feel | When to Use |
|---|---|---|
| Precision & Density | Tight spacing, monochrome, info-forward | Power users who live in the tool. Linear, Raycast, terminal aesthetics. |
| Warmth & Approachability | Generous spacing, soft shadows, friendly | Products that want to feel human. Notion, Coda, collaborative tools. |
| Sophistication & Trust | Cool tones, layered depth, gravitas | Products handling money or sensitive data. Stripe, Mercury. |
| Boldness & Clarity | High contrast, dramatic negative space | Modern, decisive products. Vercel, minimal dashboards. |
| Utility & Function | Muted palette, functional density | Work matters more than chrome. GitHub, developer tools. |
| Data & Analysis | Chart-optimized, technical but accessible | Analytics, metrics, business intelligence. |
Pick one. Or blend two. But commit to a direction that fits the product.
Color foundation (don't default to warm):
Light or dark? Dark feels technical, focused, premium. Light feels open, approachable, clean. Choose based on context.
Accent color: ONE that means something. Blue = trust. Green = growth. Orange = energy. Violet = creativity.
Internal layouts should vary by content. A metric card doesn't have to look like a plan card doesn't have to look like a settings card. One might have a sparkline, another an avatar stack, another a progress ring.
Surface treatment stays consistent: same border weight, shadow depth, corner radius, padding scale.
Never use native form elements for styled UI. Native <select>, <input type="date"> render OS-native elements that cannot be styled. Build custom components.
Custom select triggers: display: inline-flex with white-space: nowrap to keep text and icons on same row.
Screens need grounding:
When building sidebars, consider using same background as main content. Linear, Vercel use subtle border for separation rather than different backgrounds.
Never:
0 25px 50px...)Different products want different things. A dev tool wants precision and density. A collaborative product wants warmth and space. A financial product wants trust and sophistication.
Same quality bar, context-driven execution.
Detect which styling approach the project uses, then load the matching reference:
| Project uses | Load |
|---|---|
| Vanilla CSS, CSS Modules, styled-components, or no Tailwind | references/craft-css.md |
| Tailwind CSS | references/craft-tailwind.md |
If unclear, check for tailwind.config or @tailwind directives in the project. Default to CSS if neither is found.