# VibeCurb ships one JavaScript file and a folder of markdown, and its only gate is prose

> A design-constraint pack for coding agents: seven markdown skills, a five-stage pipeline, and a CLI whose documented package name does not match its own manifest. The whole mechanism is instruction text, so the interesting parts are the places a constraint can be ignored, and the project's own recovery table admits one of them.

**Yu-369/VibeCurb** — VibeCurb - Injects taste into AI workflows to stop agents from generating boring, AI slop.

- Repository: https://github.com/Yu-369/VibeCurb
- Website: https://vibecurb.pages.dev
- Stars: 978 · Forks: 60
- Language: JavaScript
- License: MIT
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/yu-369-vibecurb

## The package is one script, one folder, three dependencies

The tree is short: `.gitignore`, `LICENSE`, `README.md`, `index.js`, `package-lock.json`, `package.json` and a `skills/` directory. Everything executable lives in `index.js`, which the manifest names as both `main` and the `bin` target under the command name `vibecurb`. The declared version is 1.0.0 and the module type is `module`, with three runtime dependencies and nothing else: chalk, inquirer and ora. Those three are a terminal rendering library, an interactive prompt library and a spinner, which is the dependency set of a command line installer rather than of anything that analyses a design. There is no build step, no compiled output and no test configuration anywhere in the tree, and no `.github/` directory, so the published artifact is the source you read. The design constraints themselves are not code either. They are markdown files under `skills/`, one per pipeline, and the documentation says to install a specific `SKILL.md` file rather than a package.

## The documented command names a different package than the manifest declares

The install section tells you to run two commands:

```bash
# View all available pipelines
$ npx vibecurb-cli list

# Install a specific skill
$ npx vibecurb-cli add visual-redesign
```

Both invoke `vibecurb-cli`. The package manifest declares `"name": "vibecurb"` and a bin entry called `vibecurb`, so the published package name and the installed command are both `vibecurb`, not `vibecurb-cli`. Either the documentation was written against an earlier package name that was never renamed here, or the two commands refer to a different package, and nothing in the tree settles which. The manifest is also unusually bare for something you install globally: it carries no `repository` field, no `license` field even though the project is MIT and a LICENSE file exists, no `keywords`, no `files` allowlist and no `engines` constraint. So the two facts a registry or an audit would want, where the code came from and what it weighs, are only in the README.

## Five numbered stages, one named gate, and no gate two

Every skill is described as following the same pipeline, and it is numbered one through five. The Design Read extracts typography, color, spacing, layout and atmosphere from a reference image, existing code or a brief before any code is written. Quality Gate 1 blocks generation until the extraction passes and the agent has demonstrated it understands the design direction, palette and spatial structure. Precise Build then follows the extraction, with each skill carrying its own build sequence. Visual Diff verifies the output against the reference across composition, typography, color, motion and responsiveness using PASS/FAIL tables. Drift Rejection catches generic defaults, CSS keyword easings, AI-purple gradients and placeholder patterns inline. Only the second stage is called a gate, and the numbering implies a gate further down that never gets named. The Visual Diff is the obvious candidate, but it is described as verification, and no threshold for a pass is given anywhere, so a PASS/FAIL table is a format rather than a standard.

## Seven skills, four categories and two naming conventions

The skill table has seven rows and four categories. Three sit under Frontend, `awwwards-hero`, `pixel-perfect` and `awwwards-sections`. Two sit under Image Generation, `imagegen-frontend` and `brandkit-gen`, one under Redesign, `visual-redesign`, and one under Animations, `awwwards-motion`. The naming is not consistent across those rows: three identifiers carry an `awwwards-` prefix, two carry none, and the prefix is spelled with three w characters while the descriptions inside the same table write the site's name with two. `brandkit-gen` is categorised by output medium even though its described job is to produce brandkits and logos before the UI is built, so it is really a pipeline stage filed under a file type. Two rows make promises worth reading closely. `visual-redesign` takes existing React code and returns something designed without touching a line of JS. `pixel-perfect` takes a screenshot of any website and returns an exact replica with fonts, colors and spacing matched.

## Activation depends on a phrase you have to remember to type

The manual install path is deliberately minimal: clone the repository or download the specific `SKILL.md` file, place it inside your project's `.cursor/rules/` or `.agents/skills/` folder, then reference it in your prompt. The reference phrase is given as an example, `Based on the skill above...`, and it is doing more work than it looks. Nothing in the project registers a skill with an agent, nothing watches for the file and nothing loads it automatically, so the file sits in a folder until a prompt names it. Two folder conventions cover the tools named as supported, Cursor on one side and `.agents/skills/` for everyone else, across Cursor, Claude Code, v0, Codex, ChatGPT, Lovable, AI Studio and Gemini CLI, with the catch-all being any agent that reads markdown context. One markdown file, two directories, and a human remembering the incantation is the entire activation path, which also means the five-stage pipeline only runs when the model decides the file is relevant.

## The prompt template carries twelve placeholders and is the real specification

The documentation argues that structure beats instruction, and then supplies the structure as a fill-in template:

```
Based on the skill above, generate the <deliverable> for a <subject>.

The website is for a <context>. Because of that, I want the visual
to feel <vibe words>, with <specific elements>. Make it feel
<quality bar/reference>.

<Layout direction>. Think <composition style>, utilizing a
<color palette>. Keep it in <light/dark> mode, using <typography rules>.

I want it to look <final vibe reinforcement>. Generate the <deliverable>.
```

Count the slots and there are twelve: deliverable, subject, context, vibe words, specific elements, quality bar, layout direction, composition style, color palette, mode, typography rules and final vibe. The template also repeats the deliverable in the first and last line, so the request is framed twice. The stated reason for the template is that an agent asked for a layout without aesthetic constraints will invent generic choices, with the tip section adding that a strong reference image removes the guesswork. So the operative specification is the sentence you write, and the skill file is a set of constraints the model is asked to weigh against it.

## Recovery is three canned replies, and one admits the gate did not hold

The troubleshooting table pairs three symptoms with three replies to paste back at the agent. A dashboard-looking result gets a message saying the skill file was ignored and the drift constraints should be re-read. Weak typography gets an instruction to increase the contrast between the h1 and body text. Rushing to code gets a restatement of the first gate, no code until the extraction passes. Read as a system, the first row is the important one, because it describes the agent receiving the file and not applying it, which is exactly the failure the quality gate exists to prevent. That is what an advisory constraint looks like in practice: nothing verifies that the gate ran, and the documented recovery is to ask again. Nothing in the table carries a measurable threshold either, since weak typography is answered with a relative instruction rather than a number. The project's own warning is blunter, stating that the skills do not ask nicely and that you should not use them if you want safe, generic layouts.

## Conclusion

VibeCurb is worth a try if your problem is that a coding agent returns a competent generic layout and you would rather argue about typography than keep re-prompting, since the extraction-first pipeline and the drift replies are the parts that do the work. It will not help if you want verifiable output, because every check described is an instruction the agent is asked to follow rather than a test that runs, and no pass criterion is defined for the visual diff. Before relying on it, note three things: the CLI name in the documentation does not match the package name in package.json, there are no releases to pin and no tests or CI in the tree, and the pixel-perfect skill promises exact replicas of arbitrary screenshots, so check you have the right to reproduce whatever you hand it.

## FAQ

### What does installing VibeCurb actually put on my machine?

Either a CLI run through npx, with `list` to view pipelines and `add` to install a named skill, or a single SKILL.md file copied into `.cursor/rules/` or `.agents/skills/`. The repository itself is one JavaScript file plus a skills folder, with chalk, inquirer and ora as its only dependencies.

### Which coding agents does VibeCurb claim to work with?

Cursor, Claude Code, v0, Codex, ChatGPT, Lovable, AI Studio and Gemini CLI, plus any agent that reads markdown context. Two directory conventions are documented, `.cursor/rules/` and `.agents/skills/`.

### What are the five stages of the VibeCurb pipeline?

The Design Read, Quality Gate 1, Precise Build, Visual Diff and Drift Rejection. Only the second stage is named as a gate, and no pass criterion is given for the visual diff's PASS/FAIL tables.

### Does the visual-redesign skill modify my JavaScript?

It is described as taking existing React code and returning a designed result without touching a line of JS. No other skill states which of your files it may change.

### When does the project say not to use VibeCurb?

Its own warning says not to use it if you are looking for safe, generic layouts, because the skills intentionally override standard AI generation defaults in favour of complex grids, deep contrast and advanced typography.

## Sources

- [Issues](https://github.com/Yu-369/VibeCurb/issues)
- [License: MIT](https://github.com/Yu-369/VibeCurb/blob/main/LICENSE)
- [Project website](https://vibecurb.pages.dev)
- [README](https://github.com/Yu-369/VibeCurb/blob/main/README.md)
- [Yu-369/VibeCurb on GitHub](https://github.com/Yu-369/VibeCurb)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/yu-369-vibecurb
