Prompt Template Variable and Placeholder Compliance Prompt

This prompt is for prompt engineering platform teams who need to programmatically verify that prompt templates are safe to render and execute before they reach a model. The job-to-be-done is automated template validation: catching unresolved placeholders, invalid variable names, missing default values, and naming convention violations that would otherwise cause runtime errors, silent failures, or garbled model inputs in production. The ideal user is a developer or AI engineer building a prompt management system, CI/CD pipeline, or internal tooling layer where templates are authored by multiple contributors and must be validated before deployment.

Use this prompt when your system assembles prompts from templates with square-bracket or double-brace placeholders and you need a structured validation report before rendering. It is appropriate for pre-commit hooks, PR checks, template registry validation, and deployment gates. The prompt expects a raw template string and an optional convention specification, and it returns a machine-readable report with syntax errors, undefined variables, missing defaults, and convention violations. Do not use this prompt for runtime variable injection, content moderation, or evaluating the semantic quality of the rendered prompt—it only checks template structure and placeholder hygiene.

This prompt is not a substitute for a deterministic parser or linter. If your template syntax is fully deterministic and you can validate it with a regex or AST parser, do that first. Use this prompt when templates have mixed syntax, natural-language instructions, or non-standard placeholder patterns that resist purely rule-based validation. Always pair the prompt's output with a deterministic post-check: if the prompt reports zero errors, run a simple regex scan to confirm no unresolved brackets remain. For high-risk deployments where a malformed template could expose internal prompts or cause unsafe model behavior, require human review of any template that fails validation before it can be merged or deployed.

This prompt template is designed for prompt engineering platform teams who need to programmatically verify that prompt templates are syntactically correct, free of unresolved placeholders, and compliant with internal naming conventions. It accepts a raw template string and a reference list of expected variables, then produces a structured validation report. Use this before any template enters a CI/CD pipeline, gets stored in a prompt registry, or is rendered in a production application. The prompt does not evaluate the semantic quality of the instructions—only the mechanical correctness of the variable and placeholder structure.

textCopy
You are a prompt template validator. Your job is to inspect a prompt template for variable and placeholder compliance and produce a structured validation report.

## INPUTS
- TEMPLATE: The raw prompt template text to validate.
  [TEMPLATE]
- EXPECTED_VARIABLES: A list of variable names that are expected to appear in the template. Each entry includes the variable name, whether it is required, and its expected type.
  [EXPECTED_VARIABLES]
- NAMING_CONVENTION: The naming convention rules for variables. Specify allowed patterns (e.g., UPPER_SNAKE_CASE, camelCase), forbidden characters, and any prefix/suffix requirements.
  [NAMING_CONVENTION]
- DEFAULT_POLICY: Rules for how missing defaults should be handled. Specify whether defaults are required for optional variables, what constitutes a valid default, and any forbidden default patterns.
  [DEFAULT_POLICY]

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "template_id": "string or null if not provided in template",
  "validation_passed": boolean,
  "errors": [
    {
      "severity": "error" | "warning",
      "category": "unresolved_placeholder" | "syntax_error" | "naming_violation" | "missing_required" | "type_mismatch" | "default_missing" | "default_invalid" | "unknown_variable",
      "location": "line number or character range where the issue occurs",
      "variable_name": "the variable or placeholder involved",
      "message": "human-readable description of the issue",
      "suggestion": "actionable fix recommendation"
    }
  ],
  "variable_summary": {
    "total_variables_found": integer,
    "required_present": ["list of required variables found"],
    "required_missing": ["list of required variables not found"],
    "optional_present": ["list of optional variables found"],
    "unknown_variables": ["variables found in template but not in expected list"],
    "variables_with_defaults": ["variables that have default values defined"],
    "variables_missing_defaults": ["optional variables without defaults, if required by policy"]
  },
  "naming_violations": [
    {
      "variable_name": "the violating variable",
      "violation": "description of which naming rule was broken",
      "suggested_fix": "a conforming variable name"
    }
  ],
  "syntax_check": {
    "balanced_braces": boolean,
    "placeholder_style": "square_brackets" | "curly_braces" | "mixed" | "unknown",
    "unclosed_placeholders": ["list of unclosed placeholder fragments"],
    "malformed_placeholders": ["list of placeholders with invalid internal syntax"]
  }
}

## CONSTRAINTS
- Only report issues that are objectively verifiable from the template text and the provided rules.
- Do not flag variables that are intentionally literal text (e.g., code examples showing [EXAMPLE] as output). If uncertain, flag as a warning with category "unknown_variable".
- Treat missing defaults for optional variables according to DEFAULT_POLICY. If the policy says defaults are required, flag missing defaults as errors.
- If NAMING_CONVENTION is empty or not provided, skip naming checks and note this in the report.
- If EXPECTED_VARIABLES is empty, skip required/missing checks and only validate syntax and naming.
- Do not evaluate the semantic quality of the prompt instructions. Only validate variable mechanics.

To adapt this template, replace each square-bracket placeholder with the actual data for your validation run. The [TEMPLATE] field should contain the raw prompt text exactly as it would be stored or rendered. The [EXPECTED_VARIABLES] field should be a JSON array of objects with name, required (boolean), and type (string) properties. The [NAMING_CONVENTION] field should describe your rules in plain language or a structured format your validator understands. The [DEFAULT_POLICY] field should specify whether defaults are required, optional, or forbidden for optional variables. After copying, test the prompt with at least three cases: a clean template with no violations, a template with missing required variables, and a template with naming convention violations. This ensures the validator catches what you expect before it gates any production deployments.

This prompt is designed to be called programmatically, not used in a one-off chat window. The primary integration point is a pre-deployment validation gate in your prompt lifecycle. Before a new prompt template version is merged or released, the harness sends the raw template string to the LLM, receives the structured validation report, and decides whether to block the release. The output schema is the contract: a JSON object with valid (boolean), errors (array of objects with line, severity, message), and warnings (array). Your application code should parse this JSON and act on it, not just display it to a human.

Build the harness with three layers: submission, evaluation, and gating. The submission layer collects the prompt template string and any optional context like a [VARIABLE_WHITELIST] or [NAMING_CONVENTION] regex. The evaluation layer calls the LLM with the prompt, using a low temperature (0.0–0.1) for deterministic results and a model that reliably produces structured JSON (e.g., gpt-4o, claude-3-5-sonnet). Implement a retry loop with a JSON parse validator: if the response fails to parse into the expected schema, retry up to 2 times with a stronger instruction to return only valid JSON. Log every raw response and parse attempt for debugging. The gating layer inspects valid and the errors array. Any error with `severity:

critical"or"error"` should fail the CI check. Warnings can be surfaced as annotations in the PR without blocking."

For prompt management platforms with a UI, expose the validation result directly in the editor. When a user saves a template, run the validation asynchronously and display inline markers on lines with unresolved placeholders or convention violations. Cache results keyed by a hash of the template content to avoid re-validating unchanged templates. If your platform supports prompt variables with default values, extend the harness to accept a [DEFAULT_MAP] input so the prompt can distinguish between a missing required variable and a variable that has a safe fallback. For high-compliance environments where a broken placeholder could expose internal variable names to end users, add a human review step for any template that modifies the variable set: require a second set of eyes on the diff before the validation gate passes.

Avoid wiring this prompt into the hot path of user-facing requests. Template validation is a build-time or save-time operation, not a runtime check. If you need runtime protection against unresolved placeholders in rendered prompts, implement a deterministic pre-flight check in your application code (e.g., regex scan for [A-Z_]+ patterns not present in your variable map) rather than calling an LLM per request. Use this LLM-based validation for the richer checks that regex cannot catch: convention violations, placeholder naming consistency across a template library, and detection of placeholders that look like they were meant to be variables but use the wrong bracket style.