Naming Convention and Case Format Audit Prompt

This prompt is for engineering teams who need to enforce consistent key naming conventions—such as camelCase, snake_case, PascalCase, or kebab-case—across structured LLM outputs before those outputs reach downstream parsers, databases, or public APIs. The primary job-to-be-done is automated convention auditing: given a JSON object and a target case format, the prompt produces a field-by-field violation report with suggested corrections. The ideal user is a backend engineer, platform developer, or AI reliability lead integrating an LLM into a product where API contracts, database column mappings, or SDK type definitions depend on predictable key shapes. You should use this prompt when your system generates structured data and you cannot rely on the model alone to remember or consistently apply a naming standard across all fields, especially in long or nested outputs.

This prompt is not a schema validator, a type checker, or a completeness auditor. It does not verify that the right fields exist, that values are the correct type, or that business logic constraints are satisfied. It only audits the surface form of the keys themselves. Do not use this prompt when you need full JSON Schema compliance checking, cross-field dependency validation, or semantic correctness grading—pair it with sibling prompts like the JSON Schema Compliance Judge or Field Presence Audit for those concerns. The prompt is also not a repair tool; it identifies violations and suggests corrections but does not rewrite the payload. You will need a separate repair step or human review to apply the suggested fixes, especially when a correction could collide with another key name or a reserved word in your target system.

Before using this prompt, you must define your target convention explicitly. Ambiguous instructions like 'use standard JavaScript naming' will produce inconsistent results. Instead, specify the exact case format with clear rules: for camelCase, state that the first word is lowercase and subsequent words start uppercase with no separators; for snake_case, state that words are lowercase and separated by underscores. Provide examples of correct and incorrect keys in the [EXAMPLES] placeholder to anchor the model's behavior. The prompt works best when the input object is already valid JSON and the keys are strings. If your LLM output is still in a code block, contains trailing commas, or uses single quotes, run a syntax validation step first. Finally, recognize that this prompt is a narrow, deterministic audit tool—it should be one step in a multi-stage validation pipeline, not a standalone quality gate for production data.

This section provides a copy-ready prompt template that you can drop into your evaluation harness to audit a JSON payload for naming convention and case format violations. The template is designed to be model-agnostic and uses square-bracket placeholders for all dynamic inputs, making it easy to parameterize in code. The prompt instructs the model to act as a strict convention auditor, checking every key against a specified case format and producing a structured violation report.

textCopy
You are a strict naming convention auditor. Your task is to inspect the provided JSON payload and identify every key that violates the required naming convention.

[CONSTRAINTS]
- Only flag keys that do not match the [REQUIRED_CASE_FORMAT] convention.
- Ignore values; only audit the key names.
- Check all keys, including those in nested objects and arrays of objects.
- If a key is a reserved word in common programming languages (e.g., 'class', 'import', 'default'), flag it as a separate violation type.
- If the payload contains a mix of conventions (e.g., some camelCase and some snake_case keys), note this as an inconsistency violation.

[INPUT]
```json
[INPUT_JSON_PAYLOAD]

[OUTPUT_SCHEMA] You must respond with a single JSON object conforming to this schema: { "convention_audit": { "required_convention": "[REQUIRED_CASE_FORMAT]", "total_keys_checked": <integer>, "violations": [ { "key_path": "<string, e.g., 'user.address.streetName'>", "current_name": "<string>", "violation_type": "<'case_mismatch' | 'reserved_word' | 'inconsistent_convention'>", "suggested_correction": "<string or null>" } ], "summary": "<string>" } }

[EXAMPLES] Input: {"userId": 1, "user_name": "Alice"} Required Case: camelCase Output: { "convention_audit": { "required_convention": "camelCase", "total_keys_checked": 2, "violations": [ { "key_path": "user_name", "current_name": "user_name", "violation_type": "case_mismatch", "suggested_correction": "userName" } ], "summary": "1 violation found: 'user_name' should be 'userName'. Payload has inconsistent conventions (camelCase and snake_case)." } }

[RISK_LEVEL] This is a deterministic format check. If the output does not match the [OUTPUT_SCHEMA], the evaluation harness should retry once. If the retry fails, log the raw output and escalate for manual review.

To adapt this template, replace the placeholders in your application code before sending the request to the model. The [INPUT_JSON_PAYLOAD] should be the stringified JSON you want to audit. The [REQUIRED_CASE_FORMAT] should be a clear string like camelCase, snake_case, PascalCase, or kebab-case. The [OUTPUT_SCHEMA] is provided inline as a strict JSON Schema, which you can also enforce using your model's structured output or JSON mode features. The [EXAMPLES] section provides a one-shot demonstration of the desired behavior, which is critical for getting consistent violation types and suggested corrections. For production use, consider expanding the examples to include nested objects and reserved word collisions.

After integrating this prompt, your next step is to build a thin validation wrapper in your application that parses the model's response, confirms it matches the output schema, and routes violations to your logging or alerting system. Avoid the temptation to make the prompt do more than audit naming conventions; combining it with type checking or business logic validation will degrade its reliability. For high-risk pipelines where a missed violation could break downstream parsers, always pair this prompt with a deterministic post-check in code that verifies the model's violation count against a simple regex scan of the original keys.

The Naming Convention and Case Format Audit Prompt is designed to be called as a post-processing step after your primary LLM generates a structured output. It should not be the final gatekeeper on its own—treat it as a high-signal automated reviewer that flags violations for either automatic repair or human review. The prompt expects a JSON payload and a target convention (e.g., camelCase, snake_case, PascalCase), and it returns a structured violation report. Wire this into your application as a dedicated validation service that sits between the primary model response and your downstream parsers or databases.

For an API integration, wrap the prompt in a function that accepts the raw LLM output and a convention parameter. The function should: (1) attempt to parse the input as JSON and immediately return a parse error if it fails—do not send unparseable strings to the auditor; (2) call the LLM with the audit prompt, using a low temperature (0.0–0.1) and a model that reliably follows JSON output instructions; (3) validate the auditor's response against a strict schema that expects violations as an array of objects with field_path, current_case, expected_case, and suggested_fix; (4) if the auditor's output fails schema validation, retry once with an explicit error message appended to the prompt; (5) log the full audit result, including the original payload hash, convention, violation count, and auditor model version, to your observability platform. For high-throughput systems, batch multiple outputs into a single audit call by wrapping them in a records array and asking the auditor to return a per-record violation list.

In a CI/CD pipeline, integrate this prompt as a gate in your prompt regression test suite. Maintain a golden dataset of known-correct and known-violating payloads. For each test case, assert that the auditor correctly identifies zero violations for compliant payloads and catches every seeded violation in non-compliant ones. Track false-positive and false-negative rates over time, and set a threshold—if the auditor misses more than 5% of known violations, block the prompt change and investigate. For production use, pair this audit prompt with an automated repair step: when violations are detected, feed the violation report and original payload into a repair prompt that applies the suggested fixes and returns a corrected output. Always log the pre-repair and post-repair payloads for auditability. Avoid using this prompt on outputs that contain mixed conventions by design (e.g., keys from external APIs that follow different standards); instead, scope the audit to the fields your team controls and document which fields are exempt.