Prompt Patterns

Rabbithole Documentation — Reusable prompt structures for consistent site generation

In Rabbithole, every page is generated in complete isolation. The only information a page-generator receives is the prompt string stored in the URL mapping. There is no shared state, no theme context, no memory of previously generated pages. This means everything must live in the prompt.

This page catalogs eight reusable prompt patterns that solve common problems in Rabbithole site authorship. Each pattern is a named, copyable block you can paste into your seed prompt or sub-page prompts. Mix and match patterns as needed — most real prompts use three or more simultaneously.

Contents

1. The Style Block Pattern

PATTERN: STYLE_BLOCK

Because each page is generated independently, visual consistency requires you to re-specify your design system in every prompt. The Style Block is a compact, copy-paste specification of your site's visual language: colors, fonts, spacing rules, element styles, and layout constraints.

Without a Style Block, each page generator makes its own aesthetic decisions. With one, all pages converge on a shared design system even though none of them were generated together.

Template

DESIGN: [one-sentence aesthetic summary].
Colors: background [hex], text [hex], links [hex], visited [hex].
Font: [font stack], body size [px].
Layout: max-width [px] centered, [padding spec].
Headings: h1 [px], h2 [px] with [border spec] bottom border.
Code/pre: background [hex], border [spec], font [font], [px].
No external CSS. No JavaScript. No gradients. No box shadows.
All styles in <style> tags.

Example (this site)

DESIGN: Plain minimal technical documentation, like gcc.gnu.org.
Colors: background #ffffff, text #000000, links #0000cc, visited #551a8b.
Font: Arial, Helvetica, sans-serif, body 14px.
Layout: max-width 860px centered, padding 10px 20px.
Headings: h1 20px, h2 16px with 1px solid #cccccc bottom border.
Code/pre: background #f4f4f4, border 1px solid #ccc, Courier New 13px.
No external CSS. No JavaScript. No gradients. No box shadows.
All styles in <style> tags.
Tip: Keep your Style Block under ~80 words. Longer style specs can crowd out content instructions. Use the Reference Site Pattern (below) to supplement with an aesthetic anchor.
PATTERN: NAV_BLOCK

Navigation bars are the connective tissue of a site. Since each page is generated with no knowledge of any other, the full nav structure must be embedded in every prompt. The Nav Block is a literal list of links — labels and paths — that the generator should render as a persistent navigation element.

Without this, generated pages invent their own nav, or omit it entirely. With this, every page displays the same nav regardless of when or in what order it was generated.

Template

NAV (pipe-separated, [font size]px, placed at top of page):
  [Label] ([/path.html]) | [Label] ([/path.html]) | ...

Example (this site)

NAV (pipe-separated, 13px, placed at top of every page under a thin
  border-bottom line):
  Home (/) | Getting Started (/getting-started.html) |
  Architecture (/architecture.html) | Configuration (/configuration.html) |
  Web Tools (/web-tools.html) | Deployment (/deployment.html) |
  Examples (/examples.html) | About (/about.html)
Tip: Always include the target page's own URL in the nav listing so the generator can decide whether to render it as non-linked "current page" text. See also the Self-Referential Pattern.

3. The Lore Block Pattern

PATTERN: LORE_BLOCK

For fictional, worldbuilding, or branded sites, the Lore Block carries forward the "facts" of your universe. Since a page generating /characters/zareth.html has no knowledge of the homepage, the lore of the world, or even the name of the site, you must re-inject all of that context into every sub-page prompt.

The Lore Block typically includes: the name and premise of the site/universe, key entities (characters, organizations, places), recurring terminology, and any established canon that sub-pages should treat as fact.

Template

UNIVERSE CONTEXT:
  Site name: [name]
  Premise: [1-2 sentence summary of the world or subject]
  Key entities:
    - [Entity 1]: [brief canonical description]
    - [Entity 2]: [brief canonical description]
  Established facts:
    - [Fact A]
    - [Fact B]
  Tone: [e.g. dry academic, pulpy sci-fi, corporate satire]

Example (a sci-fi wiki)

UNIVERSE CONTEXT:
  Site name: The Meridian Codex
  Premise: An in-universe encyclopedia for the Meridian Expanse, a
    interstellar civilization 3,000 years in the future.
  Key entities:
    - The Compact: The ruling council of 12 species, based on Helix Station.
    - Zareth Vaal: A Nullspace navigator, disgraced, last seen near the Rift.
    - Nullspace: Faster-than-light travel medium; unstable beyond Tier 4.
  Established facts:
    - The Fracture War ended in 2714 CE. The Compact was founded afterward.
    - All dates use CE (Compact Era) notation.
  Tone: Dry academic encyclopedia, no editorializing.
Tip: Paste the full Lore Block into every sub-page prompt. If it grows too large, extract only the facts relevant to that specific page, plus the universal top-level facts.

4. The Content Enum Pattern

PATTERN: CONTENT_ENUM

Left to its own devices, a page generator will invent the structure of a page — which sections to include, what headings to use, what information to cover. Sometimes that's fine. For precise pages, you want to enumerate exactly what content should appear and in what order.

The Content Enum Pattern provides a numbered or bulleted list of sections, each with a brief description of what to include. The generator treats this as a content spec to fill in.

Template

CONTENT (generate these sections in order):
  1. [Section name] — [what to include / what angle to take]
  2. [Section name] — [what to include]
  3. [Section name] — [what to include]
  ...
  Include links to: [list of related sub-pages to link to]

Example (a product docs page)

CONTENT (generate these sections in order):
  1. Overview — One paragraph summarizing what this config option does.
  2. Syntax — A code block showing the full TOML syntax with defaults.
  3. Field reference — A table of all fields: name, type, default, description.
  4. Examples — Three real-world usage examples with commentary.
  5. Caveats — Known edge cases, gotchas, or version-specific behavior.
  6. See also — Links to related config pages and the main config reference.
Include links to: /configuration.html, /deployment.html, /examples.html
Tip: Always end the Content Enum with a "links to" line. This ensures the generated page has outbound links, which Rabbithole uses to populate the mapping table and create explorable depth.

5. The Depth Directive Pattern

PATTERN: DEPTH_DIRECTIVE

By default, a page generator has no guidance on how long or detailed to make a page. The result can range from a thin two-paragraph stub to an unexpectedly long essay. The Depth Directive explicitly instructs the generator on the expected length, density, and detail level of the output.

Template

DEPTH: [short|medium|long|exhaustive].
  Target length: ~[N] words of visible text.
  Detail level: [e.g. "introductory overview", "complete technical reference",
    "casual blog post", "dense academic treatment"].
  Code examples: [none|minimal (1-2)|several (3-5)|extensive].
  Tables: [none|use where helpful|required for reference sections].

Examples

# For a landing page
DEPTH: short. Target ~150 words. Detail level: punchy marketing overview.
Code examples: none. Tables: none.

# For a reference manual page
DEPTH: exhaustive. Target ~1200 words.
Detail level: complete technical reference, assume expert reader.
Code examples: extensive (at least 5, with annotations).
Tables: required for all parameter/field listings.

# For a blog post
DEPTH: medium. Target ~500 words.
Detail level: conversational, practical, minimal jargon.
Code examples: minimal (1-2 to illustrate key points).
Tables: none.
Tip: If you omit the Depth Directive entirely, model defaults vary widely. For any page where length matters — especially stubs vs. full references — always include it.

6. The Exclusion Pattern

PATTERN: EXCLUSION

LLMs have strong priors. Left unprompted, they will add certain elements to pages almost automatically: hero sections, call-to-action buttons, cookie banners, FAQ sections, "About Us" footers, emoji, social media icons, and more. If your design calls for restraint, you need to explicitly exclude these defaults.

The Exclusion Pattern is a compact list of things explicitly not to include. It is especially important when using a Reference Site Pattern (below) — the reference site may have features you want to exclude from the analogy.

Template

DO NOT include:
  - [element or feature]
  - [element or feature]
  - ...

Example (minimal doc site)

DO NOT include:
  - Hero sections, banner images, or splash headers
  - Call-to-action buttons or signup forms
  - Social media links or share buttons
  - Cookie consent banners or GDPR notices
  - Emoji or decorative icons
  - Dark mode toggles
  - "Was this helpful?" feedback widgets
  - External CSS frameworks (Bootstrap, Tailwind, etc.)
  - Any JavaScript whatsoever

Example (fictional site, tone control)

DO NOT include:
  - Modern Earth slang or anachronistic references
  - Fourth-wall breaks or meta-commentary
  - Humor or levity; maintain clinical tone throughout
  - References to real-world countries, companies, or people
Tip: The Exclusion Pattern is most powerful for tone and aesthetic control. LLMs default toward engaging, friendly, modern web conventions. If your site is austere, academic, or alien, the Exclusion Pattern is how you enforce that.

7. The Reference Site Pattern

PATTERN: REFERENCE_SITE

Sometimes the fastest way to specify an aesthetic is to name a reference site that the generator already knows well. Rather than describing every aspect of a design from scratch, you invoke a shared visual vocabulary by pointing to a real website as an aesthetic anchor.

This works because popular websites are well-represented in training data. The generator can invoke the structural, typographic, and tonal conventions of the reference site without you having to spell them out exhaustively. Combine with the Style Block for precision, and with the Exclusion Pattern to narrow which aspects of the reference to use.

Template

AESTHETIC REFERENCE: [URL or site name].
  Borrow: [aspect 1], [aspect 2], [aspect 3].
  Do NOT borrow: [aspect to exclude from the analogy].

Examples

# Plain technical documentation
AESTHETIC REFERENCE: gcc.gnu.org
  Borrow: plain white background, minimal nav, monospace code blocks, no decoration.
  Do NOT borrow: the dated table-based layout.

# Classic encyclopedia
AESTHETIC REFERENCE: Wikipedia (circa 2010)
  Borrow: left sidebar, infobox tables, section structure, neutral prose style.
  Do NOT borrow: edit links, talk page UI, or the Wikipedia logo/branding.

# Hacker News style
AESTHETIC REFERENCE: news.ycombinator.com
  Borrow: orange header bar, compact link list layout, minimal color palette.
  Do NOT borrow: comment threading or voting UI.

# Retro terminal aesthetic
AESTHETIC REFERENCE: text-mode BBS sites from the early 1990s
  Borrow: monospace everything, ASCII borders, green-on-black color palette.
  Do NOT borrow: low contrast to the point of illegibility.
Tip: Reference sites work best when they are famous and visually distinctive. Obscure or niche reference sites may not be well-represented in training data. When in doubt, fall back to the Style Block Pattern with explicit hex codes and measurements.

8. The Self-Referential Pattern

PATTERN: SELF_REFERENTIAL

Because Rabbithole generates each page in isolation, a page generator does not inherently know what URL it is generating content for. Including the target URL in the prompt is a surprisingly powerful signal: it tells the generator its own position in the site, lets it infer the page's purpose from URL structure, enables contextually appropriate "active" nav states, and helps prevent the generator from producing links that recursively point back to itself incorrectly.

The Self-Referential Pattern is simple: include the URL at the top of every prompt.

Template

PAGE URL: /[path/to/page.html]
PAGE TITLE: [Human-readable title of this page]
ROLE IN SITE: [brief description of what this page is for]

Example

PAGE URL: /reference/config/tls.html
PAGE TITLE: TLS Configuration Reference
ROLE IN SITE: Complete reference for all TLS-related configuration options.
  This is a deep-dive reference page, not a tutorial.

Using it for nav highlighting

When combined with the Nav Block, the Self-Referential Pattern lets the generator render the current page as non-linked plain text in the nav, providing a natural "you are here" indicator. 

PAGE URL: /getting-started.html

NAV (pipe-separated, 13px): Home (/) | Getting Started — current page,
  render as plain text, not a link | Architecture (/architecture.html) | ...
Tip: Even if you do not use nav highlighting, always include PAGE URL: in every prompt. It anchors the generator and improves the coherence of generated links within that page.

Combining Patterns

Most effective Rabbithole prompts combine multiple patterns. Here is a full example prompt for a sub-page of a documentation site, using all eight patterns: 

PAGE URL: /reference/cache.html
PAGE TITLE: Cache Configuration Reference
ROLE IN SITE: Deep-reference page for Rabbithole's response cache settings.

AESTHETIC REFERENCE: gcc.gnu.org — borrow plain layout, no decoration.

DESIGN: White #ffffff bg, black #000000 text, links #0000cc, visited #551a8b.
  Arial/Helvetica/sans-serif 14px. Max-width 860px centered. h2 with 1px
  solid #cccccc bottom border. Code: #f4f4f4 bg, 1px solid #ccc, Courier
  New 13px. No JS, no external CSS, no gradients.

NAV (pipe-separated, 13px):
  Home (/) | Getting Started (/getting-started.html) |
  Architecture (/architecture.html) | Configuration (/configuration.html) |
  Cache — current page (plain text) | Deployment (/deployment.html) |
  Examples (/examples.html) | About (/about.html)

UNIVERSE CONTEXT:
  Rabbithole: open-source Rust web server (github.com/ajbt200128/rabbithole,
  live at isarabbithole.com) that generates entire websites on the fly using
  LLMs. Each page is generated from only its stored prompt — no shared memory.
  Cache config controls how long generated pages are stored before expiry.

CONTENT (in order):
  1. Overview — what the cache layer does and why it matters.
  2. Syntax — TOML block showing all cache fields with defaults.
  3. Field reference — table: field name, type, default, description.
  4. Cache invalidation — how to clear or bypass the cache.
  5. Examples — two usage scenarios (high-traffic and dev mode).
  6. See also — links to /configuration.html and /architecture.html.

DEPTH: exhaustive. ~900 words. Complete technical reference, expert reader.
  Code examples: several (3-4). Tables: required.

DO NOT include:
  - Hero sections, CTAs, social links, emoji, or decorative icons
  - Any JavaScript
  - External CSS frameworks
  - Marketing language or promotional tone

This 40-line prompt encodes design, navigation, context, content structure, length, and constraints. The resulting page will be visually and tonally consistent with every other page on the site — even though no two pages were generated in the same LLM call.

Quick Reference

Pattern Solves Required?
Style Block Visual inconsistency across pages Yes, always
Nav Block Navigation missing or inconsistent Yes, always
Lore Block Fictional/brand context lost on sub-pages For fictional/branded sites
Content Enum Wrong structure or missing sections For precise content requirements
Depth Directive Pages too short or unexpectedly long When length matters
Exclusion Unwanted LLM defaults polluting output For minimal/austere designs
Reference Site Hard to describe aesthetic succinctly Optional, supplemental
Self-Referential Generator unaware of its own URL Yes, always

See Also