Skip to main content

Managing Versions

The prompt repository uses date-based versioning to track which prompts your team is running and manage updates over time.

Checking Your Current Version​

The VERSION file at prompts/VERSION in your repository records the version you are currently running:

cat prompts/VERSION
version: 2026.02.23-1430
source_sha: abc123def456
released_at: 2026-02-23T14:30:00Z

If there is no VERSION file, your repository predates the versioning system. The next prompt update PR you merge will include one.

Comparing Versions​

Since versions are date-based (YYYY.MM.DD-HHMM), comparing them is straightforward — a higher number means a newer release.

To see what changed between your current version and an incoming update, review the PR diff or compare branches directly:

git diff main..prompts/2026.03.15-0900 -- prompts/

Rolling Back​

If a prompt update causes issues (e.g., a prompt change produces worse output for your use case), revert to the previous version:

# Revert the merge commit
git revert -m 1 <merge-commit-sha>

This creates a new commit that undoes the update while preserving your Git history. The next prompt update PR will re-include the reverted changes along with any new updates — you can review them again at that point.

Pinning a Version​

If you need to stay on a specific prompt version (e.g., for compliance or audit reasons):

  1. Do not merge new prompt PRs until you are ready to update
  2. Document the pinned version in your team's runbook
  3. When ready to update, review all accumulated changes in the latest PR before merging

Version History​

Your repository's Git log and merged PR history serve as a complete audit trail of every prompt version your team has adopted:

# View prompt update history
git log --oneline --grep="Update prompts to"

Each merged PR corresponds to a specific prompt release, making it straightforward to trace when a particular version was adopted and what changed.

Propagating Updates to Deployment Points​

When you merge a prompt update PR, your prompts/ directory is updated but your deployment points (IDE config files, CI/CD pipelines, API scripts) may still reference old prompt content. To propagate updates:

  • File-based deployments (.github/copilot-instructions.md, CLAUDE.md, .cursor/rules/) — These files typically reference or include prompt content directly. After merging an update, check whether any deployment files need to be refreshed with the updated prompt content.
  • API-driven deployments — If your scripts read prompts from disk at runtime (with open("prompts/...") as f), they pick up updates automatically after the merge. No action needed.
  • CI/CD pipelines — Pipelines that reference prompts by path pick up updates on the next run. Pipelines that have prompts inlined in configuration files need to be updated manually.

If you use the Team and Enterprise deployment pattern, your automation layer handles propagation.

Multi-Team Version Management​

If different teams in your organization use different prompt subsets:

  • Shared repository: All teams share one prompt repository. Each team reviews and uses only the prompts relevant to their stack.
  • Separate repositories: Each team gets their own prompt repository with only the relevant prompt categories. Contact Manicode to configure per-team delivery.