A Lint and Format Policy Prompt That Tames AI-Generated Code

AI writes a lot of the code now, and it writes it in whatever style its training data favored. Snake_case sneaks into a camelCase project. A bare print() lands where your logger should be. Import order scrambles. CodeRabbit's own measurements put formatting problems at 2.66x more frequent and readability issues 3x worse in AI-generated code than in human-written code. The agent never read your style guide. It couldn't.

A lint and format policy prompt closes that loop two ways: it turns your loose style preferences into a written, enforceable policy, then checks code against that policy and reports violations by file and line. Not as a replacement for ESLint or Prettier, those run in CI and catch the mechanical stuff in milliseconds, but as the semantic layer above them.

Here's the prompt, the policy contract, and why the deterministic-only approach others recommend leaves a gap.

Why deterministic linting alone isn't enough for AI code

The smart writing on this argues for catching AI's predictable mistakes with deterministic rules. The widely shared Lint Against the Machine field guide lays out ten anti-pattern categories (duplication, bare excepts, any types, debugging residue, deprecated APIs) and the linter rule codes that catch them. It's right that "systematic problems yield to systematic prevention." But it explicitly stops at deterministic rules, and it's a concept guide, not a prompt.

That leaves two things uncovered. First, writing the policy: most teams have style opinions but no document, so there's nothing for a linter or a reviewer to enforce. Second, the semantic layer: a variable named data2, a function that follows the letter of the style guide but not its intent, a pattern that doesn't match the rest of the codebase. No regex catches "this name is bad." A prompt can.

Use cases like style guide enforcement workflows describe the goal but not a copyable method. This post is the method.

What you can do with this prompt

• Turn scattered style preferences into a single written policy document.
• Generate a starter linter config that encodes the deterministic half of the policy.
• Check a diff or file against the policy and get violations by line, with fixes.
• Catch semantic style issues linters miss: weak names, inconsistent patterns, logger misuse.
• Hand AI agents the policy as context so they generate compliant code in the first place.
• Onboard a new contributor with the policy instead of a tribal-knowledge code review.

Anatomy of the prompt

Two modes share one contract. Mode one writes the policy. Mode two enforces it. The output contract keeps both consistent.

Role:    You are a code style reviewer enforcing {{style_policy}}.
Context: {{style_policy}} — the team's written rules (or examples to infer from).
         {{code}} — the file or diff under review.
Task:    Check the code against the policy. For each violation, name the rule,
         the line, the severity (blocking vs advisory), and the corrected code.
         Skip anything a formatter (Prettier/Black) auto-fixes — call those out
         once, collectively, not line by line.
Output:  A table — File:Line | Rule | Severity | Current | Corrected.
         End with the policy gaps the code revealed (rules worth adding).

Step-by-step usage

1. Gather inputs

For policy authoring, collect 3 to 5 files you'd hold up as the standard. For enforcement, grab the diff or file under review plus the policy you've already written.

2. Fill variables

Set {{style_policy}} and {{code}}. In authoring mode, leave the policy as "infer from these examples." In enforcement mode, paste the real policy.

3. Run the prompt

In enforcement mode, read the blocking violations first. Advisory ones (a slightly awkward name) are suggestions; blocking ones (wrong casing convention, banned pattern) gate the merge.

4. Post-process

Apply the corrections. For the "policy gaps" section, decide which suggested rules to adopt; that section is how the policy grows from real code over time.

5. Iterate

Feed the written policy back to your AI coding agent as a system instruction so it generates compliant code, shifting enforcement left from review to authoring.

Prompt-craft patterns

Separate blocking from advisory. A policy where everything is mandatory gets ignored because nobody can ship. Mark the casing and banned-pattern rules blocking; mark naming-quality suggestions advisory. The contract should carry the distinction.

Severity:
  blocking  = casing convention, banned API, security pattern
  advisory  = name could be clearer, comment would help, minor structure

Don't re-report what the formatter fixes. Prettier and Black handle whitespace and quotes deterministically. Tell the prompt to mention those once, collectively, and spend its attention on the semantic layer. Otherwise you drown real issues in indentation nags.

Give the policy to the agent, not just the reviewer. The highest-leverage use is prevention: paste the policy into your coding agent's context so it writes compliant code, the way you'd hand a well-written rules file to Cursor. Enforcement at review time is cleanup; enforcement at authoring time is the fix.

The opinionated take: stop reviewing formatting in pull requests entirely. If a human is leaving comments about quote style or import order, your tooling has failed, not your teammate. Push every deterministic rule into Prettier, Black, or ESLint on a pre-commit hook, and reserve human and LLM attention for the semantic layer this prompt targets, naming, patterns, and intent. Formatting debates in review are a tax on everyone's time and they never change anyone's mind.

Variables you'll set

Getting started

1. Pick 3 to 5 files that represent your standard.
2. Run the prompt in authoring mode to extract the policy.
3. Mark each rule blocking or advisory.
4. Push deterministic rules into your formatter and linter config.
5. Run enforcement mode on diffs for the semantic layer.
6. Feed the policy to your AI agent so it generates compliant code.
7. To make this a standing review gate, the Code Review Policy System Prompt includes maintainability and consistency as mandatory dimensions.

A style policy is most powerful when it shapes code before review. Two reads on shifting it left: writing a .cursorrules file that actually works and writing an AGENTS.md file with AI, both of which hand your agent the conventions up front. For the semantic smells that slip past style rules, the Legacy Code Comprehension Harness reads what the code really does so your policy targets behavior, not just surface.