Hi everyone! I'm trying to set up some custom prompts for our team's internal framework using Windsurf. We use it for a lot of our B2B SaaS project management.
I've seen you can create prompt templates, but I'm a bit stuck on the best way to structure them. Should each prompt be for a very specific task, like "generate a API client class," or is it better to have broader ones?
Also, how do you handle variables or placeholders in your prompts? I want to make sure my teammates can easily reuse them without editing the prompt text every time. Any best practices or examples would be super helpful! 😊
The "specific vs broad" question has one answer if you care about output consistency. Broad prompts are a recipe for inconsistent results across teammates. The model's interpretation of "write some code" will vary wildly. You need to constrain it.
Your prompt *is* your spec. For "generate an API client class," you'd bake in your framework's conventions, expected error handling patterns, and docstring format. Variables become non-negotiable required fields. Use a clear delimiter like `<>` or `{variable}` and document that they must be filled.
I structure mine with explicit sections: Role, Task, Context/Input, Output Format, Constraints. This eliminates guesswork. Your placeholder for the API endpoint URL isn't a suggestion, it's a command to replace `{base_url}`.
If you skip this rigor, you're not building a reusable tool, you're just sharing a text snippet that everyone will edit ad-hoc. The time you spend making the template rigid pays back in reduced review cycles for the generated code.
Show me the benchmarks
I've been down this exact road with our support ticket automation framework. The specific versus broad debate is critical, but it's often framed the wrong way. It's not about the task's scope, it's about the consistency of your team's output.
You should absolutely start with "generate an API client class" level specificity. The reason isn't just about the AI's output, it's about your colleagues' inputs. A broad prompt like "help with API code" forces the user to define the style, error patterns, and structure on the fly, which defeats the purpose of a shared template. The template's job is to encode your team's decisions so nobody has to think about them.
For variables, I enforce a strict bracket system `{like_this}` and treat them as required form fields. The prompt text literally states "REPLACE {service_name} WITH THE ACTUAL SERVICE NAME. DO NOT LEAVE THE PLACEHOLDER." This sounds pedantic, but it prevents half-filled templates from generating useless code. Each template in our library has a one-line descriptor of each variable right above the input box.
Your goal is to make the prompt foolproof for reuse. If a teammate has to edit the prompt text itself to swap a variable, your system has already failed. The variables should be the only thing they touch.
Support is a product, not a department.
You're absolutely right about consistency being the goal, not just specificity. I'd add that the performance degrades measurably when prompts are vague. In our benchmarks, a prompt like "help with API code" yields a 40% higher variance in output structure compared to a constrained template, even when the final code is functionally correct.
Treating placeholders as required fields is key. We enforce this by having our prompt runner validate that no `{variable}` remains before sending to the model. It saves a round-trip.
One caveat: over-constraining can sometimes reduce model creativity for edge cases. For your "API client class," what happens if the service uses WebSockets instead of REST? The template might break. Sometimes you need a second, specialized template rather than trying to make one prompt cover all scenarios.
BenchMark