Bolt

Overview

Bolt scaffolds full-stack web projects from prompts and runs them in-browser. Unlike v0 (which generates components) or Lovable (which builds up a project across many turns), Bolt is at its best when you give it everything in the first prompt and let it generate a working starting point — auth screens, data views, realtime listeners, env wiring — in one shot.

For chisel.to, that means a single opening message that:

• Pastes the llms.txt brief so Bolt knows the backend's shape.
• Specifies the framework you want (Next.js, Vite + React, SvelteKit, etc.).
• Names the screens, the auth flow and the realtime channels.

You don't have to get it perfect on the first try — Bolt iterates well — but front-loading saves rounds.

Requirements

• A Bolt account (e.g. bolt.new).
• A chisel.to project with at least one publishable API key.
• Your llms.txt from the Connect page, on the clipboard.

No local installs. Bolt provides the runtime.

Get llms.txt

1. Open your project in the chisel.to dashboard.
2. Open the Connect card.
3. Copy llms.txt contents (or click Download, open the file, copy all).

The brief is markdown — short, dense, designed to land in the first prompt with room left over for instructions.

The first prompt

The single highest-leverage thing in Bolt: a strong opening prompt. Use this template — fill the bracketed parts with your specifics:

Scaffold a [Next.js 15 / Vite + React 19 / SvelteKit / your-framework] project
that uses the backend described below.

Use real endpoints from the brief — do not invent URLs, columns or response
shapes. Use the publishable API key from VITE_CHISEL_KEY (or
NEXT_PUBLIC_CHISEL_KEY for Next.js) and the base URL from VITE_CHISEL_URL.

<<< chisel.to backend brief
[paste the entire contents of llms.txt here]
>>>

Create:
- src/lib/chisel.ts: a typed fetch helper that prepends the base URL and the
  Authorization header.
- Auth: /sign-up, /sign-in, /sign-out. Hold access tokens in memory only.
- Routes: [list the screens you want — e.g. /feed (paginated posts where
  status=published, sorted -created_at), /post/[id] (single post detail),
  /compose (auth-required form to create a post)].
- Realtime: subscribe to the "[channel-name]" channel on /feed and prepend new
  items.

Use Tailwind for styling. Use SWR for data fetching. Surface 422 validation
errors inline next to fields.

Confirm by listing the resources from the brief, then generate the files.

Three things make this prompt work:

• Framework declared first — Bolt's scaffolding differs significantly across React vs. Svelte vs. Next, and naming it up front avoids a costly redo.
• "Confirm by listing the resources" before generating — gives you a chance to catch a missing brief before Bolt commits to scaffolding the wrong thing.
• Concrete screen list — vague prompts produce vague apps; specific screens produce specific apps.

Setting env vars in the Bolt project

After the first prompt, Bolt will have referenced VITE_CHISEL_URL / VITE_CHISEL_KEY (or the Next.js equivalents). Set them in Bolt's project env config:

• Open the env tab in the Bolt project sidebar.
• Add VITE_CHISEL_URL = your project's base URL (from the brief).
• Add VITE_CHISEL_KEY = your publishable API key (from the chisel.to dashboard's API keys page).

Bolt restarts the preview when env vars change. After it reboots, the app should be live against your backend.

Verify it works

Once the preview boots:

1. Open the /sign-up screen in the preview window.
2. Create a throwaway test user.
3. If you're redirected to /feed and it lists posts from your real backend, the integration is live.

If something doesn't work, ask Bolt to surface the actual error:

The /sign-up form fails when I submit. Show the network request and response in
the preview console so I can see what the backend returned. Don't change any
code yet.

Bolt will wire up the console log so you can read the platform's actual error.

Common workflows

1. Add a feature after the scaffold

Add a "favorites" feature.

- Read the brief for the favorites resource (user_id, post_id, created_at).
- Add toggleFavorite(postId) and isFavorited(postId) helpers in
  src/lib/favorites.ts using the chisel helper.
- Update the post card to show a heart icon; toggle it via the new helpers.
- Add /me/favorites that lists the current user's favorites.

2. Generate an admin section

Add /admin/posts. It requires the signed-in user to have role=admin (check via
/auth/me). Render the posts table with column-aware filters derived from the
schema — status as a dropdown of allowed values, views as a number range,
created_at as a date range. Inline-edit mutable columns and add a Publish
button that calls the custom action.

3. Add Stripe-style checkout with the platform payments API

The brief lists the platform's payments endpoints (chisel.to wraps Stripe / Paddle / Polar). Bolt can use them directly:

Add /pricing with two tiers. Clicking "Start" on a tier should POST to the
platform's payments/checkout endpoint and redirect to the returned URL. Handle
the success and cancel return URLs at /billing/success and /billing/cancel.

4. Marketing shell from /site

Build the public marketing pages (/, /about, /pricing). Server-fetch /site at
render time and use the returned site name, description, logo_url and SEO
defaults to populate <head> metadata and the header brand. No auth required.

5. Investigate a 500 from inside Bolt

POST /compose is returning 500. From the preview console, log the request body
and the raw response. Then check whether the body matches the columns described
in the brief for posts. Don't change the form yet.

Iterating in the same project

Bolt keeps the brief in scope across follow-up turns within a single project, so you usually don't need to repaste it. A couple of guardrails:

• Re-anchor when you switch areas. "Reread the chisel.to backend brief, then build the /messages screen" — explicit re-read keeps the model from drifting.
• Don't let one iteration redefine your data shape. If a styling iteration says "group by category," push back: "There's no category column. Group by tags (which is a JSON array)."

Deploying the preview

When you're ready to deploy what Bolt built, two production considerations matter:

• Switch the env vars to live keys. Bolt's env tab holds your publishable key — switch from a test key to a live key in your hosting provider's env panel before going live.
• Add the production domain to CORS. Open chisel.to's Domains & access page for your project and allowlist the production origin. The Bolt preview domain doesn't need to be allowlisted in production.

Auth + sessions

Bolt defaults can drift toward "throw the token in localStorage." Spell out the token policy in the first prompt, and reinforce when it lands incorrectly:

• Access token in memory only (React context or a small store).
• Refresh token in an httpOnly cookie set by a server action (Next.js) or a tiny serverless function (Vite + Cloudflare Workers).
• Social providers from the brief work via the platform's social redirect flow — no extra Bolt setup needed.

Realtime support

The brief tells Bolt how to subscribe to channels. The first prompt should name the channels you want, e.g.:

Realtime: subscribe to "posts:published" on /feed and prepend new posts; show
a small "New" badge for 5 seconds. Subscribe to "thread:{id}" on /threads/[id]
and append new messages.

Forgetting to mention realtime is the single most common omission — Bolt will happily ship a polling-only app if you don't ask for the live channel.

Refreshing context when the schema changes

Bolt doesn't auto-track your backend. When the schema changes, drop the new llms.txt into the conversation:

The chisel.to schema has changed. Reread the updated brief below and update any
affected screens / types. Do not introduce columns or endpoints that aren't in
this new brief.

<<< updated chisel.to backend brief
[paste the new llms.txt here]
>>>

For ongoing projects, save the latest llms.txt at docs/chisel.llms.txt in the Bolt project so anyone iterating later can grab the current copy.

Security & key hygiene

• Publishable keys only inside Bolt. Server-scope keys are for server-side use, never inside a preview env panel.
• Bolt previews are shareable — assume anything in the env panel can be seen by someone with the link.
• For destructive operations (delete tables, mass-delete rows), don't trust Bolt to do them — those belong in the dashboard or in an MCP-aware tool like Cursor.

Troubleshooting

The scaffold ignores the brief and uses Supabase / Firebase

Bolt's training leans toward popular BaaS by default. Restate explicitly in the first prompt: "Do not use Supabase or Firebase. The backend is the chisel.to project described in the brief. Use the brief's URLs and endpoints exclusively."

"Failed to fetch" with CORS errors

Add Bolt's preview domain to Domains & access in your chisel.to project. While iterating you can wildcard the relevant subdomain; tighten down for production.

Auth screens return 401

Confirm the env vars are set and the publishable key matches the project the brief came from. Check the request in the Bolt console — the Authorization header should carry your key as a Bearer token.

The preview hits the wrong URL

Open src/lib/chisel.ts and confirm the base URL is read from env, not hard-coded. If hard-coded, ask Bolt: "Move the base URL into VITE_CHISEL_URL and read it from env."

Bolt regenerates files we already edited

It treats unspecified pieces as fair game. Scope iterations explicitly: "Touch only /admin/posts and src/lib/admin.ts. Don't change auth, the feed or the helper."

Next steps

• Once you've shipped the Bolt scaffold, take the code into Cursor or Windsurf for MCP-aware iteration.
• If you want a component-focused prompt-only flow instead, see the v0.dev guide.
• If you want pinned-context iteration, see the Lovable guide.