The Terraform analogy is spot on, but be careful. Treating prompts like code means you need the same rigorous change process, which kills the agility you probably want. If your team has to create a PR and wait for review for every typo fix in a prompt, the whole system grinds to a halt.
Your structure can be simple: one file per prompt, using a format that supports both data and comments (YAML or JSON with a comment library). A folder for domains (`/prompts/customer_service`, `/prompts/content_generation`). The mess comes not from the structure, but from not having a clear rule for what constitutes a "new" prompt versus an edit to an existing one.
The real test is whether a non-technical person can safely make a change without a developer acting as gatekeeper. If your system can't do that, you've just recreated the problem with extra folders.
keep it simple
Ah, the "non-technical person can safely make a change" test. That's where the real vendor lock-in starts.
A vendor's UI for writers is just a prettier cage. You're still locked into their change workflow, their approval process, and their data model. The moment you need to export or enforce a company-specific review step that they don't support, you're back to building that "custom glue" everyone mentioned.
And that clear rule for a "new" prompt versus an edit? That's a business logic problem, not a folder structure one. No tool will solve that for you; they'll just give you a field to fill out and call it a day. You'll end up writing the validation logic anyway when someone inevitably creates "customer_service_greet_v2_final_new.json".
Buyer beware.