I got tired of explaining what "make it look better" means to Claude, so I built Form & Force

I've been using Claude Code quite heavily for frontend projects. It's genuinely impressive how much you can get done with it, but there's one particular part of the process that has always been frustrating for me.

Design.

Not getting a page to render. Not connecting components or setting up the application. I'm talking about the actual decisions behind a good interface.

Typography, composition, visual hierarchy, interaction design, motion, little details that make a website feel considered rather than assembled.

I kept running into the same situation.

I'd ask Claude to build something, get a perfectly functional result, and then spend the next hour explaining why it felt generic. The usual layouts would appear, familiar gradients would show up, and animations would be added without really contributing anything to the experience.

I'd ask for something more original, and get a slightly different version of the same thing.

At some point I realized that I was trying to solve a workflow problem with more prompting.

That's where Form & Force started.

GitHub: https://github.com/erenthedeveloper0/form-and-force

The idea behind it

I didn't want to create another prompt collection that tells Claude to use better typography, add some interesting animations and make everything feel premium.

I wanted to give it an actual process to follow.

Form & Force is an open-source Agent Skill and Claude Code plugin focused on frontend design, creative direction and motion engineering.

It covers everything from marketing websites and portfolios to SaaS applications, dashboards, e-commerce, editorial experiences and design systems.

The interesting part is how it approaches the work.

1. Understand the project before touching it

This is something I consider particularly important when working with existing repositories.

An agent shouldn't immediately start replacing components just because it has a different idea.

Form & Force begins by inspecting the repository, its architecture, dependencies, existing components and current implementation.

It also considers the actual product, its audience and the user journeys involved.

The idea is to make decisions based on what already exists rather than treating every project as a blank canvas.

2. Come up with an actual creative direction

Before implementation, the skill explores three different creative directions.

These aren't supposed to be three variations of the same layout with different color palettes.

They should have different visual ideas, compositions and design approaches.

The directions are evaluated, one is selected, and that direction becomes the basis for the design system.

This includes things like:

• Typography and type hierarchy
• Layout and composition
• Colors, materials and visual texture
• Component behavior
• Motion principles
• Interaction patterns

I wanted the design to have a reason behind it instead of being a collection of trendy UI decisions.

3. The anti-slop component atlas

This is one of the parts I've spent quite a bit of time on.

I put together a component atlas covering 180 components across 12 families.

It looks at common interface patterns, explains where they tend to become generic, and explores stronger alternatives when the project calls for them.

Something worth mentioning: the intention isn't to ban familiar components.

A navbar is still a navbar. A pricing section doesn't have to become some experimental piece of art.

Sometimes the conventional solution is exactly the right one.

The important distinction is whether a component is there because it serves the product or because the model has seen the same pattern thousands of times.

4. Motion should have a purpose

I also wanted motion design to be treated as part of the design process, not something added at the very end.

The skill includes guidance for animation identity, hierarchy, choreography and signature moments.

It covers implementation approaches involving CSS, WAAPI, View Transitions, GSAP, Lenis, Motion and Three.js.

That doesn't mean every project needs a cinematic preloader or a page full of scroll-triggered animations.

A subtle transition can be much more effective than a complicated animation that interrupts the experience.

5. Actually inspect what was built

I didn't want the workflow to end with Claude saying that everything looks great.

There are several bundled scripts for inspecting and checking the resulting work:

• inspect_repo.mjs for repository inspection.
• slop_scan.mjs for static interface-pattern checks.
• audit_page.mjs for rendered browser auditing through Playwright.
• contact_sheet.mjs for generating visual contact sheets.

The browser audit can also cover keyboard navigation and reduced-motion behavior.

There are additional references for accessibility, responsive design, performance, security and implementation.

The scripts can be used independently of the skill, too.

For example:

node skills/form-and-force/scripts/inspect_repo.mjs ./my-project

node skills/form-and-force/scripts/slop_scan.mjs ./my-project --strict

The static scanner doesn't require an API key or paid model call. The rendered audit requires Playwright and Chromium.

Try it

Form & Force is MIT-licensed and open source.

Install it through Claude Code:

claude plugin marketplace add erenthedeveloper0/form-and-force

claude plugin install form-and-force@form-and-force

Once installed, you can invoke it directly:

/form-and-force:form-and-force

Or simply describe the frontend work you're doing and let Claude load the skill when relevant.

There's also a standalone Agent Skill package available through the Skills Registry.

Repository: https://github.com/erenthedeveloper0/form-and-force

A few things I'm not claiming

I want to be honest about where the project currently stands.

I haven't run the paid behavioral evaluations yet, so I don't have measured evidence that Form & Force produces better outcomes than Claude without the skill.

The static scanners and browser audits are heuristic checks, not proof that a website is accessible or performs well in production.

I think this distinction matters, especially when building tools intended to improve AI-generated work.

I'd rather have people understand what the project currently does than make exaggerated claims about it.

Where I'd like to take it

There's still a lot I'd like to explore.

I'm particularly interested in making the evaluation of generated interfaces more reproducible. We can talk about visual quality all day, but figuring out how to evaluate it consistently is a much harder problem.

I'd also like to keep improving how creative direction translates into actual implementation, especially for more unusual projects where conventional frontend patterns aren't necessarily appropriate.

For now, I'd love to get more developers using it and hear what breaks, what feels unnecessary, and what could be better.

If you work with Claude Code or build agent skills yourself, I'm particularly interested in your thoughts.

What do you think is the biggest weakness of AI-generated frontend design right now: the creative decisions, the implementation, or the way we evaluate the final result?

Thanks for reading!

— Eren