About vibe-coding
vibe-coding is a set of practices for working with a coding agent on projects of any kind. It favors small iterative changes, relevant project or API references, and repeatable checks before work is considered done.
Key features
- 01Break work into the smallest shippable change
- 02Use project skills or official documentation
- 03Run tests, scripts, or reproducible checks
- 04Iterate without bundling unrelated large changes
- 05Choose references for app, data, and model layers
Use cases
- 01Implement a feature or screen in small steps
- 02Check API usage against current documentation
- 03Run repeatable verification before marking work done
Install
Copy the command and run it in a terminal.
$
npx skills add https:/After installing, type/vibe-codingin Claude Code to confirm it loaded.
Details
From the project READMEVibe coding
Vibe coding means you steer; the agent helps you ship. You do not need to master everything upfront—you need tight loops, honest checks, and the right small context at the right time. This applies to any project.
Habits
- Slice the smallest shippable change. One feature, one failure mode, one screen—whatever keeps the next step obvious.
- Implement with the right reference in view: a project skill, framework docs, or an official API page—not a wall of ad-hoc rules in the chat.
- Verify before you call it done: run tests, a script, a linter, or a reproduction the user can repeat. If nothing ran, say what should run.
- Iterate. Avoid giant diffs that mix auth, UI, and data in one go unless the user asked for that explicitly.
Skills vs. long prompts
- Prefer a short domain skill (or a link to a canonical doc) over pasting the same long instructions every session.
- If the agent keeps guessing a library’s API, read the current docs (or a dedicated skill) instead of improvising from training data.
Ecosystem: separate your layers
- App and UX (framework, components, a11y, design, routing): use skills or docs for that layer. Browsable examples include skills.sh and whatever your team ships.
- Data and APIs (databases, HTTP clients, model/speech/translation providers): use that product’s official reference or a provider-specific skill. Do not copy example HTTP calls from a UI skill into your real client without matching them to the real spec.
- Model, speech, translation, or vision features: treat them like any other API—vendor docs and provider skills win over generic chat guesses.
Gotchas
| Issue | What to do |
|---|---|
| Stale or invented APIs | Open the current project docs or provider documentation; do not trust memory alone. |
| One skill’s example bleeding into the wrong layer | A React skill’s fetch snippet is not automatically your model API—reconcile with the right spec. |
| Pasting a novel into every request | Shrink to a skill, a doc link, or a few bullets; refresh when the library changes. |
| “Big bang” refactors | Split, verify, repeat. |
Comments
Markdown supported