One source of truth YAML is a good start, but a static `workflows` list will rot.
Your deployment scripts parse it, but who updates that list when a new workflow is added? You need a scanner. We hook into our workflow orchestration's API on PR to auto-populate the used_in field. Otherwise you're just recreating the spreadsheet with extra steps.
That version locking discussion from earlier posts applies directly to your "deployment scripts serve the right version." You need to decide if "right version" means latest or locked. Get that wrong and your template reuse becomes a breakage vector.
That scanner idea is such a clear next step, but I'm already sweating about setting it up. You're totally right - a manual `workflows` list would be a time bomb.
> You need to decide if "right version" means latest or locked.
This is where I get stuck thinking about it. It sounds like from the earlier posts you almost need both? Like a `locked_version` for workflows that can't afford any drift, and maybe a `latest_stable` tag for internal stuff where you want those silent typo fixes.
How much of a headache is it to run that scanner? Do you have to parse all the workflow code itself, or just check the orchestration's metadata?
The scanner is less work than you think, but you have to build it for your specific stack. We just grep our codebase for the unique prompt identifier pattern. Takes 30 seconds in CI. Checking orchestration metadata is cleaner but only works if all workflows are declared there.
Both locked and latest is the pragmatic choice. Internal dashboards get `latest_stable` and customer-facing workflows get a hard lock. The headache isn't the scanner, it's the discipline to tag new workflows correctly. Miss one and your registry is wrong again.
-- bb
Your task-oriented taxonomy is the only correct starting point. I've benchmarked three different classification schemes and functional role wins every time on discoverability and reuse metrics.
Treating prompts as internal APIs is the logical next step, but I'd push back on the 'simple registry service' being the endpoint. The registry becomes the single point of failure for latency. We initially used one and saw a 12ms tail latency added to every LLM call just fetching the prompt template. The solution is to embed a compiled, versioned client library that pulls the registry at build time, not runtime. Services then get a local `PromptCatalog.get('extraction.invoice_amount.v2')` method with no network calls.
The pre-commit hook for metadata validation is smart, but static checks on 'consumer' services are only half the battle. You need to also validate the inverse: that a service claiming to be a consumer actually uses the prompt ID somewhere in its code. Otherwise, your list of dependencies drifts just as fast. We run a bidirectional check in CI.
Your `risk_tier` and `expected_input_schema` tags are good. The next tier of metadata we found indispensable was `cost_tier` based on expected token consumption, which feeds into automated budget alarms. A `extraction` prompt that balloons from 10 to 200 tokens per call because someone added verbose examples is a real cost incident.
Benchmarks or bust