Inline Code vs Fenced Block Disambiguation Prompt Template

This prompt is designed for documentation generators, markdown parsers, and coding agents that must reliably separate inline code spans from fenced code blocks in AI-generated or user-provided markdown. The core job is classification: every backtick-delimited segment in the input must be identified as either an inline element (destined for prose rendering) or a fenced block (destined for file operations, execution, or structured extraction). The ideal user is a developer building a pipeline that consumes markdown and needs to route code to different downstream systems—syntax highlighters, file writers, or notebook converters—without corrupting the document structure.

Use this prompt when your application processes mixed-content markdown where both inline code references and full fenced blocks coexist, and misclassification would break rendering or cause executable code to leak into prose. It is particularly valuable when the input source is an LLM that may inconsistently format code, use non-standard fence lengths, or embed backtick-heavy prose like regex patterns or shell examples. Do not use this prompt when you only need to extract all code indiscriminately, when the input is guaranteed to contain only fenced blocks, or when you are operating in a streaming context where fence state must be tracked incrementally—use the Streaming Code Block Extraction Prompt Template for that scenario. This prompt assumes you have the complete markdown text available for holistic analysis.

Before integrating this prompt, ensure your pipeline can handle the output schema: a list of classified elements, each with a type (inline or fenced), the raw content, and metadata like language tags and fence lengths. The prompt includes boundary-case handling for single-line fences, backtick-heavy prose, and nested backtick patterns. After classification, route fenced blocks to your code extraction or file-writing harness and inline spans to your markdown renderer. If your use case involves regulated documentation, medical records, or legal filings, add a human review step before any code block is written to disk or executed. Start by running the provided eval cases against your model to confirm classification accuracy before wiring this into a production pipeline.

This prompt template forces the model to classify every code-like element in a markdown response as either an inline code span or a fenced code block, then extract only the fenced blocks into a structured array. Use it when your documentation generator, coding agent, or markdown parser must reliably separate prose-level code references from file-worthy code segments. The template includes explicit boundary-case handling for single-line fences, backtick-heavy prose, and nested code references that commonly cause misclassification.

textCopy
You are a precise markdown parser that distinguishes inline code spans from fenced code blocks. Your task is to analyze the provided markdown content and classify every code-like element, then extract only the fenced code blocks into a structured output.

## INPUT
Analyze the following markdown content:

```markdown
[INPUT_MARKDOWN]

CLASSIFICATION RULES

1. Inline code spans: Single backtick-wrapped text (like this) or double-backtick-wrapped text when the content contains single backticks. These appear within paragraph text and are not standalone blocks. Do NOT extract these.
2. Fenced code blocks: Text wrapped in triple backticks (```) or triple tildes (~~~) that appear on their own lines, optionally preceded by a language tag. These are standalone content blocks. Extract these.
3. Boundary cases:
   • Single-line fenced blocks (code) are still fenced blocks if the opening and closing fences are on the same line or adjacent lines with no paragraph text between them.
   • Prose containing multiple backticks for discussion purposes (e.g., "use ``` to open a fence") is NOT a fenced block unless the backticks appear on dedicated lines.
   • Nested backtick patterns inside fenced blocks (showing markdown examples) are part of the fenced block content, not separate blocks.

OUTPUT SCHEMA

Return a JSON object with this exact structure: { "inline_code_spans": [ { "content": "the code text without backticks", "position": {"line_start": 0, "line_end": 0, "char_start": 0, "char_end": 0}, "surrounding_text": "brief context from surrounding prose" } ], "fenced_blocks": [ { "language": "detected language tag or null", "content": "the code content without fences", "fence_type": "backtick or tilde", "position": {"line_start": 0, "line_end": 0}, "is_complete": true } ], "classification_notes": ["any ambiguous cases and how they were resolved"] }

CONSTRAINTS

• Never extract inline code spans into the fenced_blocks array.
• Always include position information for traceability.
• Flag any ambiguous elements in classification_notes.
• If a fenced block appears incomplete (missing closing fence), set is_complete to false and include what was found.
• Preserve exact whitespace and indentation within fenced block content.
• Do not modify or escape the content of extracted blocks.

EXAMPLES

Example 1: Mixed inline and fenced code Input: Use the print() function like this:

pythonCopy
print("hello")

Expected classification:

• inline_code_spans: [{"content": "print()", ...}]
• fenced_blocks: [{"language": "python", "content": "print("hello")", ...}]

Example 2: Single-line fence Input:

bashCopy
ls -la

Expected classification:

• inline_code_spans: []
• fenced_blocks: [{"language": "bash", "content": "ls -la", ...}]

Example 3: Backtick-heavy prose Input: To create a fenced block, type on a new line, then your code, then again.

Expected classification:

• inline_code_spans: []
• fenced_blocks: []
• classification_notes: ["Triple backticks appear in prose context, not on dedicated lines"]

OUTPUT

Return only the JSON object. No markdown fences, no commentary.

Adapt this template by replacing [INPUT_MARKDOWN] with your actual markdown content. For production pipelines, consider adding [OUTPUT_SCHEMA] variations if you need additional metadata like file paths, insertion markers, or execution environment specs. The classification rules section is the most critical to customize—adjust boundary case handling based on the specific failure patterns you observe in your model's outputs. If you're processing streaming responses, pair this with a state machine that tracks fence open/close state across chunks rather than relying on the prompt alone.

Before deploying, test this prompt against a golden dataset containing at least 20 examples that include: single-line fences, backtick-heavy prose, nested code blocks, missing closing fences, tilde-based fences, and inline code containing backticks. Run eval checks for precision (did we extract only real fenced blocks?) and recall (did we miss any fenced blocks?). Common failure modes include misclassifying single-line fences as inline code and treating prose discussions about markdown syntax as fenced blocks. If your model consistently fails on boundary cases, add more explicit examples to the prompt rather than lengthening the rules section.

This prompt is designed to sit between a raw model response and a downstream system that needs to separate inline code from fenced code blocks. The typical integration point is a post-processing step in a documentation generator, a coding agent's response handler, or a markdown-to-notebook converter. The prompt expects a single [INPUT] containing the full markdown text and returns a structured JSON object with two arrays: fenced_blocks for file operations and inline_spans for prose rendering. Do not use this prompt for streaming responses where fence state is incomplete; use the Streaming Code Block Extraction prompt instead.

Wire the prompt into your application with a validation layer before any file write or database insert. Parse the JSON output and run these checks: (1) every fenced_block must have a non-empty content and a language tag that matches your allowed language list; (2) no inline_span should contain triple-backtick sequences, which would indicate a misclassification; (3) the sum of extracted elements should not exceed the original input's code-like token count by more than 10%, a signal of duplication. If validation fails, retry once with the same prompt but append the validation errors as a [CONSTRAINTS] field: "Previous extraction failed validation: [list specific errors]. Re-extract and correct these issues." After two failures, log the raw response and route to a human review queue rather than silently writing broken output.

For model choice, prefer models with strong JSON mode and instruction-following benchmarks (GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro). Set response_format to json_object and supply the output schema in the API call's structured output parameter, not just in the prompt text. This dual enforcement reduces fence misclassification by catching malformed JSON before it reaches your application. For tool-use integrations, expose the output schema as a tool parameter so the model can self-validate before responding. Log every extraction with the input hash, model version, validation pass/fail, and retry count for observability. The most common production failure mode is single-line fenced blocks (e.g., `code`) being classified as inline code—add an eval case for this boundary in your regression test suite before shipping.