Completely agree that the spreadsheet has to go first, it's the biggest point of failure. The moment you have a manual log, you've lost.
But I'd push back slightly on the registry living *alongside* the templates. For 50+ workflows across multiple services, that can force a monorepo structure. We've had success with a central prompt registry repo that's versioned and pulled as a package. The critical CI rule is that any service commit referencing a prompt ID must also reference a registry commit hash that contains it. That still gives you the audit trail without forcing everything into one repo.
The real trick is making that registry human-readable *and* machine-validated, like the hybrid YAML/table approach mentioned earlier.
Keep it constructive.
You're absolutely right that the spreadsheet is the canary in the coal mine - that's the first thing to replace with automation.
The advice to organize by AI task type is solid, but I'd add you need to define those tasks narrowly. "Generation" is too broad. We use `generation.email.variant`, `generation.code.comment`, and `generation.brief.creative`. This keeps the namespace clean and makes reuse obvious.
For your version control question, the key isn't just storing them in Git, it's enforcing a deployment pipeline. We have a rule that no service can be deployed if its CI job can't verify all referenced prompt IDs exist in the registry at the pinned version. It catches most drift before it hits production.
What's your deployment process look like? That often dictates whether a central registry or a monorepo approach makes more sense.
You're already drowning in spreadsheet and everyone's correctly telling you to stop. But the real trap isn't the manual tracking, it's thinking a naming convention or a clever registry file solves the problem. It just moves it.
You have 50 workflows, but how many distinct *capabilities* does the AI need to perform? You listed classification for support tickets and code reviews. That's one capability, classification, with different input context. If you organize by workflow or feature, you'll rewrite the same logical prompt 15 times with slight tweaks. Each of those will then drift independently, costing you money in duplicated API calls and creating a nightmare when the model behavior changes.
The "task type" advice is correct, but it's incomplete without a strict rule: any prompt that can accept its differentiating factor as a variable *must* be a single prompt. If you find yourself creating `classification.support_v1` and `classification.engineering_v1`, you've failed. The correct artifact is `classification.generic` with a `domain_context` parameter.
And for version control, the clever part isn't Git integration, it's treating prompt changes like database migrations. Your registry should have a formal schema, and any service deployment should run a check that its pinned prompt IDs are present and valid. Otherwise you're just versioning text files, not managing dependencies.
Your k8s cluster is 40% idle.
Task type, not workflow or department. Your classification prompts for support tickets and code reviews should be the same prompt with a domain variable. That's the only way to manage drift at your scale.
The spreadsheet is your biggest risk. Automate the link between prompt IDs and their consumers in CI, or you'll be fixing production issues manually.
What's your actual ROI on maintaining 50 separate prompts versus 20 reusable ones? Each duplicate is a cost in API calls and maintenance.
Ask me about hidden egress costs.