Use Taste Skill with Codex for Frontend Design

Install Taste Skill, give Codex stronger frontend design constraints, preserve an existing design system, and verify the result without generic AI UI patterns.

What Taste Skill changes

A design skill helps Codex avoid generic layouts by making the design read explicit. The agent must understand audience, product context, information hierarchy, interaction complexity, and existing tokens before it writes frontend code.

Install it in Codex

install-taste-skill.shbash

# Full Taste Skill package for Codex
npx skills add Leonxlnx/taste-skill -a codex

# Default frontend design skill
npx skills add https://github.com/Leonxlnx/taste-skill --skill "design-taste-frontend"

# Strict GPT / Codex-oriented variant
npx skills add https://github.com/Leonxlnx/taste-skill --skill "gpt-tasteskill"

verifytext

1. Can Codex read the new SKILL.md?
2. Does the project already have a design system or component library?
3. Are page type, audience, visual direction, references, and interaction complexity clear?
4. Did Codex write a design read before implementation?
5. Did the final response include an anti-slop pre-flight check?

Recommended workflow

workflowtext

1. Read the current page, components, CSS, and navigation
2. Produce a design read before writing code
3. Define information architecture: first view, steps, examples, FAQ, and next action
4. Implement one coherent direction
5. Run a build, preview, or screenshot check
6. Iterate on concrete findings instead of rewriting the whole page

For an existing project, audit first. Ask Codex what looks generic, what must remain, and what can be modernised before allowing it to edit the page.

Reusable prompt

codex-prompttext

Use the Taste Skill frontend design rules for this page.

Context:
- Product: AI API documentation site
- Audience: developers, AI-tool users, and team administrators
- Direction: dark technical documentation, restrained contrast, no generic purple AI template
- Constraint: preserve the current GPT88 navigation and layout

Requirements:
1. Read the existing page and components before editing
2. Start with one design read describing page type, density, motion, and layout
3. Reuse existing components and CSS variables
4. Avoid three equal feature cards, decorative gradient blobs, fake dashboards, and placeholder copy
5. Run a build or focused validation and report the changes

Applying the design rules

For a new page, define type, audience, mood, density, and references before implementation.
For a redesign, run a visual audit and separate preserved elements from changes.
For a component project, inspect tokens, themes, and existing primitives before adding new ones.
For motion, use stable patterns and avoid fragile scroll listeners.
For documentation, prioritise readability, anchors, code blocks, tables, links, and mobile reading.

Anti-slop checklist

anti-slop-checklisttext

1. Does the first view explain the page value?
2. Is the copy grounded in the actual product and audience?
3. Are repeated equal-width feature cards avoided?
4. Are decorative gradients, grids, and glowing blobs justified?
5. Is the existing design system and navigation preserved?
6. Are commands, steps, and configuration examples real?
7. Is the mobile layout readable?
8. Does the code build?
9. Are heading hierarchy, internal links, and SEO metadata present?
10. Are there no placeholders, TODOs, fake data, or unfinished blocks?

Troubleshooting

If Codex ignores the skill, name it explicitly and confirm the SKILL.md location.
If the page still feels templated, require a design read and specify audience, industry, density, references, and forbidden patterns.
If it conflicts with the site, ask Codex to read the current components and CSS first.
If the change is too broad, limit the scope to one page or section and preserve routes and shared APIs.
If the build fails, fix TypeScript and JSX errors before iterating on visual details.

Continue with Codex CLI integration, tool recovery, or the GPT-Image-2 Skill.