A Python package called DynaPrompt shipped this week. The part that makes it actually clever isn’t the TOML support. It’s that you don’t need any config at all.
Here’s the idea: the dev behind this loved how dynaconf handles app configuration, structured files, automatic loading, clean variable management. So they built the same pattern for prompts. The analogy holds surprisingly well. App config and prompt management share the same pain points: scattered strings, brittle hardcoding, no clear ownership of what lives where. DynaPrompt treats your prompts as first-class configuration artifacts, not afterthoughts buried in function calls. If you’ve ever inherited a codebase where prompts live in three different files, two environment variables, and a comment someone left in Slack, you’ll feel the appeal immediately.
What’s new: define your prompts, variables, and schemas in TOML or YAML. DynaPrompt loads everything automatically. No more hardcoded strings scattered across your app. No more manual find-and-replace every time a variable changes. Instead of hunting through four files to update how you address a user, you change one variable file and every prompt that references it picks up the update on the next load. For teams with more than one person touching the codebase, this alone is worth the install. Prompt drift, where different parts of the app quietly diverge in how they talk to a model, is one of those bugs that takes a long time to trace. A centralized config layer kills it at the root.
The twist: you don’t have to write any config files. Drop a folder with your prompt files, variable files, and schemas inside. DynaPrompt discovers everything on its own and generates the config for you. The TOML is optional. That’s the part most tools miss. Most prompt management solutions start by asking you to configure the configuration system before you can use it. DynaPrompt flips that. You organize your files the way you’d naturally organize them anyway, point the library at the folder, and it figures out the rest. The generated TOML becomes a record of what it found, not a prerequisite for getting started. That difference matters a lot when you’re prototyping fast and don’t want overhead before you’ve proven the concept works.
🔧 How it works in practice:
- 📁 Create a folder with your prompt files and variable files (JSON works out of the box). Keep prompts as plain text or markdown files. Name your variable files to match the placeholder names you use inside the prompts. The naming convention is the whole API at this layer, and it stays intuitive enough that someone unfamiliar with the codebase can figure out the structure in under five minutes.
- Point DynaPrompt at the folder. It auto-discovers and loads everything. No imports scattered across modules, no global constants file you have to update manually every time something changes. One entry point, one folder, done.
- Use
{{user_name}}syntax in your prompts. Have a file calleduser_name.json. It swaps automatically on load. This works across nested prompts too, so if you have a system prompt that pulls in a sub-template, the variable substitution propagates through. You write the placeholder once and the library handles composition at every level. - Optional: grab the generated TOML config for a cleaner project structure going forward. Once you have it, you can version it in git, diff prompt changes in code review, and onboard collaborators without a verbal walkthrough of where everything lives. That TOML also becomes your audit trail when something breaks.
💡 Pro tip: This pattern pays off fast once you hit 10+ prompts across different use cases or models. The moment you need to version prompts, swap variables by environment, or onboard someone else to your setup, having a config layer saves you hours of debugging context. Consider the specific case where you’re running the same base prompt against a frontier model in production and a local model in dev. Without a config layer, you’re managing that difference manually everywhere it appears. With DynaPrompt, you set an environment-level variable for the model target and every prompt that references it updates automatically. Same logic applies to persona variables, tone instructions, or any prompt fragment that shifts between contexts. The folder-based discovery also makes it straightforward to hand prompt editing off to non-technical collaborators. A copywriter or product manager can open a folder, edit a plain text file, and ship a prompt update without touching a single line of Python. That’s a workflow most teams don’t realize they want until they’ve done it once.
Early-stage project with a solid approach. 🔗 DynaPrompt on GitHub is worth a look if you’re building anything with more than a handful of prompts. 🚀
DynaPrompt: prompts managing package
by u/SavingsWeather1659 in PromptEngineering