We're starting to use Windsurf for our internal admin tools. I noticed when I write something like "create a user profile form," it generates plain HTML with `` and `
How do I configure Windsurf to use those specific component names instead of basic HTML? Is this about setting up a custom recipe, or is there a project-level config file for this? I want to avoid manually rewriting every generated piece of code.
learning every day
Ah, that's a super common pain point when you first start. I hit the same wall with our Salesforce Lightning components.
For your immediate need, you've got two good paths. The quick fix is to explicitly prompt for it. Instead of "create a user profile form," try "create a user profile form using our design system's TextInput and PrimaryButton components." It learns from the context pretty fast.
For a more permanent, project-level solution, you should absolutely set up a custom recipe. That's where you can bake in your component library names as the default for forms, buttons, and inputs. It's basically teaching Windsurf your team's dialect once, so it speaks it every time. The config isn't a single magic file, but the recipe structure is straightforward.
Has anyone on your team already built a recipe for your design system? Sometimes the infra or platform group has one floating around.
Spot on about the recipe being the real fix. I'd add that if you're on a monorepo, you can point the recipe at your actual component library's export file - Windsurf will read the component names and props from there. Saves you from manually maintaining a mapping.
Just a heads up though, the "learns from context fast" part can be flaky across different chat sessions. I've had it revert to basic HTML after a browser restart. Recipes stick.
NightOps
You're correct that this is a configuration challenge, not a prompt engineering problem to solve repeatedly. The custom recipe approach others mentioned is indeed the primary method for establishing those defaults project-wide.
One nuance often overlooked is that recipe effectiveness depends heavily on how you define the component mapping. A simple text substitution for "input" tags will fail when the underlying model needs to understand prop interfaces. You'll get better consistency if your recipe includes not just the component name swap but also a short, clear spec of the required props, mimicking how you'd document it for a new developer. This helps the assistant reason about the component as a functional unit rather than just a renamed tag.
Have you looked at whether your design system provides TypeScript definition files? Those can sometimes serve as a more structured reference point for the recipe than a plain list of component names.
Let's keep it constructive
That's exactly the kind of manual rewrite I'm hoping to avoid, so thanks for posting it. The custom recipe path seems like the right way to go, but I'm a bit cautious about setting it up correctly the first time.
When you define a recipe for your design system, do you map each HTML element to its React component counterpart? Like, do you literally tell it "use PrimaryButton instead of button tags" in a config, or is it more about feeding it example code? I'm worried I'll make a recipe that only half-works and introduces weird bugs.
Also, is there any risk of it using the design system components but totally messing up the props? That would be just as much work to fix.