How I Use Cursor + Claude for CSS: A Practical Workflow from a Real Project

When I first tried using AI tools for front-end work, I was skeptical—especially for something as nuanced as CSS. But after building a real production feature using Cursor and Claude, my workflow for writing and maintaining CSS has changed completely.

This post walks through my actual process from a real project: how I used Cursor as my editor, Claude as my CSS assistant, and where each tool fit into the workflow. I’ll cover what worked, what didn’t, and how I avoid the usual AI pitfalls like bloated stylesheets and brittle utility classes.

The Project: A Dashboard Redesign with Complex Layouts

The real project was a redesign of a web app dashboard. The main goals were:

• Create a responsive, 2-column layout with a collapsible sidebar.
• Implement a card-based grid for analytics widgets.
• Standardise spacing, typography, and colors across the app.
• Clean up several years of ad hoc CSS and inline styles.

The stack was a React front end with a mix of CSS modules and some legacy global CSS. My goals with Cursor + Claude were simple: move faster, but keep styles predictable and maintainable.

Step 1: Setting Up the CSS Context in Cursor

The biggest mistake I made early on was asking Claude to write CSS in a vacuum. The results looked good at first, but they didn’t match existing tokens, breakpoints, or naming conventions. Now, I start every session by giving Claude the right context inside Cursor.

Sharing the design system and constraints

In Cursor, I open the key CSS files and select them so Claude can see:

• variables.css (or tokens.css): color palette, spacing scale, typography.
• layout.css: breakpoints, container widths, grid helpers.
• Any component-level CSS modules already in use.

Then I give a prompt like this directly in Cursor’s chat sidebar:

Context: This app uses CSS variables for colors and spacing, and a mobile-first layout.
Please use the existing tokens and naming conventions you see in these files. 
We’re building a responsive dashboard layout with a collapsible sidebar.

This initial step matters. Once Claude understands the constraints, it starts suggesting CSS that feels native to the codebase instead of generic boilerplate.

Step 2: Drafting the Layout CSS with Claude in Cursor

The first big task was the overall dashboard layout: header, sidebar, and main content area. I already had the JSX structure for the layout, but no styles.

I pasted the JSX into Cursor’s side panel and asked Claude:

Here is the layout JSX for the dashboard. 
Write CSS (in a CSS module) to create a 2-column responsive layout:
- Sidebar collapses to a top nav on small screens
- Main content should scroll while header and sidebar remain fixed
- Use our spacing and color tokens from variables.css

Claude responded with a first draft of the CSS module that looked something like this (simplified):

.dashboard {
  display: grid;
  grid-template-columns: var(--sidebar-width) 1fr;
  height: 100vh;
}

.sidebar {
  background: var(--color-surface);
  border-right: 1px solid var(--color-border-subtle);
}

.main {
  overflow-y: auto;
  padding: var(--space-4);
}

@media (max-width: 768px) {
  .dashboard {
    grid-template-columns: 1fr;
    grid-template-rows: auto 1fr;
  }

  .sidebar {
    grid-row: 1;
    grid-column: 1;
  }

  .main {
    grid-row: 2;
  }
}

Instead of copy-pasting this blindly, I used one of Cursor’s best features: the “Apply to file” interaction. Cursor shows a diff preview so I can tweak class names or variable usage before committing.

Step 3: Iterating Visually with Tight Feedback Loops

Once the basic layout worked, I switched to a very iterative loop between browser and Cursor:

1. Make a change suggested by Claude in Cursor.
2. Save the file, check the UI in the browser.
3. Describe what’s visually wrong back to Claude.

Instead of saying “this doesn’t work” in a vague way, I describe the layout issues precisely:

On screens between 768px and 1024px:
- Sidebar is too wide, taking about 50% of the screen
- Main content feels cramped
- I’d like the sidebar closer to 30% width, with a max-width

Here is the current CSS. Suggest a revised layout that improves this.

Because Cursor already has the CSS open, Claude can see the exact media queries and grid settings. It usually responds with a small, targeted change instead of rewriting everything, for example:

@media (min-width: 768px) and (max-width: 1024px) {
  .dashboard {
    grid-template-columns: minmax(220px, 30%) 1fr;
  }
}

This tight loop is where Cursor + Claude really shine: I’m still making the design decisions, but I don’t have to manually calculate grid fractions, fiddle endlessly with breakpoints, or remember every CSS quirk.

Step 4: Using Claude to Refine Card Layouts and Visual Details

Next, I moved on to the analytics cards inside the dashboard. The structure was a simple grid of cards with titles, metrics, and small charts.

I asked Claude to propose a base card style and grid system:

Design a responsive card grid for the analytics widgets.
Requirements:
- 1 column on small screens
- 2–3 columns on larger screens, depending on width
- Cards should have consistent padding, subtle shadows, and rounded corners
- Use our spacing, radius, and shadow tokens

Here is the current HTML structure for the cards.

Claude suggested a grid pattern like:

.cardGrid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(260px, 1fr));
  gap: var(--space-4);
}

.card {
  background: var(--color-surface);
  border-radius: var(--radius-md);
  box-shadow: var(--shadow-sm);
  padding: var(--space-4);
}

From there, I iterated on typography, spacing between header and content, and how cards behaved when there were long titles or wrapped labels. Each time, I’d highlight the relevant CSS in Cursor and ask:

Here is the card CSS. 
I want the card header to be visually distinct from the body:
- Title slightly larger and bolder
- Subtitle muted
- Add a bottom border or separation without feeling heavy

Suggest minimal CSS changes only, no rewrites.

That last line—“minimal CSS changes only”—is critical. It prevents Claude from regenerating entire sections of CSS and introducing regressions.

Step 5: Refactoring Legacy CSS with Cursor + Claude

The dashboard redesign wasn’t greenfield; there was plenty of legacy CSS to deal with. This is where I leaned on Claude not just as a generator, but as a refactoring assistant.

Cleaning up duplicate rules and specificity wars

I had a stylesheet with patterns like:

.dashboard-card {
  padding: 16px;
  background: #fff;
  border-radius: 4px;
}

.analytics-card {
  padding: 12px 16px;
  background-color: #ffffff;
  border-radius: 4px;
}

In Cursor, I selected the entire legacy file and asked Claude:

We are consolidating our dashboard card styles into a single reusable pattern.
1. Identify duplicate or overlapping rules.
2. Propose a base .card class using our design tokens.
3. Suggest minimal variations for special cases (e.g., .card--alert, .card--compact).

Do not change class names in JSX yet—just propose CSS refactors.

Claude responded with a structured plan:

• A .card base class with shared properties using CSS variables.
• Small modifier classes for padding or background differences.
• A list of redundant rules that could be deleted.

The key here was the two-step process: first, get a proposal; then, selectively apply changes with Cursor’s diff view after reviewing them myself.

Step 6: Debugging CSS Bugs with Natural Language

While building the dashboard, I ran into the usual CSS gremlins: scrollbars appearing where they shouldn’t, cards overflowing at specific breakpoints, and a sticky header that wasn’t sticking consistently.

Instead of manually untangling everything, I used Cursor to select the relevant layout CSS and a snippet of markup, then asked Claude:

The main content area shows a vertical scrollbar inside another scrollbar.
I want:
- The entire viewport to scroll
- The header and sidebar to remain fixed

Here is the layout CSS and the main container markup.
Explain why this is happening and propose a minimal fix.

Claude pointed out that I had nested height: 100vh and overflow-y: auto on both body and the main container, causing double scrollbars. It suggested removing overflow-y from the inner container and relying on the grid layout instead.

This is one of my favourite uses of Cursor + Claude: having the AI explain the bug before suggesting a fix. The explanations help me learn or recall CSS intricacies, instead of blindly pasting code.

Step 7: Enforcing Consistency and Design Tokens

Once the new CSS was in place, I used Claude as a kind of linting assistant for design system consistency.

In Cursor, I selected all the new or changed CSS files and prompted:

Audit this CSS for consistency with our design tokens:
- Replace hard-coded colors with existing CSS variables when possible.
- Replace arbitrary spacing values with the closest spacing tokens.
- Flag any font sizes or line-heights that don't match our scale.

Respond with a list of suggested changes grouped by file.

Claude returned a structured list like:

• dashboard.module.css
  • padding: 18px; → suggest padding: var(--space-4);
  • background: #f5f5f5; → suggest background: var(--color-surface-muted);
• cards.module.css
  • font-size: 15px; → suggest font-size: var(--font-size-sm);

I then manually applied the changes that made sense. This kept the new CSS aligned with the rest of the system without relying entirely on my memory of every token.

Step 8: Guardrails I Use to Keep CSS Maintainable

AI can create as many problems as it solves if you’re not deliberate. Over the project, I settled on a few guardrails that keep Cursor + Claude helpful instead of chaotic.

1. Make Claude work in small scopes

Instead of asking it to “rewrite the dashboard CSS,” I:

• Highlight a specific component or module.
• Ask for minimal changes to solve a focused issue.
• Review every diff in Cursor before applying.

2. Always tie prompts to existing constraints

Almost every prompt includes something like:

Use our existing variables and naming conventions.
Only write classes that will be used by the given markup.
Avoid introducing new global utility classes.

This keeps generated CSS integrated instead of creating a parallel styling system.

3. Prefer explanations plus code

When something is tricky (like stacking contexts, flexbox quirks, or sticky positioning), I explicitly ask:

Explain why this layout is behaving this way, then propose a fix.
Don't change class names, only adjust properties.

The explanations make future maintenance easier, especially when I revisit the code months later.

4. Use Cursor’s diff and inline chat aggressively

Instead of copying code from chat, I:

• Use inline chat in Cursor on a specific file or selection.
• Let Claude propose edits.
• Inspect the diff carefully before accepting.

This keeps changes local and reviewable, which is crucial for CSS where side effects are easy to miss.

What Cursor + Claude Don’t Replace in CSS Work

Despite how much faster this workflow is, there are things I still do myself:

• Design judgment: deciding what “looks right” still comes from me, not the model.
• Component boundaries: deciding where CSS lives (module vs. global vs. inline).
• Performance considerations: avoiding overly complex selectors or unnecessary animations.
• Accessibility: ensuring focus styles, contrast, and motion are handled correctly.

Cursor + Claude are accelerators, not replacements. They turn “I know roughly what I want this to look like” into concrete, shippable CSS much faster, but they still rely on my judgment and review.

Final Thoughts: Why This Workflow Stuck

After shipping the dashboard redesign, I realised I was using Cursor + Claude for almost every CSS-related task:

• Drafting initial layouts and card systems.
• Refining responsive breakpoints.
• Cleaning up legacy styles and reducing duplication.
• Debugging weird layout and scrolling issues.
• Auditing for consistency against design tokens.

The biggest win wasn’t just speed; it was the ability to stay in flow. Instead of context-switching between docs, Stack Overflow, and trial-and-error in DevTools, I keep everything inside Cursor, with Claude acting as a CSS-savvy pair programmer.

If you’re building or refactoring a UI with non-trivial CSS, my recommendation is to treat Cursor + Claude as:

• A fast prototyper for layouts and components.
• A refactoring assistant for legacy styles.
• A teacher that explains why CSS behaves the way it does.

Used with clear constraints, small scopes, and careful review, they can turn CSS from a slow, frustrating part of your workflow into a genuinely enjoyable one.