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

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:

# 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.

Editorial 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.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. Yu-369/VibeCurb on GitHub