Pre-Commit Prompt Validation Prompt Template

This prompt is designed for prompt engineers who need a fast, local validation step before committing prompt changes to a shared repository. It acts as a pre-commit hook that analyzes a unified diff of your prompt against a set of defined schema rules, consistency checks, and regression assertions. Use it when you want to catch malformed instructions, conflicting constraints, or broken output schemas before they reach a CI/CD pipeline or a code review. This is not a replacement for a full regression test suite or canary deployment analysis; it is a lightweight gate that prevents obvious mistakes from leaving your local machine.

The ideal user is a prompt engineer or AI developer working in a local environment who has just modified a system prompt, tool definition, or structured output schema. The prompt expects three inputs: a unified diff of the prompt change, a ruleset defining validation criteria, and optional regression test cases. It returns a structured pass/fail report with specific violation locations and severity levels. Do not use this prompt when you need to evaluate semantic drift, measure production performance, or assess cross-model behavior—those require the full CI/CD gate and canary analysis prompts in this pillar. This prompt is also unsuitable for validating multi-agent coordination logic or complex tool-use chains that require execution-based testing.

To integrate this into your workflow, pipe the output of git diff for your prompt file into this template along with your team's validation ruleset. The ruleset should define checks like 'no unresolved placeholders,' 'output schema matches expected JSON Schema,' and 'instruction count has not changed by more than 10%.' After running the prompt, review any BLOCKER violations before committing. For WARNING level findings, use your judgment—these often flag acceptable trade-offs. If the prompt returns a FAIL status, fix the cited violations and re-run before pushing. Store your ruleset in version control alongside your prompts so the validation logic evolves with your prompt engineering practices.

This template is designed to be pasted directly into a local pre-commit hook script or a CI validation step. It accepts the original prompt, the proposed new version, and a set of validation rules, then produces a structured pass/fail report. The goal is to catch structural regressions, missing placeholders, and instruction contradictions before they reach a shared branch, saving review cycles and preventing broken prompt deployments.

textCopy
You are a prompt validation engine running in a pre-commit hook. Your task is to compare an original prompt against a proposed new prompt version and validate the diff against a provided set of rules.

## INPUTS

### ORIGINAL PROMPT
[ORIGINAL_PROMPT]

### NEW PROMPT
[NEW_PROMPT]

### VALIDATION RULES (JSON Schema)
[VALIDATION_RULES]

### GOLDEN TEST CASES (Optional)
[GOLDEN_TEST_CASES]

## INSTRUCTIONS
1. Parse the ORIGINAL PROMPT and NEW PROMPT as complete text blocks.
2. Apply each rule in VALIDATION_RULES sequentially.
3. For each rule violation, record the rule ID, violation type, exact location (line number or section), and a description of the violation.
4. If GOLDEN_TEST_CASES are provided, simulate the expected output for both prompts and flag any semantic regressions where the new output deviates from the expected behavior defined in the test case.
5. Classify the overall result as PASS, FAIL, or WARNING.
   - PASS: No violations found.
   - FAIL: One or more critical violations found (schema break, missing required placeholder, contradictory instruction).
   - WARNING: Non-critical issues found (minor phrasing change, optional field missing).

## OUTPUT SCHEMA
Return a single JSON object with the following structure:
{
  "status": "PASS" | "FAIL" | "WARNING",
  "summary": "Brief description of the overall result",
  "violations": [
    {
      "rule_id": "string",
      "severity": "critical" | "warning",
      "location": "string (e.g., 'line 12', 'system prompt section')",
      "description": "string"
    }
  ],
  "regression_flags": [
    {
      "test_case_id": "string",
      "original_output_summary": "string",
      "new_output_summary": "string",
      "deviation": "string"
    }
  ],
  "recommendation": "Proceed with commit" | "Fix violations before commit" | "Review warnings before commit"
}

## CONSTRAINTS
- Do not modify the prompts; only analyze them.
- If the NEW PROMPT is identical to the ORIGINAL PROMPT, return a PASS with an appropriate summary.
- If VALIDATION_RULES is empty or malformed, return a FAIL with a description of the invalid rules.
- Treat missing required placeholders as critical violations.

To adapt this template, replace the square-bracket placeholders with your actual data. The [VALIDATION_RULES] placeholder expects a JSON schema defining your checks—for example, required sections, forbidden phrases, or placeholder naming conventions. If you do not have a golden dataset, omit the [GOLDEN_TEST_CASES] block or pass an empty array. For high-risk prompt changes, such as those affecting safety policies or financial calculations, always include a representative set of test cases and consider adding a manual review step after the automated check passes. Wire this into your pre-commit flow by saving the output JSON and failing the commit if status is FAIL.

This prompt is designed to run inside a local pre-commit workflow, not as a standalone chat interaction. The goal is to catch instruction drift, schema violations, and basic regression risks before a prompt change ever reaches a shared branch or CI pipeline. The harness should invoke the model with the prompt template, the current prompt version, the proposed diff, and any relevant golden test cases, then parse the structured pass/fail report to block the commit on failure.

To implement this, create a script (e.g., .git/hooks/pre-commit or a CLI command wrapped by lint-staged) that does the following: (1) detects changed prompt files in the staging area, (2) computes a unified diff against the last committed version, (3) loads the golden dataset of input/output pairs for that prompt, (4) calls the model with the prompt template, injecting [PROMPT_DIFF], [GOLDEN_TEST_CASES], and [CONSTRAINTS], and (5) parses the JSON output for status. If status is FAIL, extract the violations array, format a human-readable message pointing to the specific lines and rules broken, and exit with a non-zero code to block the commit. Use a fast, cost-effective model for this check—gpt-4o-mini or claude-3-haiku are appropriate for local validation speed.

Add a bypass mechanism for emergencies, but make it explicit. A --no-verify flag on git commit skips the hook, but that should be rare. Instead, support a PROMPT_VALIDATION_BYPASS environment variable or a .prompt-validation-ignore file that must contain a justification string and an expiry timestamp. Log every bypass to a local audit file so the team can review skipped checks later. For high-risk prompts (those gating production behavior, handling PII, or making financial decisions), configure the harness to refuse bypass entirely and require a full CI gate run before any commit is accepted.

Wire the harness to respect a local configuration file (e.g., .prompt-validation.yaml) that defines which rules apply to which prompt files, the path to golden datasets, model selection, timeout thresholds, and severity mappings. This keeps the hook generic and reusable across multiple prompt projects. A single pre-commit hook can iterate over all staged prompt files, match each to its configuration block, and run the appropriate validation. Cache model responses for unchanged prompt sections to reduce latency and API costs on repeated commits.

Finally, ensure the harness produces machine-readable output for CI systems to consume later. Even though this runs locally, the same JSON report should be attachable to a pull request or pipeline run. Store the last validation report in .prompt-validation/ so that git diff against the previous validation result is possible. This gives reviewers a clear before/after comparison of what the local check found versus what CI later confirms. Avoid building a harness that only works on one engineer's machine—use a scripted, version-controlled hook that the whole team can install with a single setup command.