Taste Skills Are Turning Agent Review Into Infrastructure

Official Sources#

GitHub trending has a useful little cluster today.

EveryInc/compound-engineering-plugin is packaging brainstorm, plan, work, review, debug, and learning loops as installable agent skills and agents. Leonxlnx/taste-skill is trying to teach agents stronger frontend taste: layout, typography, motion, density, and design-system fit. hardikpandya/stop-slop attacks the same problem from prose: predictable AI tells, lazy rhythm, and empty business phrasing.

Those projects look different on the surface. One is an engineering-method plugin. One is an anti-slop frontend framework. One is a writing cleanup skill.

The shared signal is more interesting: teams are turning review taste into runnable infrastructure.

That is the next stage after skills becoming the agent operating system. The first wave said, "put your workflow in files." This wave says, "put your taste in files too, then make the agent prove it used them."

The take#

AI agents do not fail only because they miss facts.

They fail because they miss judgment.

A coding agent can satisfy the literal prompt and still ship a page that feels generic. It can fix a bug and leave behind a weird abstraction. It can write an article that says the right things but sounds like every other AI-generated post. It can run tests and still miss the product reason the change exists.

That gap is why taste skills are getting traction.

They are an attempt to make judgment portable across Claude Code, Codex, Cursor, Copilot, and whatever terminal agent a team tries next. The model changes. The local preference layer should not have to start over every time.

The mistake is treating these files as magic prompts. They are not.

The useful version is stricter: a taste skill is a review checklist, a style contract, and a calibration artifact that the agent must route through before it claims the work is done.

Why this showed up now#

The timing makes sense.

Agent tools are moving from "can edit files" to "can run a workflow." Claude Code's public README frames the tool as an agentic coding system that works in the terminal, IDE, and GitHub. OpenAI's Codex developer page frames Codex as one agent for everywhere you code.

Once agents move across surfaces, prompt snippets stop being enough.

You need portable operating instructions:

• how to brainstorm before implementation
• how to plan before editing
• how to review before merge
• how to encode a design system
• how to remove low-quality prose patterns
• how to document what the next run should learn

That is exactly what the trending projects are pointing at.

Compound Engineering says each unit of engineering work should make future work easier, not harder. Taste Skill packages frontend design judgment into installable skills. Stop Slop packages prose review into a scoring pass. The shared bet is that an agent should not merely complete tasks. It should improve the next task's starting point.

That pairs directly with long-running agents need harnesses. A harness gives the run shape. A taste skill gives the run standards.

The best skills make review earlier#

Human review often happens too late.

The engineer opens a pull request, the page already exists, the code already has shape, and the reviewer has to say, "this feels off." That kind of feedback is expensive because it arrives after the agent has committed to a direction.

A good taste skill moves part of that review forward.

For frontend work, that might mean forcing the agent to decide:

• what design language already exists in the repo
• whether the task needs dense operational UI or a lighter editorial page
• which spacing, type, and motion choices would violate the product's baseline
• whether the output looks like a generic AI landing page
• whether the design follows the local contract in DESIGN.md for AI agents

For prose, it means catching problems before publication:

• empty throat-clearing
• dramatic fake contrasts
• repetitive sentence rhythm
• passive voice where direct language would be clearer
• vague claims that need a source
• "AI slop" phrases that make a post sound disposable

This is why AI design slop is not only an aesthetic problem. It is a workflow problem. If the agent can generate slop faster than a human can review it, the bottleneck becomes taste enforcement.

The opposing view is fair#

The skeptical take is simple: these are just prompts.

That critique has teeth.

Markdown instructions do not guarantee taste. A skill with a confident name can still be vague. A frontend taste checklist can become trend-chasing. An anti-slop prose pass can make every paragraph sound clipped and self-serious. A compound-engineering loop can become ceremony if the task is small.

The answer is not to install every trending skill.

The answer is to measure whether a skill changes review outcomes.

For design skills:

• Did the first draft need fewer layout corrections?
• Did the agent follow the existing design system without being reminded?
• Did mobile and desktop both hold up?
• Did the result avoid generic AI visual tropes?

For prose skills:

• Did the draft need less cleanup?
• Did claims keep source links?
• Did internal links feel natural instead of SEO-stuffed?
• Did the voice match the site instead of sounding like a template?

For engineering workflow skills:

• Did the plan shrink the implementation diff?
• Did code review catch earlier patterns, not just local bugs?
• Did the run produce reusable learning for the next task?
• Did verification become more consistent?

If the answer is no, delete the skill or rewrite it.

That is the governance point from Skills for real engineers need governance, not fandom. Skills are useful only when they reduce a real failure mode.

Taste belongs in the repo, not only in the model#

The most durable move is not installing someone else's taste forever.

It is using public skills as scaffolding, then turning your own standards into repo-local rules.

For a product team, that means the agent should read the same constraints every run:

• design tokens and component rules
• banned copy patterns
• accessibility rules
• screenshot expectations
• source-link requirements
• verification commands
• examples of approved output
• examples of rejected output

This is where a skill becomes infrastructure. It stops being a clever prompt and starts acting like a local review rail.

The same idea already exists in code. Teams have linters, formatters, typecheckers, snapshot tests, visual regression tests, and CI gates. Taste skills are weaker than those tools, but they fit into the same control plane. They catch judgment problems earlier, then deterministic checks catch the parts machines can verify.

The ideal loop looks like this:

1. The agent reads the project strategy and design contract.
2. The agent applies the relevant taste skill before writing.
3. The agent implements the smallest useful change.
4. The agent runs deterministic checks.
5. The agent performs a review pass against the taste skill.
6. A human reviews the diff with the agent's self-review attached.
7. Any durable lesson becomes a repo instruction or skill update.

That last step matters. If the human says the same thing twice, the workflow is leaking knowledge.

The agent stack is becoming less model-centric#

There is a broader market point here.

The winning developer agent stack will not be one model plus one chat box. It will be a set of portable controls around model behavior:

• context maps
• skills
• design contracts
• local memory
• review agents
• browser validation
• deployment receipts
• cost and run logs

That is why the skill trend keeps reappearing under different names. The community is not only asking models to become smarter. It is building the missing organizational layer around them.

Taste is part of that layer.

Not because taste can be fully automated. It cannot. But because teams cannot afford to re-explain their standards every time a model opens a new session.

How I would adopt this#

Start small.

Pick one recurring failure mode:

• AI-generated pages look generic.
• Agent-written articles sound flat.
• Code reviews keep finding the same architecture issue.
• Agents skip planning on tasks that need planning.
• Agents forget to turn lessons into docs.

Then install or write one skill for that failure mode.

Do not begin with a giant skill library. Begin with one repeatable review rail and attach a receipt to it.

For example:

Before calling frontend work done, run the design-taste review.
Attach a short checklist:
- existing design language identified
- mobile layout checked
- typography checked
- no generic AI visual tropes
- screenshots reviewed

That is a better starting point than "make it beautiful."

For prose:

Before publishing, run the anti-slop pass.
Attach a short checklist:
- no unsupported claims
- source links included
- internal links are contextual
- rhythm varied
- banned phrases removed

That is a better starting point than "make it sound human."

The strongest agent workflows are going to feel boring. They will have fewer magical prompts and more local standards, receipts, and feedback loops.

That is the real lesson from today's trending skill repos.

The future of agent quality is not just better generation. It is better review, moved earlier, written down, and reused.

FAQ#

What is a taste skill for AI agents?#

A taste skill is a reusable instruction file that helps an AI agent apply subjective standards such as layout quality, prose style, design-system fit, review discipline, or anti-slop cleanup.

Are agent skills just prompts?#

Technically, many skills are prompt files with supporting references. Operationally, the useful ones behave like review rails: they define when to load a procedure, what behavior should change, and what receipt the agent should produce.

Should teams install public skill repos?#

Use public skill repos as starting points, not permanent authority. The best long-term setup is repo-local standards that reflect your product, design system, verification commands, and review culture.

How do taste skills relate to linters and tests?#

Linters and tests verify deterministic rules. Taste skills guide judgment before and after implementation. They should not replace deterministic checks, but they can reduce the number of subjective review issues that reach a human late.