Alright, let's cut through the "just create a shared doc" nonsense. You want reusable prompt templates for a team? You're not just sharing text, you're trying to enforce a workflow and avoid the inevitable drift where Bob's "optimized" version silently breaks three key assumptions.
Treating prompts like config files we throw into a Google Doc is how you get an incident at 2 AM. I've seen it: a "minor tweak" to a summarization prompt for alert routing stripped out all timezone context, turning "increased latency in us-east-1" into just "increased latency." Chaos ensued.
So, you need structure, validation, and maybe a little version control. Here's a contrarian take: don't start with the AI platform's "template" feature. Start with a schema. Define what a template *must* contain and what it *can* contain.
Here's a naive YAML example that's still miles better than a text blob:
```yaml
apiVersion: prompt.playground/v1alpha1
kind: Template
metadata:
name: incident-summary-extraction
version: 1.2
description: Extracts structured incident details from raw chat logs.
spec:
systemContext: |
You are a senior SRE analyzing incident chat transcripts.
Extract information strictly according to the provided schema.
userPrompt: |
Extract the following from the transcript:
- Primary service affected
- Start time (ISO 8601)
- Root cause (if identified)
- Mitigation action taken
Transcript: {{.transcriptText}}
parameters:
- name: transcriptText
type: string
required: true
description: Raw chat log text
constraints:
maxOutputTokens: 500
temperature: 0.1
tests:
- input:
transcriptText: "2024-05-27 03:14 UTC [Alice] db-03 CPU 100%. [Bob] failover to db-04 initiated. [Charlie] confirmed latency drop."
expectedOutputContains:
- "db-03"
- "2024-05-27T03:14:00Z"
```
Now, you can store this in Git, hook up a linter to validate the schema, and even run the test cases in CI against the Playground API to catch regressions before Bob merges his "refactor." The real value isn't the YAML itself—it's forcing the team to think about parameters, constraints, and validation. Otherwise, you're just herding cats with Markdown.
Schema's a good start, but you need enforcement. That YAML is just a spec; it doesn't stop Bob from deploying a broken 1.3. You need a linter in your CI/CD pipeline. Something that validates the spec against your schema *and* runs a basic smoke test against a known-good input/output pair.
We do this for our Kubernetes admission controllers. A failed prompt template shouldn't even get to a staging environment.
Trust but verify, then don't trust.