Extract and Validate Python Code Blocks Prompt Template

This prompt is designed for Python-specific tooling that needs to extract fenced code blocks from AI model responses and validate them before writing to disk. Use it when you are building coding agents, documentation generators, or IDE integrations that must guarantee Python code is syntactically valid, imports are available, and style is compliant before file insertion. The core job-to-be-done is transforming a raw, untrusted model response containing one or more Python code blocks into a set of validated, linted, and file-ready code segments that won't break downstream tooling.

The ideal user is a developer or platform engineer wiring an LLM into a code generation pipeline where output correctness is non-negotiable. You should have access to a Python runtime for AST parsing and import resolution, and you should be prepared to run flake8, pylint, or your team's linter as a post-extraction gate. This prompt assumes the input is a complete model response—not a streaming chunk—and that the response uses standard markdown fenced code blocks with a python language tag. It is not suitable for extracting non-Python code, handling streaming responses where fences may be incomplete, or recovering from severely malformed markdown where the model has lost track of backtick pairing.

Do not use this prompt when you need to extract shell commands, configuration files, or multi-language projects from a single response. For those cases, use the Multi-Language Code Block Extraction or Shell Command Extraction playbooks instead. Also avoid this prompt if your pipeline cannot tolerate AST parse failures—if the model generates pseudocode or incomplete snippets, the validator will reject them, and you'll need a fallback repair loop. For high-risk production systems, always pair this extraction step with human review gates when the code will be executed automatically, and log every extraction failure for prompt debugging and model performance tracking.

This prompt template is designed to be placed in your system instructions or sent as a user message when you need to extract Python code blocks from a model's response and validate them before writing to disk. It handles the full pipeline: identifying fenced Python blocks, running AST parse checks, resolving import availability, applying style linting, and returning a structured report with fix suggestions. Replace the square-bracket placeholders with your specific constraints, style configuration, and allowed import whitelist.

textCopy
You are a Python code extraction and validation engine. Your job is to extract all Python code blocks from the provided [INPUT] and validate each one before it can be written to a file.

## Extraction Rules
1. Identify all fenced code blocks with language tag `python`, `py`, `python3`, or untagged blocks that contain unambiguous Python syntax.
2. Ignore inline code spans, pseudocode, and interactive shell sessions (lines starting with `>>>` or `...`).
3. For each extracted block, record the block index, language tag, and raw content.

## Validation Pipeline
For each extracted block, run the following checks in order. Stop at the first failure and report it.

### 1. Syntax Validation
- Parse the code with Python's `ast.parse()` at the target version [TARGET_PYTHON_VERSION].
- If parsing fails, report the error line, column, and message. Do not proceed to further checks.

### 2. Import Availability Check
- Extract all top-level import statements (`import X` and `from X import Y`).
- Compare each imported module against the allowed import whitelist: [ALLOWED_IMPORTS].
- If an import is not in the whitelist, flag it as UNAVAILABLE and suggest alternatives from the whitelist if possible.
- If the whitelist is empty, skip this check and mark imports as UNVERIFIED.

### 3. Style Compliance
- Run the code through the style checker specified in [STYLE_CONFIG].
- Report violations by line number, rule code, and message.
- Classify violations as ERROR (must fix) or WARNING (should fix) based on [STYLE_SEVERITY_THRESHOLD].

## Output Schema
Return a JSON object with this exact structure:
{
  "blocks": [
    {
      "index": 0,
      "language_tag": "python",
      "content": "<raw code>",
      "validation": {
        "syntax": {
          "valid": true,
          "error": null
        },
        "imports": {
          "detected": ["os", "json"],
          "unavailable": [],
          "suggestions": {}
        },
        "style": {
          "violations": [
            {
              "line": 3,
              "rule": "E501",
              "message": "Line too long (89 > 79 characters)",
              "severity": "ERROR"
            }
          ],
          "error_count": 1,
          "warning_count": 0
        },
        "overall_pass": false
      },
      "fix_suggestions": [
        "Line 3: Break long string into multiple lines or use parentheses for implicit continuation"
      ]
    }
  ],
  "summary": {
    "total_blocks": 1,
    "passed": 0,
    "failed": 1,
    "failure_reasons": ["Block 0: 1 style error"]
  }
}

## Constraints
- Do not modify the code content. Report violations and suggest fixes, but never rewrite the code.
- If no Python blocks are found, return an empty `blocks` array with `summary.total_blocks: 0`.
- If [RISK_LEVEL] is "high", flag any use of `eval()`, `exec()`, `__import__()`, or `subprocess` as a CRITICAL finding and set `overall_pass` to false regardless of other checks.
- If [REQUIRE_HUMAN_REVIEW] is true, add a `human_review_required` boolean to each block's validation object and set it to true if any check fails.

To adapt this template, replace the placeholders with your project-specific values. [TARGET_PYTHON_VERSION] should be a string like "3.11". [ALLOWED_IMPORTS] should be a JSON array of module names, or an empty array [] to skip import checking. [STYLE_CONFIG] should specify the linter and ruleset, such as "flake8 with max-line-length=88" or "ruff with pyproject.toml defaults". [STYLE_SEVERITY_THRESHOLD] controls which violations block the overall_pass flag—set it to "ERROR" to only block on errors, or "WARNING" to block on warnings too. [RISK_LEVEL] accepts "low", "medium", or "high" and gates the dangerous-call detection. [REQUIRE_HUMAN_REVIEW] is a boolean that adds a review gate to the output schema. Always test this prompt against known-good and known-bad Python blocks before deploying it in a file-writing pipeline.

This prompt template is designed to be called as a post-processing step after a primary model response that contains Python code blocks. The typical integration pattern is a two-stage pipeline: the first stage generates or retrieves a response containing code, and the second stage passes that response through this extraction and validation prompt. The harness should treat the extraction prompt as a structured output call—request JSON mode or a tool-call response with a defined schema containing blocks, validation_results, and lint_results arrays. This ensures the output is machine-readable without additional parsing.

The implementation must include pre-validation of the input before calling the prompt. Check that the source response is a non-empty string and that it contains at least one fenced code block marker (```). If no code blocks are detected, skip the extraction call and log a NO_CODE_BLOCKS event. After receiving the structured output, run AST parse validation on each extracted block using Python's ast.parse() in a subprocess or sandboxed environment. This catches syntax errors the model may have missed. For import validation, maintain an allowlist of permitted standard library and project-specific modules; any import outside this list should flag the block for human review. The harness should also execute a configured linter (such as ruff or flake8) on each block and compare the model's reported lint results against the actual linter output to detect hallucinated diagnostics.

Retry logic should be conservative. If the extraction prompt returns malformed JSON or fails schema validation, retry once with a simplified instruction that asks only for the code block array without validation commentary. If AST parsing fails on a block, do not retry the extraction prompt—instead, pass the block to a separate repair prompt or surface it in a review queue. For file insertion workflows, always write extracted blocks to a temporary staging directory first, run all validations, and only move to the target path after all checks pass. Never write directly to the target file system from model output. Log every extraction attempt with the source response hash, extracted block count, validation pass/fail status, and any human-review flags. This audit trail is essential for debugging extraction failures in production and for demonstrating due diligence in regulated environments.