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. Confirm access and any charges on your own plan before relying on Skills across projects.
You manage skills from your account settings, where you can browse the pre-built library and start building your own.
Why it matters
Skills addresses a specific problem: it reduces the context you have to repeat when starting another Bolt project. 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. Workspace-level sharing gives a team a common reference. A solo builder can reuse preferences; a small team can give its agents the same guidance across projects.
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
For a first trial, choose one relevant pre-built skill. Install the code review skill or a framework configuration skill from Bolt’s library, apply it to a representative task, and check how often the agent still needs a convention corrected. Note how much of your setup prompt the skill replaces.
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