Prompt Anatomy for Storage

A stored prompt is not just the prompt text. It is the prompt text plus the metadata that makes it usable, maintainable, and improvable by anyone — not just the person who wrote it. Without metadata, a stored prompt is a black box. You do not know what it was designed to do, who last modified it, whether it has been tested, or where it has been known to fail. That black box is worse than no library, because it creates false confidence.

{
  "prompt_id": "sales-followup-discovery-v3",
  "version": "3.0.0",
  "created_by": "forge",
  "created_date": "2026-01-15",
  "last_modified_by": "closer",
  "last_modified_date": "2026-03-01",
  "last_tested_date": "2026-03-01",
  "intent": "Generate a post-discovery-call follow-up email that confirms pain points, builds credibility, and proposes a concrete next step",
  "use_case": "Sales — post-discovery follow-up",
  "model": "kimi-k2",
  "input_schema": {
    "prospect_name": "string",
    "company_name": "string",
    "primary_pain_point": "string",
    "next_step_proposed": "string",
    "next_step_date": "YYYY-MM-DD"
  },
  "output_schema": {
    "subject_line": "string",
    "email_body": "string, max 150 words"
  },
  "known_failure_modes": [
    "Tends to use enthusiasm inflation ('excited to') when pain_point is vague — provide specific pain point",
    "May include pricing references if proposal context is provided — add negative constraint if needed"
  ],
  "tags": ["sales", "email", "discovery", "follow-up"],
  "changelog": [
    { "version": "1.0.0", "date": "2026-01-15", "change": "Initial version" },
    { "version": "2.0.0", "date": "2026-02-10", "change": "Added tone specification after outputs were too formal" },
    { "version": "3.0.0", "date": "2026-03-01", "change": "Added negative constraint on pricing after incident in Feb" }
  ]
}

1. 1. Define the intent statement Write one sentence describing exactly what this prompt is designed to produce and for what purpose. If you cannot write this sentence clearly, the prompt is not yet ready for the library.
2. 2. Define input and output schemas What does the prompt require as input? What does it return? These schemas are the interface contract between the prompt and the systems that use it. Anyone who needs to integrate with the prompt should be able to do so from the metadata alone.
3. 3. Document known failure modes What inputs reliably produce bad outputs? What constraints have proven necessary through iteration? What edge cases has the prompt been tested on? This section converts individual learning into team knowledge.