VibeIt Users Manual — optimal uses of the vibe-coding tool

🎈 ELI5

VibeIt is a little app-builder that lives in your web browser. You type what you want ("make me a todo app with a dark theme"), it writes the code, shows you a live preview, and lets you edit the files and ship it. You bring your own AI key (from OpenAI or OpenRouter), so you're paying the model directly and nothing sits in the middle.

Think of it as a workbench with four corners: where you describe the app, where you watch it get built, where you edit the files, and where you see it run.

What VibeIt is

VibeIt is a self-contained, browser-based "vibe-coding" tool: you describe an app or change in plain language, a model you've connected generates the code, and you iterate in a live loop — edit files, preview the result, and deploy. There's no install and no backend account; the project lives in your browser and talks directly to the model provider using your own API key.

It is deliberately minimal and transparent — you can see the generated files, edit them by hand, and watch the model stream its output. That makes it well-suited to fast prototyping, learning, and small self-contained web apps.

The mental model VibeIt is the orchestration surface; the intelligence comes from whatever provider/model you connect. A better model (or a sharper prompt) produces a better app. VibeIt's job is to make the prompt → code → preview → deploy loop as tight as possible.

The four zones

Everything in VibeIt maps to one of four working areas. Knowing which zone owns which job is most of "using it well."

Zone 1

⚙️ Settings & Prompt

Project name, provider, model, API key, context mode, advanced sliders, skills, MCP servers, the Global prompt, and the per-generation prompt + Generate (stream) / Stop.

Zone 2

📡 Status & Stream

The live log of what the model is doing as it generates — token stream, tool/skill activity, and any errors. Clear logs resets it.

Zone 3

📝 Files & Editor

The generated project files. Hand-edit anything, then Save, Undo, Redo, Download, or Deploy.

Zone 4

👁 Preview

A live render of the current project with Reload, Fullscreen, and the preview URL. This is your ground truth — believe the preview, not the description.

First build in 60 seconds

Open VibeIt at attap.ai/media/files/vibeit.
Pick a provider and paste your API key. Provider = OpenAI or OpenRouter; choose a model; paste the key. (See Provider, model & API key.)
Name the project so you can tell builds apart later.
Describe what you want in the prompt box — be concrete about the goal, the look, and the must-have behaviors.
Hit Generate (stream) and watch Zone 2. When it finishes, look at the Preview (Zone 4), not just the log.
Iterate. Describe the next change, or hand-edit a file in the editor and Save. Repeat until the preview is right.
Ship it — Download the files or Deploy.

When to reach for VibeIt

Great fit

Self-contained front-end apps (single-page tools, dashboards, toys, landing pages).
Fast prototypes you want to see running in seconds.
Learning — watch how a model structures a working app.
Throwaway experiments where install friction would kill the idea.
Iterating on a UI by describing changes instead of writing boilerplate.

Reach for something else when…

You need a real backend, database, auth, or secrets management.
The project must live in version control with a team workflow.
You're editing a large existing codebase (use a dedicated coding agent).
Strict compliance / data-residency rules apply to your code.
You need long-running, multi-file refactors across many modules.

🎈 ELI5

Before VibeIt can build anything it needs to know which AI to use and your key to use it. You also tell it how much of your project to show the AI each time (a little or all of it), and a few dials that change how "creative" the AI is. Set these once and save them.

Provider, model & API key

VibeIt is bring-your-own-key. You connect it to a model provider and it calls that provider directly from your browser.

Setting	What it does	Optimal choice
Provider	`OpenAI` or `OpenRouter`.	OpenRouter if you want to try many models (Claude, Gemini, DeepSeek, Qwen, etc.) behind one key; OpenAI if you only use GPT models and want first-party billing.
Model	Which model generates the code.	A strong coding model. Via OpenRouter you can point at frontier coding models; via OpenAI use the best GPT coding tier you have access to. Start strong, drop to a cheaper model only once your prompts are dialed in.
API Key	Your secret key for the chosen provider.	Paste your own. It's stored locally for your session. Treat it like a password — don't share a screen recording with the key visible.
Project name	Labels the current build.	Name it for the thing you're building so multiple projects don't blur together.

Key hygiene Your API key bills you directly. Use a key with spend limits set at the provider, and rotate it if you ever paste it somewhere shared. If a generation loops or runs away, hit Stop — every token costs you.

Focused vs Complete (context mode)

This toggle decides how much of your project gets sent to the model on each generation — the single biggest lever on both quality and cost.

Focused

Sends only relevant snippets.

Cheaper and faster per generation.
Best for small, localized changes ("change the button color", "fix this function").
Risk: the model may lack context it needs and guess.

Complete

Sends all project files.

The model sees everything — best for cross-file changes and keeping things consistent.
More expensive and slower; uses more tokens.
Best for early scaffolding and any change that touches multiple files.

Rule of thumb Start a project in Complete (so the model builds a coherent whole), then switch to Focused for the long tail of small tweaks. Flip back to Complete whenever a change spans files or the model starts contradicting earlier code.

Advanced: Temperature / Top P / Max tokens

Dial	What it controls	For coding
Temperature	Randomness / creativity.	Keep low (≈0.1–0.4). Code wants determinism, not flair. Raise only when brainstorming copy or visual concepts.
Top P	Nucleus sampling breadth.	Leave near default (≈1.0). Adjust temperature or Top P, not both at once.
Max tokens	Ceiling on output length per generation.	Set high enough that a full file isn't truncated mid-function. If output cuts off, raise it. If costs spike, lower it and work in smaller steps.

Global prompt

The Global prompt is a stable instruction block applied to every generation — VibeIt describes its purpose as "preserve behavior, minimal diffs." Use it to encode the rules you never want to repeat.

Global prompt — starter You are editing an existing project. Rules for every change: - Make the smallest diff that satisfies the request. Don't refactor unrelated code. - Preserve existing behavior, file structure, and naming unless I explicitly ask to change it. - Keep everything in vanilla HTML/CSS/JS unless I ask for a framework. - No external build step; the app must run by opening index.html. - If a request is ambiguous, choose the simplest interpretation and note the assumption in a comment.

Why this matters Without a Global prompt, each generation can quietly re-architect things, rename files, or pull in dependencies — and your preview breaks for reasons unrelated to what you asked. A tight Global prompt is the difference between "iterating" and "fighting the tool."

🎈 ELI5

Skills are little bundles of know-how you can hand the model so it's good at a specific thing (say, making charts a certain way). MCP servers are connections that let the model use outside tools. Both are optional — add them only when a plain prompt isn't enough.

Importing skills

Skills extend what the model knows how to do. VibeIt supports three import paths:

Path	How	Use when
Import skill from URL	Paste a direct link to a skill `.zip`, then Import Skill.	The skill is hosted somewhere public and stable.
Upload Zip	Upload a skill `.zip` from your machine.	You built the skill locally or downloaded it.
Public GitHub repo	Point at a public GitHub repository (or a tree within it).	The skill lives in a repo you want to pull the latest from.

Imported skills appear in the skills display area so you can see what's active. Keep only the skills a project actually needs loaded — every active skill adds context the model has to read.

Optimal skill use Treat skills like sharp tools, not decoration. One well-matched skill ("build accessible forms", "Tailwind component patterns") meaningfully lifts output. Five vaguely-relevant skills just dilute the prompt and cost tokens. Import, verify it helped, prune what didn't.

MCP servers

The MCP Servers field takes a JSON config. The default is empty:

Default { "mcpServers": {} }

Add an entry per server you want the model to be able to call. Shape:

MCP servers — example shape { "mcpServers": { "my-tool": { "command": "npx", "args": ["-y", "@example/mcp-server"], "env": { "API_KEY": "..." } } } }

Only add MCP servers you trust An MCP server can run commands and reach external services. Add servers you control or trust, keep secrets out of anything you'll share, and remove servers a project no longer needs. If you're just building a static front-end, you probably need none — leave it as { "mcpServers": {} }.

🎈 ELI5

The fast way to use VibeIt is a little loop: ask → watch → look → fix → repeat. Ask for a change, watch it build, look at the live preview, fix what's wrong, and go again. Save often so you can undo.

The optimal build loop

Scaffold in Complete mode. First prompt should describe the whole app — goal, screens, key behaviors, visual style. Let the model build a coherent base.
Read the Preview, not the prose. The model's summary of what it did is not evidence. Open the Preview (Zone 4), interact with it, find the gap.
Make one change at a time. Switch to Focused for small tweaks. One clear request per generation — bundled requests produce muddled diffs.
Save before risky changes. Save creates the point you can Undo back to. Save → try something bold → Undo if it regresses.
Hand-edit when it's faster. For a one-line fix, just edit the file in Zone 3 and Save — don't spend a whole generation on it.
Re-preview after every change. Reload the preview; confirm the change landed and nothing else broke.
Deploy or Download when the preview is right.

Files & editor

Zone 3 holds the generated files with these controls:

Control	What it does	Tip
Files / Editor tabs	Switch between the file list and the code editor.	Skim the file list after a Complete generation to see what the model actually created.
Save	Commits your manual edits into the project state.	Save before each generation so Undo has a clean point to return to.
Undo / Redo	Step backward/forward through saved states.	Your safety net. If a generation makes things worse, Undo immediately rather than prompting your way back out.
Download	Exports the project files to your machine.	Download a known-good version before a big experiment — it's your offline backup.
Deploy	Publishes the current project.	Deploy only a version you've previewed and are happy with.
Clear project files	Wipes the project.	Destructive. Download first if there's anything you want to keep.

Preview

Zone 4 renders the live app. Controls: Reload (re-render after a change), Fullscreen (test the real layout without the editor chrome), and the preview URL.

The preview is ground truth A generation can "succeed" in the log and still produce a broken app. Always interact with the preview — click the buttons, resize the window, try the unhappy paths — before you call a change done. Use Fullscreen to catch layout issues the split view hides.

Save, download & deploy

Three different "I'm done for now" actions, for three different reasons:

Save — checkpoint inside VibeIt so you can Undo/Redo. Do this constantly.
Download — pull the files to your machine. Do this at milestones and before risky experiments; it's your real backup and your escape hatch to a normal editor / git.
Deploy — publish the current project to a live URL. Do this only from a previewed, known-good state.

🎈 ELI5

Two habits make VibeIt feel great instead of frustrating: (1) say exactly what you want and change one thing at a time, and (2) save and download often so a bad generation can't cost you anything.

Best-practice playbook

Specify the destination, not the keystrokes. Describe the behavior and look you want; let the model choose the implementation. "A 3-column responsive pricing grid that stacks on mobile" beats "add a div with class row".
Lock the rules in the Global prompt. Minimal diffs, no new dependencies, vanilla stack — set once, never repeat.
Complete to build, Focused to refine. Match context mode to the size of the change.
One change per generation. Smaller asks = cleaner diffs = easier to verify and undo.
Keep temperature low. ≈0.1–0.4 for code.
Save → experiment → Undo. Treat Save as a checkpoint before anything bold.
Download at milestones. Your only real backup lives on your machine.
Prune skills and MCP servers. Keep only what the current project uses.
Believe the preview. Verify in Zone 4 before deploying.
Stop runaway generations. If the stream loops or drifts, hit Stop — you pay per token.

Patterns

"Scaffold, then sculpt"

One big Complete-mode prompt to stand up the whole app, then a series of small Focused-mode tweaks. Don't try to get everything perfect in the first prompt; get a coherent skeleton, then refine against the preview.

"Describe the bug, don't fix it for them"

When something's wrong, describe the symptom and where you see it ("the modal doesn't close when I click the backdrop") rather than prescribing the fix. The model usually finds a cleaner solution than a dictated patch.

"Checkpoint before the cliff"

Before any change you suspect is risky (a redesign, a framework swap), Save and Download. Then you can experiment fearlessly and roll back instantly.

"Hand-edit the small stuff"

Copy tweaks, a color value, a typo — just edit the file and Save. Spending a generation (and tokens, and latency) on a one-character change is the slow path.

Anti-patterns

❌ Bundling five requests into one prompt

"Add auth, change the theme, fix the footer, add a chart, and make it faster" produces a sprawling diff you can't verify. Do them one at a time.

❌ Trusting the log instead of the preview

"Done! I've added the feature" in Zone 2 is a claim, not proof. Open the preview and try it.

❌ Staying in Complete mode for every tiny tweak

You'll burn tokens resending the whole project to change a button label. Switch to Focused for localized edits.

❌ High temperature for code

Creativity in code generation shows up as inconsistency and bugs. Keep it low.

❌ Never downloading

The project lives in the browser. Clear project files, a cleared cache, or a bad generation can cost you work if you've never downloaded a backup.

❌ Letting old skills/MCP servers pile up

Stale skills and unused MCP entries add context noise and cost. Prune to what the current project needs.

Troubleshooting

Symptom	Likely cause	Fix
Output cuts off mid-file	Max tokens too low	Raise Max tokens, or ask for the change in smaller pieces.
Model keeps re-architecting / renaming	No (or weak) Global prompt	Add the "minimal diffs, preserve structure" Global prompt.
Change touches the wrong files / misses context	In Focused mode for a cross-file change	Switch to Complete for that generation.
Costs climbing fast	Complete mode + high Max tokens on every tiny edit	Use Focused for small edits; hand-edit one-liners; Stop runaways.
Preview blank or broken after a generation	Generated code introduced an error or a dependency	Undo to the last good state; re-prompt with "vanilla, no build step" reminder.
Lost work	Cleared files / no backup	Going forward: Save constantly, Download at milestones.

Copy-paste prompt library

Tested shapes for the most common VibeIt moves. Adjust the bracketed parts.

Initial scaffold (Complete mode)

Scaffold Build a [type of app] called "[name]". Goal: [what the user accomplishes with it]. Screens / sections: [list them]. Key behaviors: [the 3-5 things it must do]. Visual style: [mood — minimal / playful / retro-terminal / corporate], [color direction]. Constraints: vanilla HTML/CSS/JS, no build step, runs by opening index.html, responsive (works on mobile). Build the whole thing now. Keep the file structure simple.

Localized tweak (Focused mode)

Tweak Small change only — minimal diff. Where: [file / component / area]. Change: [exactly what should be different]. Leave everything else exactly as is.

Bug report (let it diagnose)

Bug There's a bug. Diagnose the root cause before changing anything. Symptom: [what I see]. Where: [which screen / action triggers it]. Expected: [what should happen instead]. Walk through the likely cause, then make the smallest fix. Don't refactor unrelated code.

Redesign a section (checkpoint first!)

Redesign Redesign only the [section] visually. Keep all behavior and data identical. New direction: [describe the look — layout, spacing, type, color]. Constraints: same stack, no new dependencies, still responsive. Show me the result; I'll keep iterating on the look.

Make it responsive / accessible

Polish Pass over the whole app for [responsiveness / accessibility]: - [Responsive] Ensure it works at 360px, 768px, and 1280px widths. No horizontal scroll. Tap targets ≥ 40px. - [A11y] Semantic elements, labelled controls, visible focus states, sufficient contrast, alt text. Make minimal changes to achieve this; don't restyle beyond what's needed.

Prepare to ship

Ship-ready Final pass before deploy: - Remove console logs, dead code, and placeholder text. - Confirm every interactive element works. - Add a one-line comment at the top of index.html describing what the app does. Don't add features. Just clean up.