Custom Anti-Pattern Rule Definition Prompt

This prompt is designed for platform and DevSecOps teams who need to convert natural language descriptions of forbidden code patterns into structured, machine-readable rule definitions. The primary job-to-be-done is bridging the gap between team conventions and automated enforcement. Use it when your team has coding standards that static analysis tools do not cover out of the box, such as internal library usage rules, naming conventions for specific contexts, or architectural layering violations. The ideal user is a senior engineer or architect who can precisely describe the anti-pattern, provide positive and negative examples, and define the severity of a violation. This prompt is not for generating generic linting rules that are already available in tools like ESLint or Pylint; it is for encoding tribal knowledge that currently lives in code review checklists and onboarding documents.

Before using this prompt, you must have a clear, unambiguous description of the forbidden pattern and at least two concrete code examples—one that should trigger the rule and one that should not. The prompt expects these as inputs to ground the model's generation in your specific context. The output is a JSON rule definition designed to be consumed by an automated code review harness, not a human auditor. This means the rule must include fields for a unique ID, a human-readable description, a severity level, and a query or pattern-matching expression that can be executed against an AST or source text. The harness is responsible for validating the generated rule against your provided examples before deployment, ensuring the rule fires on true positives and remains silent on true negatives.

Do not use this prompt for safety-critical or security enforcement without a human-in-the-loop review step. While the model can generate a syntactically correct rule, it may misinterpret nuanced intent or produce a rule that is too broad or too narrow. The generated rule is a candidate, not a final artifact. Your workflow must include a validation harness that tests the rule against a curated set of positive and negative examples and surfaces any mismatches for human review. This prompt belongs in a pipeline where a human expert describes the pattern, the model generates a candidate rule, and a validation harness gates the rule before it reaches production. If your team lacks the infrastructure to run these automated checks, start by building that harness before relying on this prompt.

This prompt template transforms a plain-English description of a forbidden coding pattern into a structured rule definition that an automated checker can execute. The template is designed for platform teams who need to encode team-specific conventions—such as 'never use raw SQL string concatenation' or 'avoid importing from deprecated internal packages'—into a format that can be validated, versioned, and deployed into CI pipelines. Replace every square-bracket placeholder with your specific context before running the prompt. The output is a JSON rule object that includes detection logic, severity, remediation guidance, and test cases.

textCopy
You are a codebase rule definition generator. Your job is to convert a natural language description of a forbidden coding pattern into a precise, machine-readable rule definition.

## INPUT

Rule Name: [RULE_NAME]

Natural Language Description: [RULE_DESCRIPTION]

Target Language(s): [LANGUAGE_LIST]

Severity Level: [SEVERITY]  // Must be one of: CRITICAL, HIGH, MEDIUM, LOW, INFO

Team Context: [TEAM_CONTEXT]  // Optional: coding standards, framework conventions, or architecture decisions that inform the rule

## OUTPUT SCHEMA

Return a single JSON object with these fields:

{
  "rule_id": "string, kebab-case unique identifier derived from rule name",
  "name": "string, human-readable rule name",
  "description": "string, one-paragraph explanation of what the rule detects and why it matters",
  "severity": "string, one of CRITICAL|HIGH|MEDIUM|LOW|INFO",
  "detection_patterns": [
    {
      "pattern_type": "string, one of: ast_pattern|regex|import_check|call_graph|naming_convention|structural",
      "pattern": "string, the specific detection expression",
      "match_context": "string, where to apply the pattern: file|function|class|module|import|call_site|assignment",
      "exclusion_conditions": ["string, conditions where this pattern should NOT flag"]
    }
  ],
  "false_positive_risks": ["string, scenarios likely to produce false positives"],
  "remediation": {
    "summary": "string, one-sentence fix guidance",
    "preferred_alternative": "string, what to use instead",
    "code_example_before": "string, minimal code snippet showing the violation",
    "code_example_after": "string, minimal code snippet showing the fix"
  },
  "positive_test_cases": [
    {
      "description": "string, what this test case verifies",
      "code_snippet": "string, code that SHOULD trigger the rule",
      "expected_result": true
    }
  ],
  "negative_test_cases": [
    {
      "description": "string, what this test case verifies",
      "code_snippet": "string, code that should NOT trigger the rule",
      "expected_result": false
    }
  ],
  "suppression_mechanism": "string, how developers can suppress this rule when intentional (e.g., comment annotation, config key)",
  "confidence": "string, one of: HIGH|MEDIUM|LOW indicating how reliably this pattern can be detected automatically"
}

## CONSTRAINTS

- Detection patterns must be specific enough to minimize false positives while catching real violations.
- Every rule must include at least two positive test cases and two negative test cases.
- Remediation examples must be syntactically valid for the target language.
- If a pattern cannot be detected with high confidence through static analysis alone, set confidence to LOW or MEDIUM and note what additional evidence (runtime profiling, human review) would be needed.
- Do not invent language features or APIs that don't exist in the target language.
- If the natural language description is ambiguous, ask clarifying questions instead of guessing.

## EXAMPLES

[EXAMPLES]  // Optional: insert 1-2 example rule definitions that demonstrate your team's expected format and rigor

## RISK LEVEL

[RISK_LEVEL]  // Set to HIGH if this rule will block merges or deployments; MEDIUM if it generates warnings; LOW if informational only

After pasting this template, replace each placeholder with concrete values. For [RULE_DESCRIPTION], write a precise, unambiguous description that includes both what the pattern looks like and why it is forbidden. For [EXAMPLES], provide one or two existing rule definitions that match your team's preferred format and level of detail—this anchors the model's output style. For [RISK_LEVEL], be explicit about whether this rule will block CI pipelines or merely generate warnings, as this affects how aggressively the model should tune detection patterns. Once the prompt returns a rule definition, validate it against your positive and negative test cases before deploying it to any automated checker. If the generated rule fails any test case, feed the failure back into the prompt as a correction request rather than manually editing the JSON.

The Custom Anti-Pattern Rule Definition Prompt converts natural language descriptions of forbidden patterns into machine-readable rule definitions. The primary integration surface is a rule authoring service that accepts human-readable descriptions and returns structured rule objects. The harness must treat the generated rule as untrusted code until it passes validation against a curated test suite of positive and negative examples. This prompt is not a one-shot generator; it is the first step in a validate-repair-approve loop that ensures rules are both syntactically correct and semantically aligned with team intent before they are deployed to automated checkers.

Wire the prompt into a rule ingestion pipeline with these stages: (1) Accept a natural language rule description and optional [CONTEXT] (e.g., language, framework, existing rule set). (2) Call the model with the prompt template, requesting a structured output schema that includes rule_id, pattern, severity, positive_examples, negative_examples, and fix_suggestion. (3) Validate the output against a JSON Schema definition—reject any response missing required fields or containing malformed regex/ AST patterns. (4) Run the generated rule against a golden test set of at least 5 positive examples (should flag) and 5 negative examples (should not flag). If precision or recall falls below a defined threshold (e.g., 0.9), route to a repair prompt that includes the failing cases and asks the model to refine the pattern. (5) After passing automated validation, stage the rule for human review in a diff-view UI that shows the rule definition, test results, and affected code samples. Only after explicit approval should the rule be merged into the active rule set used by CI checks or IDE plugins.

For model choice, prefer a model with strong code reasoning and structured output support (e.g., GPT-4o, Claude 3.5 Sonnet). Set temperature=0 to maximize deterministic rule generation. Implement retry logic with exponential backoff for schema validation failures, but cap repair attempts at 3 iterations before escalating to a human author. Log every generation attempt, validation result, and repair iteration for auditability. Critical failure modes to monitor: rules that are too broad (flagging idiomatic code that follows team conventions), rules that are too narrow (missing obvious violations due to overly specific patterns), and rules that contain regex catastrophic backtracking risks. The harness should include a performance sandbox that tests generated regex patterns against large inputs and rejects any that exceed a timeout threshold. Do not deploy rules directly from model output without this multi-stage validation—the cost of a false positive in an automated checker that blocks CI pipelines is far higher than the cost of a slower, gated approval process.