Outline-Then-Detail Pattern — The "Blueprint Before Wallpaper" of Prompting

"If you build the scaffolding first, the house doesn't collapse when you start arguing about fonts." — Your future prompt engineer

Opening (quick hook — short and spicy)

You already know how to specify output schemas, design post-processing-friendly outputs, and assemble multi-part outputs like a responsible architect of information. Now let’s stop handing models raw clay and start giving them a blueprint. The Outline-Then-Detail pattern is exactly that: first force the model to sketch the skeleton, then ask it to fill in the muscles and personality — in controlled, parseable ways.

Why care? Because this pattern dramatically improves consistency, traceability, and modular re-use when you're building pipelines that will be parsed, scored, or stitched back together (remember the Multi-Part Output Assembly trick?). It’s the secret sauce for complex tasks where you want both structure and nuance.

What is the Outline-Then-Detail Pattern?

Outline-Then-Detail is a two-phase prompting strategy:

1. Outline phase: Ask the model to produce a high-level plan, sections, or steps (a predictable scaffold). This output should be short, numbered, and strictly formatted.
2. Detail phase: For each outline item, ask the model to expand into controlled, richly formatted content — one item at a time or batched — so downstream systems can parse or score each piece independently.

Think of it as drawing a table of contents before writing a book.

Why it works (AKA the engineering truth behind the magic)

• Reduces hallucination scope: Smaller, constrained tasks mean fewer wild inventions per chunk.
• Improves modularity: You can replace/repair one section without regenerating the whole thing.
• Enables targeted evaluation: Score each outline-derived segment separately (useful for rubrics & automated testing).
• Better for post-processing: You get consistent keys/section headers for parsing JSON, markdown, or CSV.

When to use it (and when not to)

Use it when:

• The task is multi-step or multi-section (reports, lesson plans, debugging flows).
• You need structured output for downstream parsing or scoring.
• You expect iterative refinement or human-in-the-loop edits.

Avoid or simplify when:

• You need very short outputs (single-sentence answers).
• The model must be extremely creative with no constraints (pure brainstorming — though you can still outline themes first).

A step-by-step recipe (copy-paste friendly)

1. Prompt: Generate a numbered outline with exactly N items. Enforce formatting (e.g., "1.", "2.").
2. Validate: Check the outline for scope and correctness. Optionally let a human or validator edit.
3. For each outline item, prompt: "Expand item #k into X subsections, each labeled and in JSON/markdown format." Limit length.
4. Assemble: Combine expanded sections using previously defined assembly rules (see Multi-Part Output Assembly).
5. Post-process: Parse with your extractor and run automated checks (schema validation, scoring, etc.).

Example — From skeleton to fully-structured product

Imagine you need a 4-section executive summary with a short action plan. Here's a simplified prompting workflow.

Code (prompt pseudocode):

PROMPT A (Outline):
"Produce a 4-item numbered outline for an executive summary on 'Reducing Customer Churn'. Use exactly these labels: 1. Problem, 2. Root Causes, 3. Proposed Solution, 4. Action Plan. No extra text."

PROMPT B (Detail for item k):
"Expand item #3 (Proposed Solution) into this JSON object: {\"title\": string, \"description\": string (max 120 words), \"impact_estimate\": string (qualitative), \"dependencies\": [string] }"

Why this is neat:

• PROMPT A produces a predictable scaffold you can validate.
• PROMPT B enforces a schema for downstream parsing.
• You can generate each JSON object separately and assemble — perfect for parallelization.

Table: Outline-Then-Detail vs. Other Patterns

Practical tips & guardrails (aka battle-tested heuristics)

• Force explicit numbering/keys. Don’t let the model invent headings. Use exact labels.
• Keep outlines short. 3–8 items is sweet spot for human readability and model focus.
• Validate the outline automatically. Check count, labels, and length before expanding.
• Expand one item per call (if latency acceptable). This reduces token noise and makes debugging trivial.
• Use a fixed schema for details. JSON or markdown sections with known keys = heaven for parsers.

Pro tip: If you previously used Tables and Matrices for comparing options, use the Outline phase to decide which table to fill, then detail each cell in the Detail phase.

A tiny checklist before you deploy

• Does the outline contain exactly the labels/number of items you expect?
• Is each detail expansion using the schema your downstream expects?
• Can you re-run or replace a single section without re-generating everything?
• Have you set max token lengths and guardrails to prevent runaway verbosity?

Closing — TL;DR plus a motivational last jab

Outline-Then-Detail is the prompt-engineering equivalent of "plan before you binge-write." It makes outputs predictable, parseable, and repairable, which is exactly what you need when engineering systems that must integrate with scoring, human review, or automated pipelines. Mix it with your previous tools — output schemas, post-processing-friendly formats, and multi-part assembly — and you get a production-ready prompt architecture.

Want predictable quality? Build the frame first. Want chaos and glitter? Skip the outline and hope for the best.

Version: "Outline-Then-Detail — Blueprint Before Wallpaper"