Why every AI built website looks the same, and the skills that help you escape it

You can usually recognise an AI built website before anyone admits how it was made.

There is the oversized headline. The familiar gradient. Three feature cards with friendly icons. A dark section to make the page feel serious. Perhaps a glowing orb, because apparently every software product now has one hiding in the server room.

The problem is not that AI cannot make a polished interface. It can. The problem is that generation naturally returns to common patterns unless someone gives it stronger context, better taste, and a process that forces decisions to survive beyond the first impressive screen.

I have been through the painful version of this while developing platforms, websites, and AI assisted product workflows. I have discovered the missing journey after implementation, noticed inconsistent states during testing, added accessibility too late, and realised that a technically correct page could still have no point of view.

Most builders learn these lessons backwards. We find the missing discipline only after its absence becomes visible.

I want to help you start from the other end. This guide shows how to give Codex or ChatGPT a small system of product, design, engineering, and quality skills that work together. It is especially useful if you do not have a full stack engineering background, but want your work to benefit from the structure that a capable multidisciplinary team would normally provide.

The goal is not to make AI generate more. It is to make every stage carry more intent.

What a skill does

A skill gives the agent a reusable way to handle a particular kind of work. Think of it as a small specialist that becomes available when the task needs it. One skill can shape the product brief. Another can review the experience. Another can test whether the final result actually meets the standard.

OpenAI describes this as progressive disclosure. The agent first sees a lightweight description, then loads the deeper guidance only when it becomes relevant. The OpenAI guide to building skills explains the current structure and installation options.

Do I have to invoke every skill myself?

No. And in a well-designed system, you should not have to remember most of them.

There are two useful modes:

• Implicit invocation. The agent selects a skill because your request matches its description. “Turn this PRD into buildable slices” might activate a delivery planning skill without you naming it.
• Explicit invocation. You select a skill deliberately. In Codex, the documented syntax is $skill-name; in ChatGPT, it is @skill-name. This is useful when you want a particular method, when the task is expensive, or when several skills could plausibly apply.

So no, this is not mainly a forward slash command system. You may use the product interface to browse skills, but the portable instruction is the skill name itself: $... in Codex and @... in ChatGPT. The Codex App Server documentation also documents the $skill-name form.

Automatic invocation still depends on a clear description. The agent needs to understand what the skill owns, when it should appear, and when another skill should take over.

Where should skills live?

The useful distinction is not “installed or not installed.” It is global capability versus project truth.

Global skills

Put a skill in your global skills directory when its method should follow you across projects. Current OpenAI guidance uses $HOME/.agents/skills for user skills. A global skill might cover:

• turning a product idea into a structured brief;
• reviewing interface quality;
• planning delivery slices;
• running an accessibility audit;
• debugging with a regression test;
• preparing a safe release.

These are reusable ways of working. They should not contain one company’s architecture, customer data, secrets, or private decisions.

Project skills

Put a skill in the repository’s .agents/skills directory when it encodes local truth. Examples include:

• how this codebase handles authentication;
• the project’s design tokens and component rules;
• its deployment and rollback process;
• its definition of done;
• the exact commands required for tests, migrations, or previews.

Project skills should travel with the repository because the repository is where those instructions are true.

There is a practical rule hiding here: global skills describe your craft; project skills describe the environment. If a reusable skill needs project details, let it read those details from the project rather than baking them into the global package.

The architecture: one journey, several kinds of judgement

The cleanest system is not one enormous “make this website good” skill. It is a small coordinator surrounded by domain skills with clear ownership.

The coordinator identifies the stage and hands work to the relevant owner. It should know that product definition comes before detailed implementation, and that verification needs acceptance criteria. It should not contain every accessibility rule, every React optimisation, and every deployment command itself.

This gives you three layers:

1. Coordinator. Understands the development journey, chooses the next stage, and prevents premature building.
2. Domain owners. Own substantial outcomes such as product definition, experience design, delivery planning, implementation, or verification.
3. Specialists. Provide narrow expertise such as motion, mobile behaviour, database performance, payments, threat modelling, or visual quality review.

The division matters because context is finite. If one coordinator includes every checklist and implementation rule, it becomes difficult to maintain and expensive to load. If every small preference becomes a standalone skill, routing becomes noisy. Domain owners are the middle layer that keeps the system intelligible.

Here is what that architecture looks like when real skills and useful public repositories are placed on the journey:

The public repositories in the diagram are references and specialist sources, not a recommended bulk installation. Emil Kowalski’s skills are particularly useful around motion and mobile feel. Tastemaker, Hallmark, and Taste Skill can sharpen visual direction and critique. Vercel’s agent skills are more relevant during implementation when the stack actually uses React, Next.js, or Vercel.

Sequence the work, not just the skill names

A skill library becomes a development system when it understands transitions.

Stage	Primary question	Typical output	Evidence before moving on
Product definition	What problem are we solving, for whom, and why now?	Brief or PRD	goals, users, constraints, success measures
Experience design	What should the user understand and do?	journeys, states, interaction direction	primary journey, edge cases, content, accessibility intent
Delivery planning	What is the smallest coherent build sequence?	vertical slices and acceptance criteria	dependencies, risks, verification plan
Implementation	How should this slice be built in this repository?	working code and tests	repository conventions, local checks, observable behaviour
Verification	Does it work, and is the evidence proportionate to the risk?	test record and release decision	behaviour, accessibility, security, regression, release checks
Learning	What should the system remember next time?	decisions, patterns, handoff notes	validated lessons rather than speculative preferences

Some skills belong mainly to one stage. Others are lenses that should appear repeatedly.

Avoiding AI slop is not a final coat of paint applied after accessibility. Distinctiveness, content hierarchy, interaction clarity, responsive behaviour, accessibility, and performance influence one another. A visual quality skill should shape the design direction, review implementation, and contribute to final verification. Security follows a similar pattern. Boundaries belong in the architecture, secure implementation belongs in the build, and testing belongs at the verification gate.

The journey is sequential, while the quality system runs through every stage.

Build from the failures you do not want to repeat

Start with one repeated failure. Perhaps the agent keeps producing generic layouts, skips empty states, ignores mobile behaviour, or declares success without testing the real journey. Give that failure an owner, a clear trigger, and an observable outcome.

At a high level, a useful skill should answer four questions:

1. What outcome does it own?
2. When should it be used?
3. What evidence does it need?
4. What must be true before the work moves on?

Codex and ChatGPT include creator and installer skills in supported environments. You can ask $skill-creator in Codex or @skill-creator in ChatGPT for guided help, then use the corresponding installer for a trusted repository. The official skill building guide remains the best source for current paths and commands.

Where to find useful starting points

Repositories are best treated as reference libraries, not shopping baskets. Read the licence, inspect every instruction, check scripts before running them, and install only what fills a real gap.

Source	Useful for	How I would use it
OpenAI Skills	Official examples and common document or workflow skills	Start here for structure and current conventions
Anthropic Skills	Examples of packaged agent expertise across platforms	Study patterns and adapt them intentionally for your environment
Emil Kowalski’s skills	Motion, mobile feel, interface critique, and prototyping	Select individual specialists rather than the whole repository
Tastemaker	More opinionated interface taste and design memory	Keep explicit at first; use during visual direction and critique
Designer Skills	Broader design workflows and reusable design knowledge	Extract the parts that match your product and stack
Hallmark	Detecting generic, recognisably AI generated interface choices	Use as a review lens, not as the sole design authority
Taste Skill	Translating design taste into reusable guidance	Use as a reference when authoring your own quality criteria
Vercel agent skills	React, Next.js, deployment, and web-platform practices	Install only the skills relevant to the active stack

Large orchestration systems such as oh my codex, and memory tools such as codebase memory MCP or Graphify, solve a different class of problem. They may be useful, but they are not interchangeable with skills. An orchestration layer coordinates agents. A memory service preserves or retrieves knowledge. A skill teaches a procedure. Adopt them only when you can name the failure that the additional infrastructure will fix.

How to install without creating a context landfill

Use a small admission test before adding anything globally:

1. Will I use this across several projects?
2. Is its trigger meaningfully different from an existing skill?
3. Can I explain its output and evidence requirements?
4. Have I inspected its instructions and scripts?
5. Should it be automatic, or explicit until I trust its routing?

If the answer to the first question is no, keep it in the project. If it overlaps another skill, merge the useful reference material into the existing owner. If it is exploratory, make it explicit.

This restraint has a technical benefit. OpenAI notes that skill metadata competes for a context budget; when many skills are installed, descriptions may be shortened or some skills omitted from the model-visible list. More installation can therefore make routing worse. The best library is not the largest one. It is the smallest library that covers the work you actually repeat.

The short instruction that makes the system work

When you start a repository, keep the default instruction short enough that people will actually use it:

Read the product brief and project instructions. Identify the current stage,
use the relevant global and project skills, and move the work to the next
evidence based checkpoint. Apply accessibility, security, performance, and
distinctive interface quality throughout; do not leave them for final polish.

The longer routing contract belongs in the repository instructions, where it can specify the stages, architecture, commands, design tokens, deployment process, and definition of done. It should not be pasted into every conversation.

Then begin with a request that provides intent rather than a list of tools:

Here is the product brief. Identify the current development stage, use the
relevant project and global skills, and take this to the next evidence based
checkpoint. Do not begin implementation until the user journey, constraints,
acceptance criteria, and delivery slice are clear.

You can still override the router. If you want a specific procedure, say $plan-delivery-slices or $verify-product-quality. Explicit control remains useful; it simply should not be the tax you pay on every ordinary request.

Distinctiveness is a systems outcome

The reason AI websites look alike is not one bad font or one overused gradient. It is the absence of accumulated decisions. The product has no strong positioning, the content has no hierarchy, the design has no art direction, implementation reaches for defaults, and review asks only whether the page works.

The skills help because they add those decisions back in at the stage where each one belongs.

A strong skill system makes good behaviour repeatable. It preserves product intent as work passes into design. It turns design decisions into acceptance criteria. It makes implementation respect the local codebase. It asks for evidence before release. And it records what was actually learned, instead of filling memory with every passing preference.

This connects directly to spec-driven development: a specification gives the work a source of truth, while skills give the agent repeatable ways to move that truth through the system. It also extends the broader argument in The skills every AI product builder should develop. Human judgement still chooses the problem, shapes the standard, and decides what evidence is enough.

You can give someone your entire skill folder. Sometimes that is generous and useful. But teaching them how to design the routing, boundaries, and sequence is more durable. Repositories change. Tools change. Product names change.

The ability to turn a way of working into a small, testable operating system travels much further.