What happened
Bolt.new launched Skills, reusable bundles of context, rules, and actions that its AI agent pulls in automatically while you build. Instead of typing out your preferred fonts, tech stack, or coding conventions at the start of every new project, you package that once as a skill and Bolt applies it when relevant.
Skills work at two levels. A project skill applies only to the app you’re currently building. A workspace skill is shared across your whole team, so everyone building in that workspace gets the same standards without repeating instructions. Bolt says skills trigger automatically as a project needs them: a framework-specific skill won’t activate on a project that doesn’t use that framework.
Bolt ships a library of pre-built skills at launch, covering theming, performance optimization, code review, framework configuration, deployment setup, and SEO and GEO (search and AI-citation) optimization. You can install one of these in a click, build a custom skill from scratch, or upload one from another tool. Bolt’s announcement doesn’t list a plan restriction or added cost for Skills, so treat access as available broadly on Bolt.new until the company states otherwise.
You manage skills from your account settings, where you can browse the pre-built library and start building your own.
Why it matters
The problem Skills addresses is real and specific: every AI app builder session starts from zero unless you re-explain your context. That repetition costs time on every new project, and it’s also where inconsistency creeps in. If you forget to mention a convention on project three that you mentioned on project one, your codebase drifts.
Packaging that context once and having it apply automatically is the same idea behind Cursor’s rules files or Claude’s own Skills feature, applied to Bolt’s own building process. What’s different here is the workspace-level sharing. A solo builder gets convenience. A small team gets something closer to a shared style guide that the agent actually enforces, not just documents.
The custom skill for a security review is worth calling out specifically. Bolt frames it as something you can package to flag vulnerabilities against your team’s policy. That’s a meaningfully different claim than a formatting preference, because a badly specified security skill could give you false confidence that checks are happening when they aren’t actually catching what you think they’re catching.
Who should care
This matters most if you build multiple projects in Bolt.new, or work with a small team that keeps re-explaining the same stack and conventions to the agent. If you’re a one-off, single-project user, the workspace-sharing benefit doesn’t apply to you yet, though the time savings from a personal preferences skill still might.
It matters less if your projects vary so much in stack and structure that there’s little to standardize between them. A skill only saves time when the pattern actually repeats.
What builders should do next
Start with one pre-built skill instead of building a custom one first. Install the code review skill or a framework configuration skill from Bolt’s library, apply it to your next project, and compare that build against your last one without it: how many times did you have to correct a convention the agent got wrong, and how much of your initial setup prompt did the skill replace.
If you build a custom skill, especially anything like a security review, write down what it’s actually supposed to catch before you package it. Test it against a project where you already know a specific issue exists, like a hardcoded secret or a missing input check, and confirm the skill actually flags it. A skill that silently misses the thing you built it to catch is worse than no skill at all, because it looks like coverage you don’t actually have.
End of article