Blog · Oct 15, 2026 · 7 min read

Cursor rules for vibe coding audio plugins

Cursor (and similar AI coding tools) work better when the project has a short set of always-on rules. For plugin prototypes, those rules are not bureaucracy—they are studio etiquette for the AI: how to talk, what stack to keep, and how not to blow up your ears or your architecture.

Here is a practical pattern that works for browser plugin prototypes and vibe-coding musicians on the path to VST/AU.

What Cursor rules are (in one sentence)

A rules file (often .cursor/rules/*.mdc) is a persistent brief the assistant reads before it edits. You write it once; every chat inherits the rails.

Tone: studio buddy, not senior engineer

Musicians succeed when the AI explains music first and code second. Tell the assistant to:

• Use plain English and synth/DAW metaphors (“this gain is like a master fader”)
• Preview the change in 1–3 sentences before editing
• End every edit with a listen test: save → refresh → Start → move X → expect Y
• Change one feature at a time

Without that, you get jargon dumps and multi-file rewrites that break sound.

Tech rails that keep the zip runnable

For a zero-build browser prototype, lock the stack in the rules:

• Plain HTML, CSS, vanilla JS (ES modules OK)—no React, bundler, npm, or TypeScript unless you ask
• Keep the layout: src/index.html, main.js, audio.js, style.css
• Must still work by double-clicking index.html
• One shared AudioContext, created/resumed only after a user click
• Route through master gain → limiter → destination; never bypass
• Ramp parameters (setTargetAtTime / ramps)—no zipper noise from jumping .value
• Default volumes low (master ≤ ~0.3); protect ears
• Rhythm: schedule with currentTime, not setInterval alone

Those lines stop the classic vibe-coding failure: “helpful” rewrites into a Vite+React app that silent-fails offline.

Scope boundaries

Explicitly list out-of-scope items unless the user asks: backends, logins, databases, deploy pipelines, compiling a VST/AU this session, paid libraries. Beginners ask for “make it a VST now” mid-session; rules should remind the AI to stay on the browser prototype until the idea is proven—then point to the JUCE path.

A minimal rule skeleton

You do not need a novel. A short file that names the tool idea, the audience (musician, not programmer), tone, tech rails, and out-of-scope list is enough. Vibepatch Spec → Scaffold ships a filled .cursor/rules file personalized to your plugin idea so you skip inventing this from scratch.

Habits that make rules stick

1. Open the folder, not a single file
2. Run an “understand” prompt with no edits first
3. Ask for one control or behavior per turn
4. Listen after every change; if it breaks, describe what you heard and fix smallest-first

Rules set the culture. Your prompts enforce the tempo.

Next: Browser prototype vs VST/AU — path to your first plugin →