- In short
- Prompt versioning and plugin dependency management extend configuration management to the parts of a Claude system that change most often. Prompts are versioned so a change can be reviewed, rolled back, and tied to an eval result; plugin and dependency versions are pinned so the configuration stays reproducible; and the discipline ties prompt, model, and plugin versions together into a single coherent release rather than letting any one of them drift on its own.
Configuration is more than the model
The model is not the only part of a Claude system that shapes its behavior. The prompt drives what the model does on every call, and the plugins extend what the application can do. If you pin the model but let the prompt and plugins drift, you have only pinned a third of the system. Prompt versioning and plugin dependency management close that gap, and the Claude Certified Developer - Foundations (CCDV-F) exam treats them together under Task Statement 2.6, Configuration Management, at apply level: you are expected to design a release discipline, not just name its parts.
This knowledge point builds on CLAUDE.md and settings.json configuration, which establishes that configuration should be explicit, shared, and version-controlled. It is the natural partner of model version pinning: pinning the model secures one variable, and versioning prompts and dependencies secures the other two, so the whole system is reproducible together.
- Prompt versioning
- Treating each production prompt as a versioned artifact: changes are reviewed before they ship, tracked so they can be rolled back, and tied to the eval result that measured the version's behavior.
Why prompts need versions
A prompt is not a throwaway string; it is a critical piece of production behavior. Versioning it means treating a prompt change the way you treat a code change. Three benefits follow, and the exam names all three. A change can be reviewed before it goes live, so a second pair of eyes catches a regression before users do. It can be rolled back, so when a new prompt turns out to behave worse than expected, you can return to the previous known-good version instead of scrambling to reconstruct it. And it can be tied to an eval result, so each version carries evidence of how it actually performed rather than a hopeful assumption that it works.
That third benefit is the one that makes the others meaningful. Tying a prompt version to an eval result means every version is linked to the evaluation run that measured its behavior. Now a change is not just "the new wording looked better"; it is "version 4 scored higher than version 3 on our eval suite, here is the run." That link is what turns prompt iteration into an auditable, reversible process. Without it, you cannot say which version was good, cannot justify a change, and cannot confidently roll back, because you no longer know what "good" was.
Pinning plugins and dependencies
The second strand is dependencies. Just as the model and prompt determine behavior, so do the plugins an application uses and the dependencies those plugins rely on. Plugin and dependency versions are pinned so the configuration stays reproducible: the application runs the same plugin behavior every time until you deliberately change a pin. This is the same reproducibility logic developed in plugin management in Claude applications, now applied as part of a versioned release rather than as a one-off setup choice.
The point of pinning dependencies is that an unpinned dependency is a hole in your reproducibility exactly the size of that dependency. If the model is pinned and the prompt is versioned but a plugin is free to update itself, the application's behavior can still shift without any deliberate change on your part, because the unpinned plugin moved. Reproducibility is only as strong as its weakest unpinned link, so configuration management pins every link that can change behavior.
Tying it into one coherent release
The unifying idea, and the reason this knowledge point sits at apply level, is that configuration management ties prompt, model, and plugin versions together into a single coherent release. Behavior is a function of all three, so reproducibility requires managing all three as a unit. A release is not "the prompt we happened to have live plus whatever the model and plugins resolved to"; it is a specific prompt version, a specific pinned model, and specific pinned plugin and dependency versions, recorded together.
That coherence is what makes a system genuinely reproducible and diagnosable. When behavior changes, you can point to exactly which version of which component changed, because they move together as deliberate releases rather than drifting independently. And when something regresses, you can roll the whole release back to a known-good combination, not just one part of it while the others stay mismatched. The skill the exam tests is recognising that pinning any one component in isolation is insufficient; the release is the unit.
What the exam tests you on
This knowledge point sits in Domain 2, Applications and Integration, the highest-weighted domain on the CCDV-F exam at roughly 33 percent, and it is assessed at apply level. Two traps recur.
The first trap is changing a production prompt in place with no version history or rollback path. Editing the live prompt directly, with nothing tracking what it was before, destroys the ability to review the change, roll it back, or connect it to an eval result. A scenario where a prompt was "just tweaked" in production and now behaves worse, with no way back, is exhibiting this fault. The fix is to version the prompt so every change is reviewable, reversible, and tied to evidence.
The second trap is pinning the model but leaving prompts and plugins unversioned. This is the partial-discipline mistake: a team feels safe because the model is fixed, yet behavior can still drift because the prompt was edited in place or a plugin updated itself. The correct instinct is that reproducibility requires versioning all three, prompt, model, and plugins, as one coherent release, not just the model.
Misconception
Prompts are just text, so editing the live prompt directly when I want to improve it is fine.
What's actually true
Misconception
I pinned the model version, so my application's behavior is now fully reproducible.
What's actually true
Worked example
Worked example
A team pins its model but keeps editing the production prompt directly, then hits a regression.
Confident because the model is pinned, the team treats the prompt as a live string they can tweak whenever they want. One afternoon someone refines the wording to handle an edge case, edits it straight in production, and moves on. Two days later support reports that a common request now gets a worse answer. The team wants to revert, but there is no record of the previous prompt, no review of the change, and no eval run tied to either version, so they cannot even say for certain which edit caused the regression or what the good version looked like.
They rebuild the discipline properly. Prompts become versioned artifacts: each change is reviewed before it ships, tracked so any version can be restored, and tied to the eval run that measured it, so "better" is a number, not a hunch. They also pin their plugin and dependency versions, closing the last path by which behavior could drift unannounced. Finally, they package the prompt version, the pinned model, and the pinned plugins as one release, so from now on a behavior change traces to a specific, deliberate release and can be rolled back as a unit.
The judgment on display is exactly the apply-level skill Task Statement 2.6 tests: version the prompt, pin the dependencies, and tie all three moving parts into one reproducible release.
How it shows up on the exam
Questions describe a system that lost reproducibility and ask what discipline was missing. A prompt tweaked in place with no way back points to missing prompt versioning. Behavior drifting despite a pinned model points to unversioned prompts or unpinned plugins. The correct answer always returns to the same principle: reproducibility is a property of the whole release, so prompt, model, and plugin versions are managed together, each change reviewable, reversible, and tied to evidence.
This knowledge point completes Task Statement 2.6 alongside model version pinning and rests on the configuration foundations in CLAUDE.md and settings.json configuration. Together they describe a Claude system whose behavior is deliberate, shared, and reproducible from one release to the next.
A team is proud that their Claude application uses a pinned model, yet its behavior still shifts unpredictably between deployments. Which gap most likely explains this?
People also ask
Why should prompts be versioned?
What does it mean to tie a prompt version to an eval result?
Why pin plugin dependencies alongside the model?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.