Configuring Layout and Visual Density Constraints as a Frontend Quality Enforcement Layer
Teaches you how to write grid, container, and density rules inside SKILL.md files so AI coding agents produce tighter, more intentional page compositions instead of the loosely spaced, single-column defaults they gravitate toward.
Define explicit grid column counts, container max-widths, section padding scales, and minimum content-to-whitespace ratios inside your SKILL.md file. Specify numeric breakpoints for each viewport tier, ban full-width single-column defaults above tablet, and set density tokens that force the agent to pack content intentionally. This creates a frontend quality enforcement layer that replaces the agent's generic spacing instincts with precise compositional rules.
Outcome: Your AI agent stops producing loosely spaced, single-column layouts and instead generates pages with intentional grid structures, controlled whitespace, and professional visual density that match production-quality design standards.
Prerequisites
- Basic understanding of CSS Grid and Flexbox layout models
- Familiarity with responsive breakpoints and container queries
- A working SKILL.md file already installed in your AI coding agent (see installing-skill-files-in-ai-coding-agents)
- Comfort reading and editing markdown instruction files
Overview
AI coding agents like Cursor, Claude Code, Codex, and v0 share a consistent bias: they default to generous padding, single-column stacking, and symmetrical whitespace that produces layouts resembling wireframes more than finished products. The visual density of professionally designed pages, where content fills the viewport with purpose and rhythm, is something these agents rarely achieve unprompted. This skill teaches you to write the specific layout and density constraints inside SKILL.md files that override those defaults and function as a frontend quality enforcement layer between the agent's output and your design standards.
Within the Taste Skill Frontend Design Framework, layout and density constraints sit at the structural foundation. Typography rules (covered in enforcing typography and spacing standards) govern the micro-level text relationships, while layout constraints govern the macro-level page composition: how many columns a section uses, how wide containers stretch, how much vertical space separates blocks, and how densely content fills available area. Without these constraints, agents make safe choices. Safe choices look like every other AI-generated landing page on the internet.
The concrete artifact you produce is a layout constraint block inside your SKILL.md file, typically 40-80 lines of markdown rules covering grid definitions, container maximums, section padding scales, density ratios, and viewport-specific overrides. Once this block exists, every page the agent generates passes through these rules before output. The result is measurable: you can compare the content-to-whitespace ratio of pages generated with and without constraints and see the difference immediately. Pages move from 30-40% content density (the typical agent default) to 55-70% density (the range where professional marketing sites, dashboards, and editorial layouts operate). You are not removing whitespace. You are making whitespace intentional rather than accidental.
This skill pairs directly with writing anti-slop design review rules, which catches violations after generation, while density constraints prevent violations during generation. Think of density constraints as the proactive half and review rules as the reactive half of the same quality system.
How It Works
AI agents generate layouts by pattern-matching against their training data, which skews heavily toward boilerplate templates, documentation sites, and tutorial projects. These sources share characteristics: wide padding, centered single columns, generous vertical gaps between sections, and few multi-column compositions. When you ask an agent to "build a landing page," it reproduces these patterns because they are statistically dominant in its training corpus. The agent is not making a design decision. It is making a probability decision.
Layout and density constraints work by replacing probability with instruction. Instead of letting the agent decide how wide a container should be (it will pick something safe like max-w-3xl or 768px), you specify: "Container max-width is 1280px for marketing pages and 1440px for dashboards." Instead of letting it choose padding (it will pick py-16 or py-24 because those appear most frequently in component libraries), you specify: "Section vertical padding follows the scale 48px, 64px, 80px and never exceeds 80px." The agent follows explicit instructions over implicit patterns every time.
The mental model is constraint-based design, borrowed from print layout and industrial design. A newspaper page is dense because the grid is specified in advance: column count, gutter width, margin size, and minimum story height are all defined before any content is placed. The content fills the structure rather than the structure expanding to accommodate content. Your SKILL.md density rules create the same dynamic. You define the grid first, and the agent places content within it.
Density itself is the ratio of meaningful content area to total viewport area. Professional marketing sites typically operate at 55-70% density. Dashboards push higher, 65-80%. Editorial layouts sit around 50-65% with intentional negative space for readability. Agent defaults cluster around 30-45%, which is why AI-generated pages feel "empty" even when they contain plenty of content. The content is there, but it is swimming in unstructured whitespace.
The constraints you write fall into four categories. Grid rules define column counts and gutter widths per viewport tier. Container rules set max-widths and horizontal padding. Spacing rules establish vertical rhythm between sections and within sections. Density rules set minimum content-to-whitespace ratios and ban specific anti-patterns like full-width hero sections with a single centered headline and nothing else.
This system works within the Taste Skill Frontend Design Framework because SKILL.md files are read by the agent at prompt time. The constraints are not compiled, transpiled, or enforced at runtime. They are instructions the agent follows during code generation. This means the constraints must be unambiguous. Vague instructions like "use tighter spacing" fail because the agent has no numeric anchor. Precise instructions like "section padding-y must be 48px, 64px, or 80px, selected based on content volume within the section" succeed because the agent can evaluate and comply.
One important nuance: density constraints should vary by page type. A pricing page needs different density than a blog post, which needs different density than a settings panel. Your SKILL.md file should include a page-type lookup that maps each template category to its density target. This prevents the agent from applying dashboard-level density to a long-form article, which would feel cramped, or article-level density to a dashboard, which would feel empty.
Step-by-Step
Step 1: Audit your current agent output for layout patterns
Before writing constraints, you need to see what your agent actually produces when unconstrained. Generate three to five representative pages using your current setup: a marketing landing page, a feature detail page, a pricing page, and a dashboard or app screen if relevant. Do not provide any layout guidance in the prompt. Simply describe the content and let the agent choose the layout.
Examine each output and record the following measurements: container max-width in pixels, number of columns used above 1024px viewport, vertical padding between sections in pixels, and the approximate ratio of content area to total viewport area. You can estimate content-to-viewport ratio by taking a screenshot at 1440px wide and using any image editor to calculate the percentage of pixels occupied by content versus background or padding. Record these numbers in a simple table. This baseline tells you exactly where the agent's defaults land and how far you need to push them.
Tip: Most agents will produce pages where vertical padding between sections is 2-4x larger than it needs to be. If you see consistent py-20 or py-24 (80-96px) between sections, your constraint file should cap section gaps at 64-80px and establish smaller values for related subsections.
Step 2: Define your target density ranges by page type
Create a page-type density map that specifies the content-to-viewport ratio target for each category of page your agent will generate. Start with three to five page types. Marketing landing pages should target 55-65% density. Product feature pages should target 60-70%.
Pricing and comparison pages should target 65-75% because they are data-dense by nature. Blog and editorial pages should target 50-60% to preserve reading comfort. Dashboard and app interfaces should target 65-80%. " Each row should include the page type, the target density percentage range, the rationale in one sentence, and the maximum number of consecutive single-column sections allowed before the agent must break into a multi-column layout.
Tip: The 'maximum consecutive single-column sections' rule is one of the highest-impact constraints you can set. Limiting it to two forces the agent to introduce visual variety through side-by-side comparisons, feature grids, or image-text pairings. Without this rule, agents will stack ten single-column blocks in a row.
Step 3: Specify grid rules per viewport tier
Define explicit column counts and gutter widths for each responsive breakpoint. Use four tiers: mobile (under 640px), tablet (640-1023px), desktop (1024-1439px), and wide (1440px and above). For each tier, specify the maximum column count available, the gutter width in pixels, and any column-span rules. For example: "Desktop tier uses a 12-column grid with 24px gutters.
Content sections must use at least 2 columns. " For mobile, specify that content stacks to a single column but maintains the same gutter width scaled to 16px. Write these as numbered rules, not prose paragraphs. Agents parse numbered rules more reliably than embedded instructions within paragraphs.
Tip: Specify column counts as minimums for content sections, not maximums. Agents naturally minimize columns. If you say 'up to 4 columns,' the agent will use 1. If you say 'minimum 2 columns for feature sections above 1024px,' the agent complies.
Step 4: Set container max-width and horizontal padding rules
Define container constraints that prevent the two most common agent failures: containers that are too narrow (centering 768px of content in a 1440px viewport) and containers that are too wide (stretching content edge-to-edge with no margins). Specify a primary content container width, typically 1200-1280px for marketing pages and 1400-1440px for dashboards. Specify horizontal padding that scales per breakpoint: 16px on mobile, 24px on tablet, 32-48px on desktop. Add a rule that full-bleed sections (background color or image extending to viewport edges) must still contain an inner container at the standard width.
This prevents the agent from creating full-bleed sections where the text also stretches edge-to-edge, which is a common failure mode. Write the container rules as a constraint block with clear if-then logic: "If page type is marketing, container max-width is 1280px.
Tip: Add an explicit ban on max-w-prose and max-w-3xl for non-article pages. These Tailwind utilities are deeply embedded in agent training data and will override your container rules if the agent reaches for familiar classes. State: 'Do not use max-w-prose or max-w-3xl on marketing, product, or dashboard pages.'
Step 5: Establish vertical spacing scales and section rhythm
Define a spacing scale that the agent must use for vertical gaps between sections, between elements within a section, and between a heading and its content. Use a constrained scale rather than allowing arbitrary values. A good production scale for section gaps is 48px, 64px, 80px. For intra-section element gaps, use 16px, 24px, 32px.
For heading-to-content gaps, use 8px, 12px, 16px. md file with the rule: "All vertical spacing must use values from this scale. " Then add contextual rules: "Adjacent sections with related content use the smallest section gap (48px). Adjacent sections introducing a new topic use the medium gap (64px).
" This creates vertical rhythm. The agent can no longer dump py-24 on every section indiscriminately.
Tip: Include a rule that inner padding within cards, panels, and contained elements follows a separate, smaller scale (12px, 16px, 20px, 24px). Without this, agents apply section-level padding inside cards, creating cards that are 60% padding and 40% content.
Step 6: Write anti-pattern bans for common density failures
List the specific layout anti-patterns your agent must avoid. These are explicit bans, not suggestions. Base them on the patterns you identified in Step 1. " Write each ban as a numbered rule with the banned pattern described specifically enough that the agent can check its own output against it.
Vague bans like "avoid too much whitespace" will be ignored. Specific bans like "no section may have padding-y exceeding 80px" will be followed.
Tip: Frame bans in terms of measurable properties whenever possible. 'Too much padding' is subjective. 'Padding-y must not exceed 80px' is checkable. Agents comply with checkable rules at a much higher rate.
Step 7: Add viewport-specific density overrides
Your density rules need breakpoint awareness. What works at 1440px wide does not work at 375px wide, and agents frequently apply desktop density targets to mobile, creating cramped mobile layouts, or mobile density targets to desktop, creating empty desktop layouts. Add a "Responsive Density Overrides" section that specifies behavior per tier. For mobile: "Content stacks to single column.
Section padding-y reduces to 32px and 48px. " For tablet: "Feature grids use 2 columns minimum. " For wide desktop: "Feature grids may use 3 or 4 columns. Content container increases to dashboard width if page type warrants it.
" These overrides prevent the agent from generating responsive layouts that technically work at each breakpoint but feel wrong because the density is inconsistent across them.
Tip: Add a specific rule for the 1024-1280px range, which is where most density problems compound. This is the range where agents cannot decide between tablet and desktop behavior and often produce awkward 2-column layouts with excessive horizontal gaps. Specify: 'At 1024-1280px, use 2-column layouts with 24px gutters and no horizontal padding beyond 32px per side.'
Step 8: Test constraints by regenerating your baseline pages
md file. Use identical prompts so the only variable is the presence of constraints. Take screenshots at 1440px viewport width and compare side by side with the originals. Measure the same metrics: container width, column count, section padding, and content-to-viewport ratio.
You should see container widths increase from the 768-900px range to your specified 1200-1280px range. Column counts should increase from 1 to 2-4 on content sections. Section padding should decrease from 80-96px to 48-64px. Content density should rise from the 30-45% range to the 55-70% range.
If any metric has not moved meaningfully, the corresponding constraint is either too vague or conflicts with another instruction. Revise the specific rule, make it more explicit or numeric, and regenerate.
Tip: If the agent partially follows constraints but reverts to defaults in some sections, check whether your constraint rules are at the top or bottom of the SKILL.md file. Agents weight instructions near the top of context more heavily. Move your layout constraints above typography and motion rules if density is your primary concern.
Step 9: Calibrate and version your constraint file
After testing, refine values that produced results that are too tight or still too loose. Calibration is an iterative process. You may find that 48px minimum section padding feels too compressed for certain content types, in which case adjust the scale to 56px, 64px, 80px for that page type. " Once calibrated, add a version number and date to your constraint block so you can track changes over time.
Store previous versions in a changelog comment block at the bottom of the section. This prevents regression when team members edit the file later.
Tip: Create a 'known exceptions' subsection listing cases where the agent should relax density rules. Common exceptions: full-screen onboarding flows, error states, empty states, and single-action confirmation pages. Without exceptions, the agent will try to densify pages that genuinely need breathing room.
Examples
Example: SaaS marketing landing page for a small startup
A three-person startup uses Claude Code to generate landing pages for their project management tool. Their current output has a centered hero with a single headline, a single-column feature list, and 96px padding between every section. The page scrolls for five full viewport heights despite containing only moderate content. They want a denser, more professional layout that fits comfortably within three viewport heights at 1440px.
The team audits their current output and records: container width 768px, column count 1, section padding 96px, content density approximately 32%. They define a marketing page density target of 60-65%. Their constraint block specifies container max-width 1280px, section padding scale of 48px/64px/80px, and a minimum 2-column grid for feature sections on desktop. They add an anti-pattern ban: 'Hero sections must contain at minimum a heading, subheading, CTA button, and either a product screenshot, feature highlights, or social proof.
' They ban py-24 and py-20 utility classes explicitly. After regeneration, the hero contains a headline, subheading, CTA, and product screenshot in a 2-column layout. Features appear in a 3-column grid. Section padding dropped to 48-64px.
The page now fits within three viewport heights at 1440px. Content density measures 61%. The total constraint block is 52 lines of markdown. 0 and commits it alongside their codebase.
Example: Enterprise SaaS dashboard with multiple data panels
A mid-size B2B company with a 12-person engineering team uses Cursor to generate internal dashboard views. Their agents produce dashboards with one data card per row, 32px gaps between cards, and 48px page margins, resulting in dashboards where users must scroll extensively to see KPIs that could fit on one screen. The design team specifies that dashboards should show 6-8 KPI cards above the fold at 1440px.
md file. Container max-width is set to 1440px with 24px horizontal padding. The grid uses 12 columns with 16px gutters. KPI cards must use a 4-column span (3 cards per row) or 3-column span (4 cards per row) depending on the total number of KPIs.
Card inner padding is capped at 16px horizontal and 12px vertical. Section gaps between dashboard zones (KPIs, charts, tables) use 24px. The anti-pattern bans include: 'Do not render KPI cards at full row width. Do not add vertical padding exceeding 24px between dashboard sections.
' After regeneration, the dashboard renders 8 KPI cards in two rows of four, followed by a 2-column chart zone, all visible above the fold at 1440px without scrolling. Content density measures 74%. The team adds a conditional exception for dashboard empty states, which are allowed to use centered single-column layout with a call-to-action for adding data.
Example: B2C e-commerce category page generated by v0
A direct-to-consumer brand uses v0 to prototype category pages for their online store. The agent produces product grids with 2 columns, large card gaps, and oversized product images that push most products below the fold. The merchandising team wants 12-16 products visible above the fold at 1440px to maximize browse engagement.
The team writes a 'Product Grid Layout' constraint block. Container max-width is 1320px. Product grids use 4 columns on desktop with 20px gutters, 3 columns on tablet, and 2 columns on mobile. Product card inner padding is 12px.
Product image aspect ratio is constrained to 1:1 or 4:5, not free-height. Card height is controlled by setting a max-height on the image container rather than letting images dictate card size. Filters and sort controls sit in a horizontal bar above the grid, not in a sidebar that steals a column. The anti-pattern ban states: 'Do not use 2-column product grids on desktop viewports.
Do not add margins exceeding 20px between product cards. ' After regeneration, the category page shows 16 products in four rows of four above the fold. Content density is 68%. The page feels like a professional e-commerce experience rather than a prototype.
The team extends the constraint block with a 'Product Detail Page Layout' subsection that uses a 2-column layout (image gallery left, product info right) at 55-60% density to give shoppers room to evaluate individual items.
Example: Technical documentation site for an open-source library
An open-source project uses Codex to generate documentation pages. The output has extremely narrow content columns (640px), no sidebar navigation on desktop, and 80px section padding between every documentation block. The maintainers want a layout that includes persistent sidebar navigation on desktop, wider content areas for code examples, and tighter vertical spacing so developers can scan quickly.
The maintainers create an 'Editorial / Documentation Layout' constraint block targeting 50-60% content density. Container max-width is 1280px. Desktop layout uses a 2-column structure: 280px fixed sidebar for navigation and remaining width for content. Content column max-width for prose is 780px.
Code blocks are allowed to expand to the full content column width (approximately 960px) to avoid horizontal scrolling. Section padding scale is 32px/48px/56px, smaller than marketing pages to support scanning. The heading-to-content gap is 8px for H3 and 12px for H2. The anti-pattern bans include: 'Do not center documentation content without a sidebar on desktop.
Do not use section padding exceeding 56px. ' After regeneration, documentation pages render with a persistent left sidebar, wide code examples, and tight vertical rhythm. Developers can see approximately 40% more content per viewport compared to the previous output. Content density measures 55%.
The maintainers add a mobile override that collapses the sidebar into a hamburger menu and reduces section padding to 24px/32px.
Best Practices
Write every constraint as a numeric rule rather than a qualitative description. 'Container max-width is 1280px' succeeds. 'Use a reasonable container width' fails. AI agents interpret qualitative instructions by falling back to their training data defaults, which is exactly what you are trying to override.
Numeric rules leave no room for interpretation and produce consistent results across regenerations.
Separate your constraints by page type using clearly labeled subsections. A pricing page and a blog post have fundamentally different density requirements. If you write one universal set of rules, the agent will either cramp your blog content or leave your pricing page half-empty. Use markdown headers like '### Marketing Page Layout' and '### Editorial Page Layout' so the agent can locate the relevant block based on the page type in the prompt.
Test constraints at 1440px viewport width as your primary validation resolution. This is the width where density problems are most visible because there is enough horizontal space for the agent's spacing defaults to create obvious emptiness. If your layout looks properly dense at 1440px, it will typically look good at smaller widths where content naturally compresses. If you only test at 1024px, you will miss density issues that appear on larger monitors.
Include explicit column-count minimums rather than maximums for content-heavy sections. Agents default to fewer columns because single-column layouts require less compositional judgment. Saying 'minimum 2 columns for feature grids on desktop' forces multi-column thinking. Saying 'up to 4 columns' does not, because 1 is technically 'up to 4.'
Update your density constraints quarterly or whenever you ship a major design change. Agent behavior shifts as models are updated, and constraints that worked perfectly with one model version may produce different results after an update. A quarterly review where you regenerate your baseline pages and compare against previous outputs catches drift early before it compounds across dozens of generated pages.
Co-locate layout constraints with the spacing token definitions they reference. If your spacing scale is defined in one section and your section padding rules reference those tokens two hundred lines later, the agent may lose context. Place the scale definition immediately above the rules that use it. Proximity in the instruction file directly correlates with compliance rate.
Document the 'why' behind each constraint in a brief inline comment. Agents sometimes override rules when they perceive a conflict with another instruction. Adding '(prevents the single-column hero stacking pattern that makes pages look like wireframes)' after a rule gives the agent context for resolving ambiguity in favor of your constraint rather than its defaults.
Version-control your SKILL.md file alongside your codebase. Layout constraints are code-adjacent artifacts that affect generated output. Treating them as casual documents that live in a shared drive leads to undocumented edits, conflicting rules, and regressions. Put them in the repository, require pull request reviews for changes, and tag releases.
Common Mistakes
Setting density targets but not defining the spacing scale that achieves them
Correction
Density targets like '60% content ratio' are outcomes, not instructions. The agent cannot directly measure content-to-viewport ratios during generation. It needs the inputs that produce that outcome: specific padding values, gutter widths, and container sizes. If you set a target without defining the spacing tokens that achieve it, the agent will ignore the target and fall back to defaults.
Always pair density targets with the exact numeric spacing scale, container width, and column rules that produce the desired ratio. You will know this mistake is happening if your output pages have the right number of columns but still feel empty, the column structure is correct but the spacing within and between sections is still inflated.
Applying the same density rules to all page types without differentiation
Correction
Dashboard-level density (70-80%) applied to a blog post creates claustrophobic text walls. Blog-level density (50-60%) applied to a pricing comparison page creates a page that feels unfinished. This mistake happens because it is faster to write one rule set, and developers assume the agent will 'figure it out' by context. The agent does not figure it out.
It applies the rules as written. Create separate constraint blocks per page type with different container widths, column counts, and spacing scales. The diagnostic signal is user feedback that some pages feel 'too tight' while others feel 'too loose,' despite both using the same constraint file.
Using Tailwind class names in constraints instead of pixel values
Correction
Writing 'use py-12 instead of py-24' assumes the agent knows the current Tailwind configuration and that the project even uses Tailwind. md files are meant to be portable across frameworks, and tying constraints to a specific utility class library breaks portability. More importantly, Tailwind's spacing scale has changed between versions, so py-12 might mean 48px in one project and something else if the config is customized. ' The agent will translate to the appropriate implementation, whether Tailwind, CSS custom properties, styled-components, or plain CSS.
md to a non-Tailwind project and getting confused or broken output.
Writing density constraints as suggestions rather than rules
Correction
Phrases like 'prefer tighter spacing,' 'try to use multi-column layouts,' and 'consider reducing padding' are parsed by agents as optional guidance that can be overridden by other patterns. This happens because developers write constraints in a conversational tone, the way they would brief a human designer. Agents respond to imperative instructions. Rewrite every suggestion as a hard rule: 'Section padding-y must not exceed 80px.' 'Content sections above 1024px viewport must use a minimum of 2 grid columns.' 'No section may contain only a centered heading with no adjacent content blocks.' The signal that you have this problem is inconsistent compliance, some generations follow the rules and others do not, depending on how strong the agent's default pattern was for that particular layout.
Forgetting to constrain inner element density (cards, panels, modals)
Correction
Most developers write section-level and page-level constraints but forget that the same padding inflation occurs inside cards, modals, panels, and other contained elements. The agent will produce a page with correct section spacing but cards that are 60% internal padding and 40% content. This happens because inner elements feel like implementation details rather than layout concerns. Add a dedicated 'Component Inner Spacing' subsection that specifies padding scales for cards (12-20px), modals (16-24px), and inline panels (8-16px).
The tell is cards that look correct in terms of grid placement but feel hollow or oversized relative to their content.
Setting container widths too aggressively wide without gutter and margin safeguards
Correction
Overcorrecting from narrow defaults to very wide containers (1600px+) without proportional gutter and margin rules creates a different problem: content that stretches uncomfortably wide with text lines exceeding readable lengths. This happens when developers measure the density improvement from wider containers and push the number higher without testing readability. Cap marketing page containers at 1280px and dashboard containers at 1440px unless you have specific multi-panel layouts that warrant wider. Always pair container width with a maximum content column width (typically 720-800px for prose) and side elements or margins that absorb the remaining width.
Other Skills in This Method
Enforcing Typography and Spacing Standards in AI-Generated UI
Teaches how to write and apply SKILL.md rules that govern font sizing, line height, letter spacing, whitespace, and visual density to eliminate generic-looking layouts.
Adding Motion and Interaction Taste Rules
How to specify animation timing, easing curves, hover states, and transition guidelines in SKILL.md files so AI-generated interfaces feel polished and intentional.
Writing Anti-Slop Design Review Rules
How to author SKILL.md checklist rules that catch common AI-generated UI anti-patterns such as oversized padding, default border-radius, and bland color choices before code ships.
Auditing AI-Generated Frontends for Design Quality
A structured review workflow for evaluating AI-produced React and Next.js interfaces against Taste Skill criteria covering hierarchy, contrast, alignment, and component consistency.
Installing SKILL.md Files in AI Coding Agents
How to set up and configure Taste Skill instruction files in tools like Cursor, Claude Code, Codex, Gemini CLI, and v0 so your agent follows design-quality rules.
Authoring Portable SKILL.md Files for Design Systems
Teaches how to create reusable, framework-agnostic SKILL.md instruction files that encode your team's design-system tokens, component conventions, and aesthetic judgment for any AI agent.
Frequently Asked Questions
How do I configure layout density constraints for a project that uses both Tailwind and custom CSS?
Write all constraints in pixel values, never in framework-specific utility class names. State '48px' rather than 'py-12.' The agent will translate pixel values into the appropriate implementation for whatever styling system the project uses. If you need to reference the Tailwind config for consistency, add a note like 'this project's Tailwind config maps spacing-12 to 48px' as context, but keep the constraint itself in absolute units. This makes the SKILL.md portable and avoids breakage when the Tailwind config is customized.
How long should it take to configure layout constraints from scratch?
The initial audit of agent defaults takes about 15-20 minutes if you generate three to five pages and take screenshots. Writing the first version of constraint rules takes 30-45 minutes for someone comfortable with CSS layout concepts. Testing and calibration, where you regenerate baseline pages and compare outputs, takes another 15-30 minutes. Expect the full first pass to take 60-90 minutes. Subsequent refinements are much faster, typically 10-15 minutes per iteration, because you are adjusting specific values rather than building the structure.
Should I configure layout constraints before or after writing typography rules?
Configure layout constraints first. Typography rules govern micro-level relationships (font sizes, line heights, heading hierarchies), but they operate within the container and grid structure that layout constraints define. If you write typography rules first and then change the container width, your type scale may need adjustment because line lengths change. Start with the macro layout: containers, grids, section spacing. Then layer typography rules that fit within those containers. The sibling skill [enforcing typography and spacing standards](/skills/enforcing-typography-and-spacing-standards) is designed to follow this skill in sequence.
Why does my agent keep reverting to single-column layouts despite my multi-column constraints?
This typically happens for one of three reasons. First, your constraint may be phrased as a suggestion ('prefer multi-column') rather than a rule ('must use minimum 2 columns'). Rewrite as imperative. md file, such as a mobile-first rule that the agent is applying to all viewports. ' Third, the constraint may be positioned too far down in the file. Move layout constraints above other rule categories so they receive higher priority in the agent's attention.
How do I handle pages where high density would hurt usability, like onboarding flows?
Add a 'Known Exceptions' subsection to your constraint block that lists page types exempt from standard density targets. Onboarding flows, empty states, single-action confirmation screens, and error pages are common exceptions. For each exception, specify the allowed density range, which is typically 25-40% for these cases, and the reason. The agent will check the page type against the exception list before applying constraints. Without this list, the agent will attempt to densify pages that genuinely need open, focused layouts, creating confusing onboarding experiences or cramped error messages.
Can I use the same density constraints across different AI coding agents like Cursor, Claude Code, and v0?
Yes. This is a core design principle of SKILL.md files within the Taste Skill framework. Because constraints are written in plain markdown with numeric values rather than agent-specific syntax, they work across any agent that reads markdown instruction files. The specific compliance rate may vary slightly between agents (some follow numeric rules more precisely than others), but the format is portable. Test your constraint file with each agent you use and note any agent-specific adjustments in a comment block, such as 'v0 tends to interpret gutter widths loosely, specify gap-[20px] explicitly if output gutters are inconsistent.'
What content-to-whitespace ratio should I aim for if my brand identity emphasizes minimalism?
Minimalist design is not the same as empty design. Minimalist brands like Apple and Linear operate at 45-55% content density. They use whitespace intentionally to create focus and hierarchy, but every pixel of whitespace serves a purpose. The anti-pattern is not whitespace itself but accidental, uniform whitespace that has no relationship to content hierarchy. Set your density target at 45-55%, keep your spacing scale constrained (40px/56px/72px for sections), and add a rule that whitespace between elements must vary based on semantic relationships rather than being uniform. Two related elements get smaller gaps. A shift to a new topic gets a larger gap. This produces intentional minimalism rather than the accidental emptiness of agent defaults.