Skip to content
Notifications
Clear all

What's the best way to version control prompts alongside code?

1 Posts
1 Users
0 Reactions
2 Views
(@aurorab)
Reputable Member
Joined: 3 months ago
Posts: 339
Topic starter   [#28735]

Alright, everyone, I've hit a real-world snag that I think a lot of us are starting to feel, especially as we build more complex automations and customer journeys with our coding assistants.

My team's been using Claude and GitHub Copilot heavily to generate and refine workflows for our email service providers (think dynamic content blocks for ActiveCampaign, or complex segmentation logic for Mailchimp). The code it helps us write is neatly tucked into our Git repos, versioned, and reviewed. But the *prompts* we used to generate that code? They're scattered across Slack threads, personal notes, and copied-pasted into AI chat histories. It's a mess.

When we need to tweke a workflow six months later, we're left guessing: "What was the magic prompt that built this SendGrid dynamic template parser?" We lose the *why* and the *how it was built*, which is just as valuable as the final code.

So, I'm on a mission to version control prompts alongside the code they generate. I want them linked, reviewable, and part of our deployment story. I've been experimenting with a few approaches:

* **Inline Comments:** Putting the core prompt as a comment in the header of the generated script file. Simple, but feels clunky and can clutter the code.
* **Separate Prompt Files:** Having a `prompts/` directory with `.md` or `.txt` files named to match the corresponding script (e.g., `generate_segmentation_logic.md`). This keeps things separate but linked.
* **Git Hooks:** Using a pre-commit hook to automatically snapshot the prompt used (if pulled from a CLI tool) into a companion file. This is more advanced but promises good fidelity.
* **Docs-as-Code:** Treating prompts as documentation and using a system like Mintlify or even just a `README.prompts.md` in the repo root that structures them.

What I'm really after is a *practical workflow recipe*. Something that doesn't add too much overhead but gives us that crucial traceability.

Has anyone else set up a system for this? I'm particularly curious about:
- How you structure the relationship between prompt and output in the repo.
- If you include not just the final prompt, but the iterative conversation (that can be huge, I know!).
- Whether you've found tools that help diff or review prompt changes effectively.

Let's share our setups! I'll compile the best ideas and share back a concrete, step-by-step recipe we can all use.

—Aurora


don't spam bro


   
Quote