diff --git a/.agents/skills/eli5/README.md b/.agents/skills/eli5/README.md
new file mode 100644
index 000000000000000..25de96c71049f9d
--- /dev/null
+++ b/.agents/skills/eli5/README.md
@@ -0,0 +1,325 @@
+# ELI5 Technical Writing
+
+A technical writing simplification tool and philosophy that transforms dense, jargon-heavy technical content into accessible explanations for everyone—from developers and IT admins to marketers, students, and hobbyists.
+
+## What is ELI5?
+
+ELI5 (Explain Like I'm 5) is an approach to technical documentation that prioritizes clarity and understanding without sacrificing accuracy. It's built on the belief that technical concepts should be accessible to everyone, regardless of their background.
+
+This project provides:
+
+- **A philosophy** - Principles for making technical content approachable
+- **An OpenCode skill** - Automated tool for simplifying technical documentation
+- **Working examples** - Before/after demonstrations of the approach
+
+## Philosophy Overview
+
+Technical writing often prioritizes precision over clarity, leaving readers confused by jargon, unstated assumptions, and missing context. ELI5 addresses this by:
+
+- **Explaining the "why"** before the "what" and "how"
+- **Using tech-adjacent metaphors** that clarify without oversimplifying
+- **Identifying common pitfalls** readers encounter
+- **Providing practical use cases** to ground abstract concepts
+- **Layering explanations** so beginners and experts both benefit
+- **Maintaining technical accuracy** while improving accessibility
+
+Read the full philosophy in [agent.md](./agent.md).
+
+## Quick Start
+
+### Using the OpenCode Skill
+
+**Prerequisites:**
+- OpenCode CLI installed
+- This skill installed in `~/.config/opencode/skills/eli5/`
+
+**Installation:**
+```bash
+# Option 1: Copy to OpenCode skills directory
+cp -r /Users/caley/eli5 ~/.config/opencode/skills/eli5
+
+# Option 2: Symlink for development
+ln -s /Users/caley/eli5 ~/.config/opencode/skills/eli5
+```
+
+**Usage:**
+```bash
+# Simplify a documentation file
+/eli5 path/to/your-docs.md
+
+# Follow the interactive prompts:
+# 1. Choose which sections to simplify
+# 2. Review the generated .eli5.md comparison file
+# 3. Decide next steps (integrate, refine, or keep as reference)
+```
+
+**Output:**
+The skill creates a `.eli5.md` file with:
+- Side-by-side before/after comparison
+- Analysis of what made the original confusing
+- Plain-language summaries
+- Tech-adjacent metaphors
+- Use cases and practical context
+- Common pitfalls and related concepts
+
+### Example
+
+**Before (`api-docs.md`):**
+```markdown
+## POST /webhooks
+
+Creates a webhook subscription for edge events.
+
+### Parameters
+- `endpoint` (string, required): HTTPS URL
+- `events` (array, required): Event types
+```
+
+**After (`api-docs.eli5.md`):**
+```markdown
+### ✨ Simplified Version
+
+**In Plain Language:**
+A webhook lets your application receive automatic notifications when
+specific events happen, without constantly checking for updates.
+
+**Think of It Like:**
+A webhook is like a doorbell notification. Instead of constantly
+checking your front door to see if someone arrived (polling), the
+doorbell alerts you the moment someone presses it (push notification).
+
+**When You'd Use This:**
+- Getting notified when a deployment completes
+- Triggering actions when content is published
+- Syncing data between systems in real-time
+```
+
+See full examples in the [examples/](./examples/) directory.
+
+## Project Structure
+
+```
+eli5/
+├── README.md # This file
+├── agent.md # Technical writing philosophy + AI guidelines
+├── SKILL.md # OpenCode skill definition (streamlined)
+├── EXAMPLES_REFERENCE.md # Detailed patterns and examples
+├── TESTING_GUIDE.md # Comprehensive testing instructions
+├── QUICKSTART_TEST.md # Quick test verification (start here!)
+├── CONSERVATIVE_UPDATES.md # Change log for conservative approach
+├── SKILL_REORGANIZATION.md # Change log for file restructuring
+├── resources/
+│ ├── content-type-guide.md # Content type-specific patterns
+│ ├── pattern-library.md # Before/after transformation patterns
+│ └── ...
+└── examples/
+ ├── api-docs-example.md # Technical API documentation (original)
+ ├── api-docs-example.eli5.md # Simplified version with analysis
+ ├── architecture-example.md # Technical architecture doc (original)
+ ├── architecture-example.eli5.md # Simplified version with analysis
+ └── ...
+```
+
+## File Descriptions
+
+### [agent.md](./agent.md)
+The heart of the ELI5 philosophy. Contains:
+- **Part 1: Philosophy** - Core beliefs about technical writing
+- **Part 2: Agent Guidelines** - How AI agents should operate when simplifying content
+
+Essential reading for understanding the "why" behind ELI5.
+
+### [SKILL.md](./SKILL.md)
+The OpenCode skill definition. Includes:
+- Complete workflow description
+- Content analysis framework
+- Simplification principles
+- Output format specifications
+- Quality guidelines
+- Example usage
+
+**Streamlined for fast loading** (535 lines) - references detailed patterns in other files.
+
+This is the executable specification that powers the `/eli5` command.
+
+### [EXAMPLES_REFERENCE.md](./EXAMPLES_REFERENCE.md)
+Extended examples and detailed patterns. Contains:
+- **Content Type-Specific Patterns** - Full before/after examples for each type
+- **Simplification Principles** - Detailed writing guidelines
+- **Output Format Templates** - Structure and formatting examples
+- **Suggestions for Enhancement** - Line-specific recommendation patterns
+
+**Referenced by SKILL.md** when detailed examples are needed. Contains the verbose patterns that would make SKILL.md too large (1,834 lines of detailed examples).
+
+### [TESTING_GUIDE.md](./TESTING_GUIDE.md)
+Comprehensive testing instructions for the conservative enhancement approach:
+- Step-by-step test procedures
+- Expected results and success criteria
+- Detailed verification checklists
+- Common issues and fixes
+- Test results template
+
+Use this to verify the skill produces 1.5-2x enhancements (not 5-10x).
+
+### [QUICKSTART_TEST.md](./QUICKSTART_TEST.md)
+Quick reference for testing the conservative approach:
+- One-line test command
+- Success criteria table
+- Pass/fail quick check
+- Where to go for details
+
+**Start here** for rapid verification.
+
+### [CONSERVATIVE_UPDATES.md](./CONSERVATIVE_UPDATES.md)
+Change log documenting the shift from verbose (5-10x) to conservative (1.5-2x) enhancements:
+- What changed in each file
+- Before/after behavior comparison
+- Rationale for changes
+
+### [SKILL_REORGANIZATION.md](./SKILL_REORGANIZATION.md)
+Change log documenting the reorganization of SKILL.md (2,261 → 535 lines):
+- What was extracted to EXAMPLES_REFERENCE.md
+- File size comparison
+- Benefits of streamlined structure
+
+### [examples/](./examples/)
+Real-world demonstrations showing:
+- Typical technical documentation (before)
+- Full ELI5 transformation (after)
+- Applied principles in action
+
+Use these as templates for your own simplification work.
+
+## Content Types Supported
+
+The ELI5 skill automatically detects and applies specialized patterns for different documentation types:
+
+### Overview Pages
+**What:** Product landing pages with features/benefits
+**Pattern:** Problem → Solution → Benefit framing
+**Focus:** Lead with value, help users self-identify if they need this
+**Example:** `cloudflare-docs/overview.md` → Product intro with "Perfect for" section
+
+### Concept Pages
+**What:** Explanatory documentation about features/concepts
+**Pattern:** Analogy → Plain Explanation → Technical Details
+**Focus:** Build understanding with layered explanations
+**Example:** `examples/architecture-example.md` → Edge computing concepts
+
+### How To Guides
+**What:** Step-by-step procedural instructions
+**Pattern:** Multi-path approach (Dashboard + API)
+**Focus:** Context before steps, serve UI users and developers
+**Example:** Configuration guides with both UI and code paths
+
+### Reference Pages
+**What:** Technical specifications and parameters
+**Pattern:** Use-case organization + Two-tier descriptions
+**Focus:** Organize by purpose, provide plain + technical descriptions
+**Example:** `examples/reference-example.md` → Cache headers reference
+
+### Tutorials
+**What:** Guided projects teaching through application
+**Pattern:** Progressive complexity (Build → Enhance → Polish)
+**Focus:** Clear expectations, explain code, build confidence
+**Example:** `examples/tutorial-example.md` → Build a URL shortener
+
+### How It Works
+
+1. **Automatic Detection:** Skill analyzes document structure to identify content type
+2. **Validation:** Asks you to confirm or correct the detected type
+3. **Type-Specific Patterns:** Applies optimized simplification for that content type
+4. **Enhanced Output:** Generates `.eli5.md` with appropriate structure
+
+Each content type uses specific analysis criteria and simplification approaches documented in [SKILL.md](./SKILL.md).
+
+## Key Principles
+
+### 1. Context Before Details
+Always explain why something matters before diving into how it works.
+
+### 2. Tech-Adjacent Metaphors
+Use analogies rooted in familiar technology concepts, not overly simplistic comparisons.
+
+### 3. Respect Reader Intelligence
+Readers lack context, not intelligence. Never condescend with phrases like "simply" or "just."
+
+### 4. Layer Explanations
+Start with the simplest explanation, then add technical depth. Provide multiple entry points.
+
+### 5. Accuracy is Non-Negotiable
+Simplify language, not facts. Technical precision must be maintained.
+
+### 6. Focus on Use Cases
+Abstract concepts become clear when grounded in practical, realistic scenarios.
+
+### 7. Identify Common Pitfalls
+Help readers avoid misunderstandings by explicitly addressing common mistakes.
+
+### 8. Content-Type Awareness
+Recognize different documentation types and apply appropriate patterns—overviews need benefit-first framing, concepts need analogies, how-tos need multi-path instructions.
+
+### 9. Multi-Path Documentation
+Provide both Dashboard (UI) and API/CLI paths where applicable, serving beginners and technical users simultaneously.
+
+## Who This Is For
+
+### Writers
+- Technical writers seeking clarity principles
+- Developer advocates creating accessible documentation
+- Product managers writing user-facing content
+- Anyone documenting complex systems
+
+### Readers
+- Developers who want jargon-free explanations
+- IT admins learning new technologies
+- Students and hobbyists building skills
+- Marketers understanding technical products
+- Anyone who's ever thought "I wish someone would explain this simply"
+
+## Tone & Style
+
+ELI5 documentation is:
+
+✅ **Clear and professional** - Straightforward, no fluff
+✅ **Respectful** - Assumes readers are intelligent
+✅ **Practical** - Grounded in real use cases
+✅ **Accurate** - Technically correct
+
+ELI5 documentation is not:
+
+❌ **Condescending** - No "simply," "just," or "obviously"
+❌ **Oversimplified** - Accuracy isn't sacrificed for brevity
+❌ **Playful** - Professional tone maintained
+❌ **Action-focused** - Understanding comes before steps
+
+## Future Enhancements
+
+Planned features (documented, not yet implemented):
+
+- **Inline code comment reading** - Simplify code documentation and comments
+- **Multi-format support** - HTML, PDF, API specs (OpenAPI)
+- **Automated complexity scoring** - Jargon density metrics, readability analysis
+- **Interactive mode** - Iterative refinement with real-time feedback
+
+## Contributing
+
+This is a personal project, but contributions are welcome:
+
+1. Follow the philosophy in [agent.md](./agent.md)
+2. Use examples as templates
+3. Maintain clear, professional tone
+4. Ensure technical accuracy
+5. Test simplifications with diverse audiences
+
+## License
+
+MIT License - See individual files for details
+
+## Questions?
+
+Read [agent.md](./agent.md) for the complete philosophy and guidelines, or explore the [examples/](./examples/) directory to see ELI5 in action.
+
+---
+
+**Remember:** The goal isn't to "dumb down" technical content. It's to make expertise accessible while respecting both the subject matter and the reader.
diff --git a/.agents/skills/eli5/SKILL.md b/.agents/skills/eli5/SKILL.md
new file mode 100644
index 000000000000000..b8a2b347cfc976f
--- /dev/null
+++ b/.agents/skills/eli5/SKILL.md
@@ -0,0 +1,282 @@
+---
+name: eli5
+description: Transform technical jargon into clear explanations using before/after comparisons, metaphors, and practical context
+license: MIT
+compatibility: opencode
+metadata:
+ audience: mixed (developers, IT admins, marketers, students, hobbyists)
+ workflow: technical-simplification
+ output_format: before-after-comparison
+ supported_formats: .md, .mdx
+---
+
+## What I Do
+
+I transform dense, jargon-heavy technical documentation into accessible explanations. Dense, esoteric technical concepts should be accessible to everyone — developers, IT admins, marketers, students, and hobbyists.
+
+**Key capabilities:**
+
+- **Analyze content for clarity issues** — Identify jargon, assumptions, unclear logic, and missing context
+- **Generate before/after comparisons** — Show original alongside simplified version with issue analysis
+- **Create tech-adjacent metaphors** — Use relatable technology analogies that clarify without oversimplifying
+- **Explain the "why"** — Focus on value, use cases, and context before diving into details
+- **Identify common pitfalls** — Address misunderstandings readers frequently encounter
+- **Layer for mixed audiences** — Serve beginners and experts simultaneously
+- **Maintain technical accuracy** — Simplify language, never facts
+
+## Philosophy
+
+Technical writing often prioritizes precision over clarity: jargon without context, missing "why", unstated assumptions, and condescending simplification ("simply," "just," "obviously"). ELI5 fixes this through:
+
+1. **Context before details** — Start with "why" and "when" before "what" and "how"
+2. **Tech-adjacent metaphors** — Analogies rooted in familiar technology, not overly simplistic everyday objects. Acknowledge where metaphors break down.
+3. **Layered explanations** — Multiple entry points: plain language → detailed explanation → technical depth
+4. **Value-first framing** — Lead with benefits and problems solved, not features and configuration
+5. **Explicit pitfalls** — Address common misunderstandings directly
+6. **Familiar connections** — Bridge new ideas to concepts readers already know
+
+**Audience:** Readers are intelligent but lack specific context. Never write for the "lowest common denominator." Assume smart people who are unfamiliar with this particular domain.
+
+**Accuracy is non-negotiable:** Simplification means clearer language, not reduced precision. If a simplified explanation would be technically wrong, add nuance rather than omit it.
+
+**Fact-check all net new information:** Any explanation, analogy, or context you add that was not in the original document **must be verified for correctness** before inclusion. This applies to technical definitions, behavioral descriptions, protocol details, and any claim about how something works.
+
+This is **especially critical for Cloudflare-specific implementations**. Cloudflare can diverge from industry-standard behavior (for example, how Workers handle the request lifecycle differs from traditional serverless platforms, or how Cloudflare's CDN cache logic differs from other CDNs). Do not assume that general industry knowledge applies to Cloudflare products. When adding commentary about Cloudflare-specific behavior:
+
+1. **Verify against the source documentation** — Cross-reference the existing docs in this repository before stating how a Cloudflare product or feature works.
+2. **Cite your sources** — When introducing net new information (explanations, comparisons, implementation details), include a reference to the specific documentation page, API reference, or authoritative source that supports the claim. Use inline links or footnotes.
+3. **Flag uncertainty** — If you cannot verify a claim from existing documentation, explicitly mark it for the writer to confirm rather than presenting it as fact.
+
+**Tone:** Clear, direct, professional. Not condescending, not overly casual, not hyperbolic. Never use "simply," "just," "obviously," "clearly," "as everyone knows," or "it's easy to."
+
+## When to Use Me
+
+- Content assumes too much prior knowledge
+- Jargon and acronyms are not explained
+- Documentation jumps to "how" without explaining "why"
+- Readers struggle to understand when/where to use something
+- You want feedback on what makes content confusing
+
+## How I Work
+
+### Workflow
+
+**1. Accept File Path**
+
+```bash
+/eli5 path/to/documentation.md
+```
+
+Supported: `.md`, `.mdx`
+
+**2. Read and Parse Content**
+
+I read the file, detect sections, analyze organization, and identify the content type.
+
+**Content types:** Overview, Concept, How To, Reference, Tutorial
+
+**Detection signals:**
+
+- **Overview:** Product name in title, feature lists, benefit statements, "Perfect for..." sections
+- **Concept:** "What is...", "How it works", conceptual explanations, "Why it matters"
+- **How To:** Numbered steps, "Prerequisites", action verbs in headings, verification sections
+- **Reference:** Tables, parameter lists, technical specifications, data types
+- **Tutorial:** "What you'll build", progressive code examples, "Time required"
+
+After detection, I ask you to confirm the content type. Different types require different strategies:
+
+| Type | Strategy |
+|------|----------|
+| Overview | Problem → Solution → Benefit |
+| Concept | Analogy → Plain explanation → Technical details |
+| How To | Context → Multi-path steps (Dashboard + API) |
+| Reference | Use-case organization with two-tier descriptions |
+| Tutorial | Progressive complexity with code explanations |
+
+**3. Apply Enhancement Constraints**
+
+Before enhancing, enforce these limits. Target 1.5-2x expansion (not 5-10x). Enhance existing content with context, not replace it.
+
+**Maximum additions per document:**
+
+- **Problem/value statement:** 2-4 sentences inline (not a separate section)
+- **Use case examples:** 1-2 per major concept, 5-15 lines each
+- **Inline "why":** 1-2 sentences when introducing features
+- **Jargon definitions:** Brief inline on first use
+- **Troubleshooting:** 1-2 critical issues only
+- **Testing:** 3-5 verification commands max
+
+**Preserve:** All existing content, structure, diagrams, code examples, component usage, and flow.
+
+**Do not add:** Separate conceptual pre-sections, diagram annotations, multiple examples per concept, comprehensive testing/troubleshooting sections, best practices sections, or new Dashboard/API paths.
+
+**Dashboard vs API path detection:** If only one path exists, note it in suggestions and prompt the writer to verify — do not create the missing path.
+
+**4. Ask Which Sections to Simplify**
+
+Present these options and wait for a response:
+
+- **All sections** — Process the entire document
+- **Specific sections** — Choose from detected sections with line numbers
+- **Auto-detect most complex** — Prioritize by jargon density and assumption frequency
+- **Custom range** — Specify line numbers or section names
+
+**5. Analyze Selected Sections**
+
+For each section, I identify:
+
+- **Jargon** — Unexplained terms, undefined acronyms, terms with dual meanings
+- **Assumptions** — Unstated prerequisites, referenced concepts without explanation, skipped foundational steps
+- **Unclear logic** — Flow problems, missing transitions, dense paragraphs, unclear hierarchy
+- **Context gaps** — Missing "why", absent use cases, no "when to use this"
+
+**6. Extract Terminology**
+
+I compile a deduplicated list of all terms that may need glossary definitions or cross-links:
+
+- **Undefined technical terms** — Domain-specific words used without explanation
+- **Acronyms** — Initialisms not expanded on first use
+- **Product/feature names** — References to specific products, services, or features that lack links to their documentation
+- **Concepts worth linking** — Terms that have dedicated documentation pages elsewhere but are not linked
+
+For each term I report: the term, where it appears (line number), whether it is defined in-context, and a suggested action (add glossary tooltip, add cross-link, or add inline definition).
+
+Always include the Terminology Index in the output. If no terms need action, state that explicitly.
+
+**7. Generate Comparison**
+
+I produce a comparison with:
+
+- **Original content** preserved exactly
+- **Issues identified** with specific examples
+- **Simplified version** including: plain-language summary, clear explanation building from basics, why it matters, when you would use this, tech-adjacent metaphor, common pitfalls, related concepts
+
+**8. Report and Prompt**
+
+I report: summary of improvements made, what made the original confusing, and the full terminology index.
+
+Then I ask: **What would you like to do next?**
+
+1. **Suggest additional improvements**
+2. **Create a PR** with changes
+3. **Refine specific sections**
+4. **Apply changes to original** file
+5. **Keep as reference**
+
+## Decision Framework
+
+**Should I simplify a term?**
+
+- **Replace or explain** if: domain-specific jargon, most readers will not know it, a simpler term is equally accurate
+- **Keep but define** if: industry standard readers should learn, no simpler term is accurate, term appears frequently
+
+**Should I add content?**
+
+- **Yes** if: "why" is missing, use cases are absent, common misunderstandings are not addressed
+- **No** if: original is already clear, addition would pad without value, reader can infer from context
+
+**Should I remove content?**
+
+- **Rarely.** Only if genuinely redundant or tangential. Never remove caveats, accuracy qualifiers, or security warnings.
+
+## Quality Checklist
+
+Before finalizing, verify:
+
+- [ ] Technical accuracy maintained
+- [ ] Jargon identified and explained
+- [ ] Assumptions stated explicitly
+- [ ] "Why" comes before "what" and "how"
+- [ ] Use cases are realistic
+- [ ] Metaphors have clear 1:1 mapping with stated limitations
+- [ ] No condescending language
+- [ ] Enhanced version is 1.5-2x original (not 5-10x)
+- [ ] Original structure preserved (not reorganized)
+- [ ] 1-2 examples max per concept
+- [ ] Diagrams left untouched
+
+## Edge Cases
+
+- **Very long documents (>1000 lines):** Ask which sections to prioritize, offer to process in chunks
+- **Already-clear content:** Acknowledge clarity, suggest minor improvements only
+- **Highly technical content:** Maintain accuracy above all, use progressive disclosure
+- **Code-heavy docs:** Add plain-language explanations of what code accomplishes and why it is structured that way
+- **Multiple audience types:** Use labeled sections ("For developers:" / "For non-technical readers:")
+
+## Output Format
+
+Produce output following this template exactly. All sections are required.
+
+```markdown
+# ELI5 Simplified: [Original Doc Name]
+
+**Original:** `[file path]`
+**Sections simplified:** [count/list]
+
+---
+
+## Simplification Overview
+
+**What was confusing:**
+- [Issue pattern 1]
+- [Issue pattern 2]
+
+**Approach taken:**
+- [Strategy 1]
+- [Strategy 2]
+
+---
+
+## Section: [Original Heading]
+
+### Original Content
+[Exact text from source, preserved]
+
+### Issues Identified
+**Jargon:** [terms and why problematic]
+**Assumptions:** [unstated prerequisites]
+**Unclear Logic:** [structural issues]
+
+### Simplified Version
+**In Plain Language:** [One-sentence distillation]
+**What It Is:** [2-3 paragraphs building from basics]
+**Why It Matters:** [Benefits and value]
+**When You'd Use This:** [Use cases with context]
+**Think of It Like:** [Tech-adjacent metaphor]
+**Where this metaphor breaks down:** [Limitations]
+**Common Pitfalls:** [Misunderstanding → Correction]
+**Related Concepts:** [Connections to familiar ideas]
+
+---
+
+[Repeat for each section]
+
+---
+
+## Terminology Index
+
+| Term | Line | Defined? | Suggested Action |
+| ---- | ---- | -------- | ---------------- |
+| [term] | [line number] | Yes/No | Add glossary tooltip / Add cross-link to [page] / Add inline definition |
+
+---
+
+## Summary & Recommendations
+
+**Key improvements made:** [list]
+**Patterns noticed:** [meta-analysis]
+
+## Suggestions for Enhancement
+
+Line-numbered recommendations for further improvements:
+
+| Line(s) | Current Approach | Suggested Enhancement | Why | Priority |
+| ------- | ---------------- | --------------------- | --- | -------- |
+| [lines] | [what exists] | [what to change] | [why it improves accessibility] | High/Medium/Low |
+```
+
+## References
+
+- **Content type detection criteria:** `references/content-type-guide.md`
+- **Before/after pattern templates:** `references/pattern-library.md`
+- **Full examples:** `EXAMPLES_REFERENCE.md`
diff --git a/.agents/skills/eli5/recommendations/internal-dns/index.eli5.mdx b/.agents/skills/eli5/recommendations/internal-dns/index.eli5.mdx
new file mode 100644
index 000000000000000..6d9e9f57671e88a
--- /dev/null
+++ b/.agents/skills/eli5/recommendations/internal-dns/index.eli5.mdx
@@ -0,0 +1,205 @@
+---
+pcx_content_type: overview
+title: Internal DNS (beta)
+wid: internal-dns
+sidebar:
+ order: 14
+ label: Overview
+ group:
+ badge:
+ text: Beta
+ label: Internal DNS
+head:
+ - tag: title
+ content: Internal DNS
+---
+
+import {
+ Render,
+ Description,
+ Plan,
+ RelatedProduct,
+ DirectoryListing,
+ GlossaryTooltip,
+ Example,
+} from "~/components";
+
+
+ Simplify private network management with Cloudflare DNS for your internal
+ resources.
+
+
+
+
+Manage DNS records that should only be accessible within your private network—useful when you need internal systems (like `database.internal` or `api.corp`) to resolve differently for employees versus the public internet. Internal DNS [zones](/dns/internal-dns/internal-zones/) and [views](/dns/internal-dns/dns-views/) pair up with [Gateway resolver policies](/cloudflare-one/traffic-policies/resolver-policies/) so that you can control how a DNS query should be responded to according to query context, such as query source IP.
+
+**When you'd use this:** Organizations with multiple offices or regions often need the same hostname to resolve to different IP addresses depending on where the query originates—for example, `intranet.company.com` pointing to London servers for London users and San Francisco servers for SF users.
+
+
+
+## Architecture overview
+
+You can use different [connectivity options](/dns/internal-dns/connectivity/) to on-ramp your traffic to Cloudflare—such as WARP client on employee devices, Magic WAN for office networks, or Cloudflare Tunnel for servers. Then, Cloudflare Gateway resolver acts as an interface between the DNS client and internal DNS zones, determining which zones a query should access based on resolver policies you define.
+
+Internal DNS zones do not get assigned Cloudflare nameservers and can only be queried via Cloudflare Gateway resolver. This means they're completely private—no one outside your organization can query them, unlike public DNS zones which are visible to the entire internet.
+
+**How this differs from public DNS:** Public DNS zones (like `example.com`) are assigned Cloudflare nameservers and can be queried by anyone on the internet. Internal DNS zones exist only within your Cloudflare account and are only accessible through Gateway resolver. Even if someone knows your internal hostname (like `database.corp.local`), they cannot resolve it without going through your Gateway resolver with proper authentication.
+
+```mermaid
+flowchart LR
+ accTitle: Internal DNS query overview
+ accDescr: Diagram comparing internal DNS query with public DNS
+ A[Client]
+ subgraph Cloudflare account
+ subgraph Gateway
+ B[Default 1.1.1.1 resolver]
+ X[Resolver policy selecting an internal DNS view]
+ end
+ subgraph Authoritative DNS
+ Y[(Public DNS)]
+ Z[(Internal DNS)]
+ end
+ end
+
+ C[Public resolver]
+
+ B --Query--> Y
+ X --Query + View ID--> Z
+ A --Query--> B
+ A --Query--> X
+ C --Query--> Y
+```
+
+Internal DNS zones are grouped into DNS views, which are selected by the resolver policy you define. Views are usually logical groupings relevant to your organization, such as different geographical locations, departments (HR, Engineering), or network environments (production, staging). A single zone can exist in multiple views with different records—for example, `api.company.local` in the "London" view points to `10.0.1.5`, while the same zone name in the "San Francisco" view points to `10.0.2.5`.
+
+**Why views matter:** Without views, everyone in your organization would get the same DNS responses. Views let you customize responses based on who's asking—London employees can get London servers, developers can access staging environments, and contractors might have restricted access to only certain internal systems. This contextual resolution is what makes Internal DNS powerful for multi-region deployments and Zero Trust security models.
+
+```mermaid
+flowchart LR
+ accTitle: Internal DNS views and zones
+ accDescr: Diagram exemplifying Internal DNS views and zones relationship
+ subgraph Internal DNS
+ subgraph View 111 - London
+ Y[Zone 600
example.local]
+ Z[Zone 601
local]
+ end
+ subgraph View 110 - San Francisco
+ X[Zone 101
example.com]
+ B[Zone 100
example.local]
+ S[Zone 102
com]
+ end
+ W[Zone 701
net]
+ end
+```
+
+Internal DNS zones contain the DNS records that should be used to resolve an internal DNS query. Also, if no internal record is found within a matching internal zone, Cloudflare will check if the matching internal zone is [referencing another internal zone](/dns/internal-dns/internal-zones/reference-zones/)—this lets you share common records across multiple zones without duplicating them.
+
+
+
+```mermaid
+flowchart LR
+ accTitle: Internal DNS zones and internal records
+ accDescr: Diagram exemplifying Internal DNS zones and records relationship
+ subgraph View 111 - London
+ subgraph Zone 601 - local
+ S["@ A 192.0.2.10"]
+ T["ghi.example A 192.0.2.15"]
+ end
+ subgraph Zone 600 - example.local
+ X["@ A 192.0.2.1"]
+ Y["abc A 192.0.2.6"]
+ Z["def A 192.0.2.9"]
+ end
+ end
+```
+
+In this example, a query for `ghi.example.local` routed to view ID 111 would go to zone 600, which presents the longest matching zone name (`example.local`). Zone 600 does not contain a record for `ghi` but, if it is referencing zone 601, Cloudflare will then look for the queried record within the reference zone. This reference chain lets you organize records hierarchically—for instance, storing all `.local` records in one zone while having specific subdomain zones that reference it.
+
+
+
+## How it works: Query flow example
+
+When an employee queries an internal hostname, here's what happens:
+
+1. **Client makes DNS query:** User on WARP client queries `database.company.local`
+2. **Gateway evaluates policy:** Gateway checks resolver policies—is this user in London office? VPN? Specific device group?
+3. **Policy selects view:** Based on query context (source IP, device posture, user identity), resolver policy selects the appropriate view (e.g., "View 111 - London")
+4. **Zone lookup:** Gateway queries Internal DNS zones within that view for `database.company.local`
+5. **Response returned:** If found, returns the IP address (e.g., `10.0.1.100` for London database server)
+
+**Key difference from public DNS:** Public DNS always returns the same answer regardless of who asks. Internal DNS with views returns different answers based on who's asking and where they're asking from.
+
+## Common use cases
+
+**Multi-region infrastructure:** Route users to the nearest data center by returning different IPs based on their location—`api.company.com` resolves to `10.0.1.5` for London users and `10.0.2.5` for SF users.
+
+Example scenario: You have application servers in three regions (US, EU, APAC). Instead of hard-coding server addresses or managing complex routing, you create three views—one per region—each with the same zone name (`company.local`) but different IP addresses. Gateway resolver policies route queries to the appropriate view based on source location.
+
+**Zero Trust access control:** Create resolver policies that only allow specific device groups to resolve sensitive internal hostnames like `admin.internal` or `payroll.corp`, while other employees get NXDOMAIN (domain does not exist) responses.
+
+Example scenario: Only devices in the "Finance" group should be able to access `payroll.company.local`. Create a view containing the payroll zone, then set up a resolver policy that selects this view only for Finance group devices. When someone outside Finance tries to query `payroll.company.local`, their query uses the default view which doesn't contain that zone, resulting in NXDOMAIN—effectively making the hostname "invisible" to unauthorized users.
+
+**Development and staging environments:** Developers can access both production and staging systems using the same hostnames, while non-developers only see production.
+
+Example scenario: Create a "Developers" view that contains zones for both `prod.company.local` (pointing to production IPs) and `staging.company.local` (pointing to staging IPs). Non-developer employees use a "Standard" view that only contains the production zone. Developers can seamlessly switch between environments, while ensuring production systems remain accessible to everyone who needs them.
+
+## Prerequisites
+
+Before implementing Internal DNS, you'll need:
+
+- **Cloudflare Gateway:** Internal DNS requires Gateway resolver to route queries (included with Zero Trust plans)
+- **Connectivity method:** At least one way to route traffic through Cloudflare (WARP client, Magic WAN, or Cloudflare Tunnel)
+- **Internal IP ranges:** The private IP addresses you want your internal hostnames to resolve to (e.g., `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`)
+
+## Getting started
+
+To implement Internal DNS:
+
+1. **Set up connectivity:** Choose how traffic reaches Cloudflare (WARP client for employee devices, Magic WAN for office networks, or Cloudflare Tunnel for servers)
+2. **Create zones:** Define your internal DNS zones with the records you need (for example, create a `company.local` zone with records like `database.company.local → 10.0.1.100`)
+3. **Create views:** Group zones into logical views based on location, department, or environment—views determine which users see which zone responses
+4. **Configure policies:** Set up Gateway resolver policies that select the appropriate view based on query context (source IP, device posture, user identity)
+5. **Test:** Verify queries from different locations/users resolve to the expected IPs—check that London users get London IPs and SF users get SF IPs
+
+For detailed step-by-step setup instructions, see the [Get started guide](/dns/internal-dns/get-started/).
+
+## Resources
+
+
+
+## Related products
+
+
+ Set up policies to inspect DNS, Network, HTTP, and Egress traffic.
+
+
+
+ Improve security and performance for your entire corporate networking,
+ reducing cost and operation complexity.
+
+
+---
+
+**Enhancement summary:**
+
+This overview was enhanced with inline context explaining when you'd use Internal DNS, step-by-step query flow showing how views work, and three detailed use case examples with real-world scenarios. Added explanations of key concepts (views, zone referencing, privacy model) and a "Getting started" checklist.
+
+**What was added:**
+- Opening context: When to use Internal DNS with concrete example (lines 34-36)
+- Architecture explanations: On-ramp options, why zones are private (lines 42-44, 48-50)
+- Views explanation: Why views matter and how they enable customization (lines 73-75)
+- Query flow section: Step-by-step walkthrough of how Internal DNS processes queries (lines 114-126)
+- Zone referencing context: How reference chains work and why they're useful (lines 105-107)
+- Common use cases: Three detailed scenarios (multi-region, Zero Trust, dev/staging) with implementation examples (lines 128-151)
+- Getting started: 5-step setup checklist (lines 153-162)
+- Preserved: All MDX components (``, ``, ``, etc.), all three mermaid diagrams, and all original structure unchanged
+
+**Target expansion:** 1.89x (135 → 255 lines)
diff --git a/.agents/skills/eli5/references/EXAMPLES_REFERENCE.md b/.agents/skills/eli5/references/EXAMPLES_REFERENCE.md
new file mode 100644
index 000000000000000..742a86dc6ee14df
--- /dev/null
+++ b/.agents/skills/eli5/references/EXAMPLES_REFERENCE.md
@@ -0,0 +1,1834 @@
+# ELI5 Skill: Extended Examples Reference
+
+Detailed patterns, examples, and templates referenced by SKILL.md.
+
+**Purpose:** This file contains verbose examples and detailed patterns that would make SKILL.md too large. Reference sections below when you need detailed guidance or examples.
+
+---
+
+## Table of Contents
+
+1. [Content Type-Specific Patterns](#1-content-type-specific-patterns) - Full before/after examples for each content type
+2. [Simplification Principles](#2-simplification-principles) - Detailed writing guidelines
+3. [Output Format Templates](#3-output-format-templates) - Structure and formatting examples
+4. [Suggestions for Enhancement Examples](#4-suggestions-for-enhancement) - Line-specific recommendation examples
+
+---
+
+## 1. Content Type-Specific Patterns
+
+## Content Type-Specific Patterns
+
+Once content type is detected and validated, I apply type-specific simplification patterns for optimal results.
+
+### Overview Page Simplification
+
+**Purpose:** Help users quickly understand what a product/feature is and decide if they need it.
+
+**Required Elements:**
+- Opening benefit statement (what problem this solves)
+- Problem/Solution/Benefit structure
+- "Perfect for" self-identification section
+- Quick start link
+- Technical architecture separated to bottom
+
+**Analysis Focus:**
+- Does opening paragraph answer "what" and "why"?
+- Are features explained with benefits, not just descriptions?
+- Is there a clear call-to-action?
+- Are technical terms defined or separated?
+
+**Simplification Approach:**
+
+1. **Lead with benefits** - Convert technical descriptions to value propositions
+2. **Problem framing** - Start with the challenge users face
+3. **Feature → Benefit conversion** - Transform feature lists to outcome statements
+4. **Self-identification** - Add "Perfect for" with user scenarios
+5. **Separate technical details** - Move architecture to collapsible sections
+
+**Pattern Example:**
+
+❌ **Before (Technical-first):**
+```markdown
+## Product X
+
+Product X is a distributed edge computing platform utilizing V8
+isolates for serverless code execution with sub-millisecond cold
+start performance.
+
+Features:
+- Global anycast network deployment
+- Automatic scaling and load distribution
+- Pay-per-request pricing model
+```
+
+✅ **After (Benefit-first):**
+```markdown
+## Product X
+
+Run code worldwide without managing servers. Deploy in seconds,
+scale automatically, pay only for what you use.
+
+**What problem it solves:**
+Maintaining global infrastructure is expensive and complex. Product X
+runs your code in 300+ cities automatically, handling all the
+infrastructure for you.
+
+**Perfect for:**
+- Applications needing fast global performance
+- Teams wanting to skip server management
+- Projects with variable traffic (scale from zero to millions)
+
+[Get started in 5 minutes →]
+
+---
+
+**For technical users:** Built on V8 isolates with global anycast
+deployment. [Architecture details →]
+```
+
+---
+
+### Concept Page Simplification
+
+**Purpose:** Build understanding of WHY something works the way it does.
+
+**Required Elements:**
+- Opening analogy or visual (accessible to all)
+- Plain language definition
+- "Why it matters" business value
+- How it works (simplified explanation)
+- Real-world use cases (3-5 specific scenarios)
+- Technical details for advanced users (separated)
+
+**Analysis Focus:**
+- Is there an analogy early in the content?
+- Does it explain WHY before HOW?
+- Are use cases concrete and realistic?
+- Are technical details clearly separated?
+
+**Simplification Approach:**
+
+1. **Start with analogy** - Tech-adjacent comparison for mental model
+2. **Plain English definition** - What it is without jargon
+3. **Value first** - Why it matters before how it works
+4. **Layered explanation** - Simple → detailed → technical
+5. **Concrete examples** - Real scenarios, not abstract concepts
+
+**Pattern Example:**
+
+❌ **Before (Technical-only):**
+```markdown
+## Rate Limiting
+
+Rate limiting implements token bucket algorithms to control request
+throughput based on configurable parameters including burst size and
+refill rate. Requests exceeding limits receive 429 status codes.
+```
+
+✅ **After (Layered explanation):**
+```markdown
+## Rate Limiting
+
+**Think of it like:** A nightclub with maximum capacity. Even if
+1,000 people want to enter at once, you only let a controlled number
+in at a time to keep things manageable.
+
+**What it is:**
+Rate limiting controls how many requests can hit your website in a
+given time period. Without it, a sudden spike—whether from real
+users or attackers—could overwhelm your server.
+
+**Why you need it:**
+- Prevents DDoS attacks from taking your site down
+- Stops bots from scraping your content
+- Ensures fair usage across all users
+- Keeps infrastructure costs predictable
+
+**How it works:**
+You set a rule like "100 requests per minute per IP address." When
+someone exceeds this limit, we block additional requests until the
+time window resets.
+
+**Real scenarios:**
+- E-commerce site during Black Friday preventing bot purchases
+- API preventing scraping of product catalog
+- Forum preventing spam post flooding
+
+---
+
+**For technical users:** Implements token bucket algorithm with
+configurable burst size and refill rates. Returns 429 status with
+Retry-After header. [Implementation details →]
+```
+
+---
+
+### How To Page Simplification
+
+**Purpose:** Help users successfully accomplish specific tasks.
+
+**Required Elements:**
+- Context (what this accomplishes, why you'd do it)
+- Prerequisites listed upfront
+- Expected outcome stated
+- Time estimate (if non-trivial)
+- Dashboard path (UI-focused, detailed steps)
+- API/CLI path (code-focused, in collapsible section)
+- Verification steps
+- Common issues and troubleshooting
+
+**Analysis Focus:**
+- Is context provided before steps?
+- Are prerequisites clearly stated?
+- Is there both a Dashboard and API path?
+- Are verification steps included?
+- Are common pitfalls addressed?
+
+**Simplification Approach:**
+
+1. **Add context** - What's accomplished and why
+2. **State prerequisites** - What must be true before starting
+3. **Multi-path instructions** - Dashboard AND API/CLI options
+4. **Annotate steps** - Add notes for confusing points
+5. **Include verification** - How to confirm it worked
+6. **Address pitfalls** - Common issues encountered
+
+**Pattern Example:**
+
+❌ **Before (Steps-only):**
+```markdown
+## Enable Feature
+
+1. Navigate to Settings
+2. Click Security
+3. Toggle feature on
+4. Save changes
+```
+
+✅ **After (Contextual multi-path):**
+```markdown
+## Enable Feature
+
+**What this does:** Protects your site from [specific threat] by
+[specific mechanism].
+
+**Time required:** ~2 minutes
+**Prerequisites:** Admin access to your account
+
+**What happens:** After enabling, all incoming requests will be
+[specific behavior]. You'll see results in Analytics within 5 minutes.
+
+### Via Dashboard
+
+1. Log into your dashboard at dash.example.com
+2. Select your site from the list
+3. In the left sidebar, click **Security**
+4. Find **Feature Name** and toggle it **On**
+5. Click **Save Changes**
+
+💡 **Note:** Changes take effect immediately, but analytics may take
+5 minutes to update.
+
+### Via API
+
+
+Show API example
+
+```bash
+curl -X PATCH "https://api.example.com/v1/settings" \
+ -H "Authorization: Bearer YOUR_TOKEN" \
+ -d '{"feature_enabled": true}'
+```
+
+**Response:**
+```json
+{
+ "success": true,
+ "result": {
+ "feature_enabled": true,
+ "updated_at": "2026-02-09T10:30:00Z"
+ }
+}
+```
+
+[Full API documentation →]
+
+
+
+## Verify It's Working
+
+1. Visit your site in a new browser tab
+2. Open browser Developer Tools (F12)
+3. Check the Network tab for [specific header/behavior]
+4. You should see [expected result]
+
+## Troubleshooting
+
+**Problem:** Feature doesn't seem to be active
+**Solution:** Clear your browser cache and wait 5 minutes for
+propagation. Still not working? Check that [prerequisite].
+```
+
+---
+
+### Reference Page Simplification
+
+**Purpose:** Provide comprehensive technical details accessibly.
+
+**Required Elements:**
+- Opening context ("When you'd use this")
+- Common scenarios upfront
+- Use-case organization (not alphabetical)
+- Two-tier descriptions (plain English + technical spec)
+- Practical examples for each item
+- Real usage scenarios
+
+**Analysis Focus:**
+- Is content organized by use case or alphabetically?
+- Are descriptions both plain and technical?
+- Are practical examples included?
+- Is there context about when to use options?
+
+**Simplification Approach:**
+
+1. **Add opening context** - When you'd reference this section
+2. **Reorganize by use case** - Group by purpose, not A-Z
+3. **Two-tier descriptions** - Plain explanation + technical spec
+4. **Add examples** - Real usage with expected results
+5. **Include "when to use"** - Decision guidance
+
+**Pattern Example:**
+
+❌ **Before (Alphabetical specs-only):**
+```markdown
+## Cache Headers
+
+**Cache-Control:** Controls caching. Values: public, private,
+no-cache, max-age=seconds
+
+**Expires:** HTTP date for expiration
+
+**Pragma:** Legacy directive. Value: no-cache
+```
+
+✅ **After (Use-case organized with examples):**
+```markdown
+## Cache Headers Reference
+
+**When to use:** Control how long content stays cached and who can
+cache it.
+
+### Common Scenarios
+
+**Scenario 1:** Static assets (images, CSS, JS) → Cache for 1 year
+**Scenario 2:** Blog posts → Cache for 1 hour
+**Scenario 3:** User dashboards → Never cache
+
+---
+
+## Headers by Purpose
+
+### Long-Term Caching (Static Assets)
+
+#### `max-age=31536000` (1 year)
+
+**What it does:** Caches content for 1 year before checking for updates
+
+**When to use:** Files that never change, like `logo-v2.png` or
+`style.abc123.css` with version hash in filename
+
+**Technical spec:** Integer, seconds. Range: 0-31536000 (1 year max)
+
+**Example:**
+```http
+Cache-Control: public, max-age=31536000, immutable
+```
+
+**Result:** First visitor downloads the file. For the next year, all
+visitors get the cached version with zero origin requests.
+
+---
+
+#### `immutable`
+
+**What it does:** Tells browsers this file will literally never change
+
+**When to use:** Combine with `max-age` for versioned assets
+(filename includes hash/version number)
+
+**Technical spec:** No value. Presence activates directive.
+
+**Example:**
+```http
+Cache-Control: public, max-age=31536000, immutable
+```
+
+**Result:** Browsers won't revalidate even on refresh. Perfect for
+`style.abc123.css` where hash changes when content changes.
+
+---
+
+### Frequently Updated Content
+
+#### `max-age=3600` (1 hour)
+
+**What it does:** Caches content for 1 hour
+
+**When to use:** Content that updates occasionally but doesn't need
+to be real-time, like blog posts or product pages
+
+**Technical spec:** Integer, seconds
+
+**Example:**
+```http
+Cache-Control: public, max-age=3600
+```
+
+**Result:** Content stays cached for 1 hour. After expiration, next
+request checks origin for updates.
+
+---
+
+#### `no-cache`
+
+**What it does:** Always check with origin before using cached version
+
+**When to use:** Content that changes frequently but can still be
+cached briefly (shopping cart, personalized pages)
+
+**Technical spec:** No value. Presence activates.
+
+**Example:**
+```http
+Cache-Control: no-cache
+```
+
+**Result:** Every request checks origin via If-Modified-Since or
+ETag. If nothing changed, serves cached version (304 response).
+
+---
+
+### Never Cache
+
+#### `private, no-store`
+
+**What it does:** Prevents any caching
+
+**When to use:** Sensitive data (account info, payment details) or
+highly dynamic content (real-time scores, live chat)
+
+**Technical spec:** Combine both directives
+
+**Example:**
+```http
+Cache-Control: private, no-store
+```
+
+**Result:** Every request fetches fresh from origin. Nothing cached
+anywhere.
+```
+
+---
+
+### Tutorial Page Simplification
+
+**Purpose:** Teach through real-world application, building confidence progressively.
+
+**Required Elements:**
+- "What you'll build" with specific example
+- "Who this is for" with prerequisites
+- Time estimate
+- "What you'll learn" key concepts
+- Progressive complexity (minimal → full → polished)
+- Code block explanations ("What this does")
+- Troubleshooting section
+- Optional enhancements clearly marked
+
+**Analysis Focus:**
+- Does it start with "What you'll build"?
+- Are prerequisites clearly stated?
+- Is every code block explained?
+- Does complexity build progressively?
+- Are common issues addressed?
+
+**Simplification Approach:**
+
+1. **Set expectations** - What, who, time, learning outcomes
+2. **Start minimal** - Prove concept with simplest version
+3. **Progressive enhancement** - Add features one at a time
+4. **Explain every code block** - What it does and why
+5. **Troubleshoot** - Common issues students encounter
+6. **Mark optional** - Clearly separate enhancements from core
+
+**Pattern Example:**
+
+❌ **Before (Code-dump):**
+```markdown
+## Build X
+
+```javascript
+const handler = async (req) => {
+ const url = new URL(req.url)
+ return new Response('Hello')
+}
+addEventListener('fetch', e => e.respondWith(handler(e.request)))
+```
+```
+
+✅ **After (Explained progression):**
+```markdown
+## Build a URL Shortener
+
+### What You'll Build
+
+A working URL shortener that redirects short links to long URLs,
+stores mappings, and tracks click analytics.
+
+**Live example:** `short.example.com/github` → `github.com/cloudflare`
+
+### Who This Is For
+
+Developers comfortable with JavaScript. No prior experience with
+Workers needed, but you should understand:
+- HTTP requests and responses
+- JSON data format
+- Basic async/await
+
+### Time Required
+
+30-45 minutes
+
+### What You'll Learn
+
+- How to handle requests at the edge
+- Storing data in key-value storage
+- Building a simple API
+- Deploying code globally in seconds
+
+---
+
+## Step 1: Create Your First Worker
+
+Let's start with the absolute minimum—a Worker that responds to
+requests:
+
+```javascript
+// Entry point: runs for every HTTP request
+addEventListener('fetch', event => {
+ // Pass request to our handler function
+ event.respondWith(handleRequest(event.request))
+})
+
+// Handler: processes the request and returns a response
+async function handleRequest(request) {
+ return new Response('Your URL shortener will live here!', {
+ headers: { 'content-type': 'text/plain' }
+ })
+}
+```
+
+**What this code does:**
+
+- **Line 2:** Listens for incoming HTTP requests
+- **Line 4:** Calls `handleRequest` to process each request
+- **Line 8-12:** Returns a simple text response
+
+**Test it:**
+
+1. Deploy this code to Workers
+2. Visit your Worker's URL
+3. You should see: "Your URL shortener will live here!"
+
+This proves your Worker is running. Now let's add actual functionality...
+
+---
+
+## Step 2: Add URL Parsing
+
+Now let's make it recognize short codes in the URL:
+
+```javascript
+async function handleRequest(request) {
+ // Extract the pathname from the URL
+ // Example: https://short.example.com/github → "/github"
+ const url = new URL(request.url)
+ const shortCode = url.pathname.slice(1) // Remove leading "/"
+
+ // For now, just echo back the short code
+ return new Response(`You requested: ${shortCode}`, {
+ headers: { 'content-type': 'text/plain' }
+ })
+}
+```
+
+**What changed:**
+
+- **Line 3-4:** Parse the full URL to extract the path
+- **Line 5:** Get the short code (everything after the `/`)
+- **Line 8:** Echo it back so we can test
+
+**Test it:**
+
+1. Visit `your-worker.dev/test`
+2. You should see: "You requested: test"
+3. Try `your-worker.dev/abc123` → "You requested: abc123"
+
+Now we can detect what short code someone's requesting...
+
+---
+
+## Step 3: Store URL Mappings
+
+[Continue building progressively...]
+
+---
+
+## Common Issues
+
+**Problem:** "Error: Exceeded CPU limit"
+
+**Cause:** Your Worker is doing too much computation in a single request
+
+**Solution:** Workers have a 50ms CPU time limit. Move heavy processing
+to background tasks or use Durable Objects for longer operations.
+
+**Problem:** "KV data not updating"
+
+**Cause:** KV is eventually consistent and may take 60 seconds to
+propagate globally
+
+**Solution:** For testing, add a cache-busting parameter (`?v=2`) or
+wait 60 seconds between writes and reads.
+
+---
+
+## Optional Enhancements
+
+Want to take this further? Here are some ideas:
+
+**Add Click Analytics** (Medium difficulty)
+- Store click count in KV
+- Increment on each redirect
+- Create stats endpoint
+
+**Custom Short Codes** (Easy)
+- Let users choose their short code
+- Check if code is already taken
+- Return error if unavailable
+
+**Expiring Links** (Medium)
+- Store expiration timestamp
+- Check before redirecting
+- Return 404 if expired
+```
+
+---
+
+## Simplification Principles
+
+---
+
+## 2. Simplification Principles
+
+## Simplification Principles
+
+### Plain Language Guidelines
+
+**Sentence Structure:**
+
+✅ **One idea per sentence** when possible
+- "Webhooks send notifications. This happens when events occur."
+- Not: "Webhooks, which are HTTP callbacks, send notifications containing event data to your specified endpoint when certain events occur on the platform."
+
+✅ **Active voice** over passive
+- "The system sends a notification"
+- Not: "A notification is sent by the system"
+
+✅ **Concrete nouns** over abstract
+- "Your endpoint receives a POST request"
+- Not: "The interface abstraction layer facilitates data transmission"
+
+✅ **Common words** when equally accurate
+- "Use" not "utilize"
+- "Help" not "facilitate"
+- "Start" not "initiate"
+
+✅ **Short paragraphs** (3-4 sentences maximum)
+- Easier to scan and digest
+- Provides visual breathing room
+- Maintains focus on single topic
+
+**Terminology Handling:**
+
+**Always define on first use:**
+```markdown
+An API (Application Programming Interface) defines how programs
+can request and exchange data...
+```
+
+**Expand acronyms:**
+```markdown
+CDN (Content Delivery Network)
+CI/CD (Continuous Integration/Continuous Deployment)
+HMAC (Hash-based Message Authentication Code)
+```
+
+**Provide context for technical terms:**
+```markdown
+Not: "Configure the webhook endpoint."
+But: "A webhook endpoint is the URL where we'll send notifications.
+Configure it to point to your server."
+```
+
+### Metaphor Creation (Tech-Adjacent)
+
+**What makes a good metaphor:**
+
+1. **Rooted in familiar technology** - Build on concepts readers likely know
+2. **1:1 concept mapping** - Key aspects align accurately
+3. **Clarifies, doesn't confuse** - Simpler than original concept
+4. **Acknowledges limitations** - States where metaphor breaks down
+
+**Metaphor Library (Core Examples):**
+
+#### 1. API → Restaurant Menu
+
+```markdown
+**Think of It Like:**
+An API is like a restaurant menu. The menu shows you what dishes
+are available (endpoints), what customizations you can request
+(parameters like "no onions" or "extra spicy"), and what you'll
+receive (the response - your meal). You don't need to know how the
+kitchen operates or what cooking techniques they use. You just order
+from the menu, and the kitchen handles the rest.
+
+**Where this breaks down:**
+Unlike a restaurant where you wait for your food, API responses are
+usually near-instantaneous. Also, APIs can fail (kitchen is out of
+ingredients), requiring error handling.
+```
+
+#### 2. Caching → Library Reserve Desk
+
+```markdown
+**Think of It Like:**
+Caching is like a library's reserve desk. Popular books are kept at
+the front desk for quick access instead of requiring a trip to the
+stacks. The first person requesting a book triggers the librarian to
+fetch it from the stacks, but then it stays at the reserve desk so
+subsequent readers can grab it immediately.
+
+**Where this breaks down:**
+Caches expire (books eventually return to the stacks), and cache
+invalidation (deciding when to return books) is more complex than
+the metaphor suggests.
+```
+
+#### 3. Load Balancing → Grocery Checkout Lanes
+
+```markdown
+**Think of It Like:**
+Load balancing is like grocery store checkout lanes. Instead of
+everyone lining up at a single register (which would create a huge
+wait), customers are distributed across multiple lanes. If one lane
+gets too long or a register breaks down, the store can redirect
+people to other lanes.
+
+**Where this breaks down:**
+Load balancers are more intelligent than checkout lane selection—they
+know which servers are healthy, how busy they are, and can route
+based on sophisticated algorithms.
+```
+
+#### 4. Webhooks → Doorbell Notifications
+
+```markdown
+**Think of It Like:**
+A webhook is like a doorbell notification. Instead of constantly
+checking your front door to see if someone arrived (polling), the
+doorbell alerts you the moment someone presses it (push notification).
+You only respond when there's actually something to respond to.
+
+**Where this breaks down:**
+Doorbells are instantaneous, while webhooks have some latency due to
+network transmission. Also, webhooks can fail if your server is down
+(like a broken doorbell).
+```
+
+#### 5. Authentication → Building Security Badge
+
+```markdown
+**Think of It Like:**
+Authentication is like a building security badge system. You present
+your badge (credentials) when entering. The system verifies you are
+who you claim to be (authentication), then checks what floors you're
+allowed to access (authorization). Different badges have different
+access levels.
+
+**Where this breaks down:**
+Digital authentication often uses time-limited tokens (like a badge
+that expires), and can verify identity through multiple methods
+(password + fingerprint), which isn't common with physical badges.
+```
+
+#### 6. Rate Limiting → Freeway Metering Lights
+
+```markdown
+**Think of It Like:**
+Rate limiting is like freeway on-ramp metering lights. Instead of
+letting everyone merge at once (causing congestion), the lights
+control how many cars enter per minute. This keeps traffic flowing
+smoothly on the main freeway. If you arrive too fast, you wait at
+the red light.
+
+**Where this breaks down:**
+Rate limits are often user-specific (you get your own limit), not
+shared like a metering light. Also, rate limits reset on schedules
+(every hour, every day), unlike continuous traffic flow.
+```
+
+#### 7. Database Indexing → Book Index
+
+```markdown
+**Think of It Like:**
+A database index is like the index at the back of a textbook. Instead
+of reading every page to find mentions of "webhooks," you check the
+index, which tells you exactly which pages to look at. The index
+takes up extra space, but makes searching dramatically faster.
+
+**Where this breaks down:**
+Database indexes need updating when data changes (like keeping a
+book index current as you add pages), and choosing which fields to
+index involves tradeoffs between search speed and write speed.
+```
+
+#### 8. CDN → Local Warehouses
+
+```markdown
+**Think of It Like:**
+A CDN (Content Delivery Network) is like having local warehouses
+instead of shipping everything from one central warehouse. When
+someone in California orders a product, it ships from the California
+warehouse (faster delivery). When someone in New York orders, it
+ships from New York. Same product, closer source.
+
+**Where this breaks down:**
+Unlike physical warehouses with unique inventory, CDNs store copies
+of the same content in many locations. Updates need to propagate to
+all locations (cache invalidation), which has no physical warehouse
+equivalent.
+```
+
+#### 9. Containers → Shipping Containers
+
+```markdown
+**Think of It Like:**
+Software containers are like shipping containers. Before shipping
+containers existed, moving goods required different methods for
+different types of cargo. Shipping containers standardized this—put
+anything inside a standard container, and it can go on any ship,
+truck, or train. Software containers work the same way: package your
+application and its dependencies, and it runs anywhere.
+
+**Where this breaks down:**
+Shipping containers physically isolate cargo, while software
+containers share the same operating system kernel. Also, you can run
+thousands of software containers on one machine, unlike physical
+containers.
+```
+
+#### 10. Environment Variables → Settings Panel
+
+```markdown
+**Think of It Like:**
+Environment variables are like your application's settings panel—
+configuration values that change behavior without modifying code.
+Just like you might set your phone to dark mode or adjust notification
+preferences, environment variables let you configure database URLs,
+API keys, or feature flags without rewriting your application.
+
+**Where this breaks down:**
+Environment variables are usually set before the application starts
+(not changed while running), and they're text-based rather than UI
+toggles. They're also specific to each deployment environment (dev,
+staging, production).
+```
+
+**Creating New Metaphors:**
+
+When you encounter a concept not in this library, create a new metaphor by:
+
+1. Identifying the core mechanism or purpose
+2. Finding a tech-adjacent analog readers likely understand
+3. Mapping key concepts 1:1
+4. Testing: Does this clarify or create new confusion?
+5. Stating where the metaphor breaks down
+
+### Why-Focused Explanations
+
+**Always structure content in this order:**
+
+**1. The Problem (Why)**
+```markdown
+When building applications, you often need to know when something
+happens on another platform—like when a payment completes, a file
+finishes uploading, or a deployment succeeds. Constantly checking
+for updates (polling) wastes resources and creates delays.
+```
+
+**2. The Solution (What)**
+```markdown
+Webhooks solve this by pushing notifications to you. When an event
+happens, we immediately send a message to your server with the details.
+```
+
+**3. The Value (Why It Matters)**
+```markdown
+This means:
+- Your application responds in real-time instead of polling
+- You save resources (no constant checking)
+- Users get faster updates
+- You only process events that actually happened
+```
+
+**4. The Use Cases (When)**
+```markdown
+Common scenarios:
+- Triggering workflows when deployments complete
+- Updating your database when content changes
+- Sending notifications when payments are processed
+- Syncing data between systems automatically
+```
+
+**5. The Implementation (How)**
+```markdown
+To set up a webhook:
+1. Create an endpoint URL where we'll send notifications
+2. Configure which events you want to receive
+3. Verify requests are from us (using signatures)
+4. Process the event data and take appropriate action
+```
+
+This order respects how humans learn: **purpose before mechanism**.
+
+### Multi-Audience Layering
+
+Serve different knowledge levels simultaneously:
+
+**Structure for Mixed Audiences:**
+
+```markdown
+**In Plain Language:**
+[One sentence anyone can grasp]
+
+**What It Is:**
+[2-3 paragraphs building from basics, no jargon assumed]
+
+**Why It Matters:**
+[Benefits applicable to all readers]
+
+**When You'd Use This:**
+[Scenarios showing practical value]
+
+**Think of It Like:**
+[Metaphor for conceptual understanding]
+
+---
+
+**For developers:**
+Technical implementation details, API references, code examples
+
+**For non-technical readers:**
+Focus on outcomes, when to involve technical help, business impact
+```
+
+**Example in Practice:**
+
+```markdown
+## Webhook Signature Verification
+
+---
+
+## 3. Output Format Templates
+
+## Output Format & Structure
+
+### Generated File Template
+
+When I simplify documentation, I create a `.eli5.md` file with this structure:
+
+```markdown
+# ELI5 Simplified: [Original Doc Name]
+
+**Original:** `[file path]`
+**Simplified on:** [timestamp]
+**Sections simplified:** [list of sections]
+
+---
+
+## 📋 Simplification Overview
+
+**What was confusing:**
+- [Pattern 1 - e.g., Heavy acronym use without expansion]
+- [Pattern 2 - e.g., Assumed understanding of HTTP protocols]
+- [Pattern 3 - e.g., Jumped to implementation without explaining purpose]
+
+**Approach taken:**
+- [Strategy 1 - e.g., Added one-sentence summaries for each concept]
+- [Strategy 2 - e.g., Expanded all acronyms on first use]
+- [Strategy 3 - e.g., Added "Why this matters" to each section]
+- [Strategy 4 - e.g., Created tech-adjacent metaphors for abstract ideas]
+
+---
+
+## Section: [Original Heading]
+
+### 📄 Original Content
+
+```
+[Exact text from source, formatting preserved]
+```
+
+### ⚠️ Issues Identified
+
+**Jargon:**
+- `[term]` - [Why problematic, what's assumed]
+- `[term]` - [Why problematic, what's assumed]
+
+**Assumptions:**
+- [What's assumed - e.g., "Assumes reader understands REST principles"]
+- [What's assumed - e.g., "References 'the config file' without showing where"]
+
+**Unclear Logic:**
+- [Issue - e.g., "Jumps from concept to code without transition"]
+- [Issue - e.g., "No explanation of why this approach was chosen"]
+
+### ✨ Simplified Version
+
+**In Plain Language:**
+[One crisp sentence capturing the essence without jargon]
+
+**What It Is:**
+[2-3 paragraphs building understanding from basics. Define terms.
+Explain concepts. Build progressively. No jargon assumed.]
+
+**Why It Matters:**
+[Value proposition and concrete benefits]
+
+- **Benefit 1:** [Specific, concrete impact]
+- **Benefit 2:** [Specific, concrete impact]
+- **Benefit 3:** [Specific, concrete impact]
+
+**When You'd Use This:**
+
+- **Scenario 1:** [Realistic use case with context]
+ - Example: "When building a chat application that needs real-time message delivery..."
+
+- **Scenario 2:** [Realistic use case with context]
+ - Example: "When synchronizing inventory between your store and warehouse..."
+
+- **Scenario 3:** [Realistic use case with context]
+ - Example: "When triggering post-deployment tasks like cache clearing..."
+
+**Think of It Like:**
+[Tech-adjacent metaphor with detailed explanation]
+
+[Full metaphor explanation, making connections explicit]
+
+**Where this metaphor breaks down:**
+[Acknowledge limitations honestly]
+
+**Common Pitfalls:**
+
+- **Pitfall:** [What people commonly misunderstand]
+ **Reality:** [Correction with explanation]
+
+- **Pitfall:** [Common mistake]
+ **Reality:** [How it actually works]
+
+**Related Concepts:**
+[Connections to things readers might already know]
+
+- "If you've used [familiar concept], this works similarly..."
+- "This is the technical equivalent of [known idea]..."
+- "Related to [concept], but differs in that..."
+
+---
+
+[Repeat structure for each section]
+
+---
+
+## 📊 Summary & Recommendations
+
+**Key Improvements Made:**
+
+1. **[Improvement category]**
+ - [Specific change made]
+ - [Impact on clarity]
+
+2. **[Improvement category]**
+ - [Specific change made]
+ - [Impact on clarity]
+
+3. **[Improvement category]**
+ - [Specific change made]
+ - [Impact on clarity]
+
+**Patterns Noticed:**
+
+[Meta-analysis of what made this documentation difficult]
+
+- **Jargon overload:** [Details]
+- **Assumption patterns:** [Details]
+- **Structure issues:** [Details]
+- **Missing context:** [Details]
+
+**Recommendations for Future Writing:**
+
+- [Suggestion 1 - e.g., "Define acronyms on first use"]
+- [Suggestion 2 - e.g., "Start each section with 'why' before 'how'"]
+- [Suggestion 3 - e.g., "Include at least one real-world use case per concept"]
+- [Suggestion 4 - e.g., "Add metaphors for abstract concepts"]
+
+---
+
+## ✅ Next Steps
+
+Review complete! What would you like to do next?
+
+1. **Suggest additional improvements** - Identify other sections or refinements
+2. **Create a PR** - Integrate these changes into the original documentation
+3. **Refine specific sections** - Focus on particular areas that need more work
+4. **Apply changes to original** - Update the source file with simplified content
+5. **Keep as reference** - Use this comparison for review/learning only
+
+Let me know how you'd like to proceed!
+```
+
+### File Naming Convention
+
+**Input:** `path/to/documentation.md`
+**Output:** `path/to/documentation.eli5.md`
+
+**Input:** `api-reference.mdx`
+**Output:** `api-reference.eli5.mdx`
+
+The `.eli5` suffix clearly indicates this is a simplified version while preserving the original format extension.
+
+### Suggestions for Enhancement Section
+
+After the main simplification and summary, I include a **"Suggestions for Enhancement"** section that identifies specific opportunities to improve accessibility further.
+
+**Format:**
+
+Each suggestion includes:
+- **Line reference:** Specific location in the original document
+- **Section name:** What part of the doc this applies to
+- **Current approach:** What's there now
+- **Suggested enhancement:** What could be added
+- **Why this helps:** Accessibility benefit explained
+- **Implementation:** Concrete code/example showing the enhancement
+
+**Example:**
+
+```markdown
+---
+
+## 📝 Suggestions for Enhancement
+
+---
+
+## 4. Suggestions for Enhancement
+
+## 📝 Suggestions for Enhancement
+
+These suggestions show where additional patterns could improve accessibility:
+
+### Line 45-52: Add Multi-Path Instructions
+
+**Location:** Section "Enable Always Use HTTPS"
+**Current approach:** Dashboard-only instructions provided
+
+**Suggested enhancement:** Add API path for technical users who prefer code
+
+**Why this helps:**
+- Serves both UI users and developers with their preferred method
+- Technical users can automate the process via API
+- Provides complete coverage for mixed audiences
+
+**Implementation:**
+```markdown
+### Via API
+
+
+Show API example
+
+\`\`\`bash
+curl -X PATCH "https://api.cloudflare.com/client/v4/zones/{zone_id}/settings/always_use_https" \\
+ -H "Authorization: Bearer {token}" \\
+ -d '{"value":"on"}'
+\`\`\`
+
+**Response:**
+\`\`\`json
+{
+ "success": true,
+ "result": {
+ "id": "always_use_https",
+ "value": "on"
+ }
+}
+\`\`\`
+
+
+\`\`\`
+
+---
+
+### Line 78-85: Move Technical Details to Collapsible
+
+**Location:** Section "How TLS Encryption Works"
+**Current approach:** Technical cipher suite details inline with main explanation
+
+**Suggested enhancement:** Move advanced technical details to collapsible section
+
+**Why this helps:**
+- Beginners get the simple explanation without being overwhelmed
+- Experts can expand for full technical depth
+- Maintains clear progressive disclosure
+- Reduces cognitive load for those learning basics
+
+**Implementation:**
+\`\`\`markdown
+## How TLS Encryption Works
+
+Your connection is encrypted using industry-standard TLS 1.3 protocol,
+ensuring no one can intercept your data in transit.
+
+
+For technical users: Cipher suite details
+
+We support TLS 1.3 with modern AEAD cipher suites including:
+- TLS_AES_128_GCM_SHA256
+- TLS_AES_256_GCM_SHA384
+- TLS_CHACHA20_POLY1305_SHA256
+
+Perfect forward secrecy via X25519 key exchange. [Full TLS configuration →]
+
+
+\`\`\`
+
+---
+
+### Line 120-122: Add Recommended Default
+
+**Location:** Encryption mode options comparison
+**Current approach:** Lists all options (Off, Flexible, Full, Full Strict) equally
+
+**Suggested enhancement:** Call out recommended default for most users
+
+**Why this helps:**
+- Reduces decision paralysis for uncertain users
+- Provides a safe starting point
+- Guides users toward best security practices
+- Acknowledges that not all users can evaluate tradeoffs
+
+**Implementation:**
+\`\`\`markdown
+### Encryption Modes
+
+**Recommended for most sites:** Full (Strict)
+
+Provides maximum security by validating your origin server's
+certificate. This is the best option if your server has a valid SSL
+certificate installed.
+
+#### Other Options
+
+- **Off:** No encryption (Not recommended - only use for testing)
+- **Flexible:** Encrypts visitor-to-Cloudflare only (Use if your
+ server doesn't have SSL)
+- **Full:** Encrypts entire path but doesn't validate certificate
+- **Full (Strict):** Maximum security with certificate validation ✅
+\`\`\`
+
+---
+
+### Line 195-200: Add Concrete Use Case
+
+**Location:** Feature description section
+**Current approach:** Abstract benefit statement without example
+
+**Suggested enhancement:** Add realistic use case showing feature in action
+
+**Why this helps:**
+- Makes abstract benefits concrete and relatable
+- Helps users visualize how they'd use this
+- Provides "aha moment" of recognition
+- Increases confidence in feature relevance
+
+**Implementation:**
+\`\`\`markdown
+**Why you need it:**
+Prevents attackers from overwhelming your site with fake traffic.
+
+**Real scenario:**
+An e-commerce site during Black Friday gets hit by bots trying to
+buy limited inventory. DDoS protection automatically filters out
+the bot traffic, letting real customers complete their purchases
+while the attack is absorbed across Cloudflare's network.
+
+Without protection, the site would crash within minutes, losing
+thousands in sales.
+\`\`\`
+```
+
+**When to include suggestions:**
+
+Include this section when:
+- Multi-path opportunities exist (Dashboard + API)
+- Technical details could be collapsed
+- Missing recommended defaults
+- Abstract concepts need concrete examples
+- Progressive disclosure could be improved
+- Common decision points lack guidance
+
+**Placement:**
+
+The Suggestions section appears:
+- After the "Summary & Recommendations" section
+- Before the "Next Steps" section
+- Clearly separated with heading and explanation
+
+This makes suggestions actionable without cluttering the main before/after comparison.
+
+---
+
+## Important Guidelines
+
+### Quality Checklist
+
+Before finalizing any simplified content, verify:
+
+- [ ] **Technical accuracy maintained** - No facts changed or oversimplified
+- [ ] **One-sentence summary** captures essence without jargon
+- [ ] **Jargon identified** and either explained or replaced
+- [ ] **Assumptions stated** explicitly in Issues section
+- [ ] **"Why" comes before "what"** in explanations
+- [ ] **Use cases are realistic** and practical
+- [ ] **Metaphor has 1:1 mapping** of key concepts
+- [ ] **Metaphor limitations** acknowledged
+- [ ] **Common pitfalls** are genuinely common (not invented)
+- [ ] **Tone is professional** and respectful
+- [ ] **No condescending language** ("simply," "just," "obviously")
+- [ ] **Reader intelligence** respected throughout
+
+### Tone Rules
+
+**Never use these condescending phrases:**
+
+❌ "Simply configure the endpoint..."
+❌ "Just add the webhook URL..."
+❌ "Obviously, you'll need to..."
+❌ "Clearly, this requires..."
+❌ "As everyone knows..."
+❌ "It's easy to..."
+❌ "All you have to do is..."
+
+**Use these respectful alternatives:**
+
+✅ "To configure the endpoint, you'll need to..."
+✅ "Add the webhook URL by..."
+✅ "This requires..."
+✅ "Here's how this works..."
+✅ "This involves..."
+✅ "The process is..."
+
+### Accuracy Is Non-Negotiable
+
+**Good simplification:**
+```markdown
+Webhooks send HTTP POST requests to your endpoint URL whenever
+specified events occur. Think of it as a notification system where
+we call your server instead of you constantly checking ours.
+```
+*Accurate, clear, uses metaphor effectively*
+
+**Bad simplification:**
+```markdown
+Webhooks let programs talk to each other.
+```
+*Too vague, loses important details, not actually helpful*
+
+**When complex accuracy is needed:**
+
+Use progressive disclosure:
+
+```markdown
+**Simplified:** Rate limiting controls how many requests you can
+make in a time period, like 100 requests per minute.
+
+**More precisely:** Rate limits apply per API key and reset on a
+sliding window. If you hit the limit, you'll receive a 429 status
+code with a Retry-After header indicating when you can try again.
+```
+
+### Handling Different Content Types
+
+#### API Documentation
+
+Focus on:
+- What the endpoint does (purpose)
+- When you'd use it (scenarios)
+- What you send (parameters explained)
+- What you get back (response explained)
+- Common use cases
+- Error handling (what can go wrong)
+
+**Add value through:**
+- Explaining parameter purposes, not just types
+- Showing realistic request/response examples
+- Clarifying common misunderstandings
+- Connecting to real-world workflows
+
+#### Architecture Documentation
+
+Focus on:
+- Problem being solved
+- Why this approach was chosen
+- Tradeoffs made (what was gained/lost)
+- When this architecture makes sense
+- Alternatives considered
+
+**Add value through:**
+- Explaining decision rationale
+- Making tradeoffs explicit
+- Providing context for choices
+- Connecting to business requirements
+
+#### Code Documentation
+
+Focus on:
+- What the code accomplishes
+- Why it's structured this way
+- Key concepts or patterns used
+- What to watch out for
+
+**Add value through:**
+- Plain-language "reading guides"
+- Explaining non-obvious choices
+- Clarifying complex logic
+- Showing how pieces fit together
+
+## Edge Cases & Handling
+
+### Very Long Documents (>1000 lines)
+
+**Strategy:**
+
+1. **Offer processing options:**
+ - "This document has 1,500 lines across 25 sections. How would you like to proceed?"
+ - Option A: Process all sections
+ - Option B: Focus on specific sections (show list)
+ - Option C: Auto-detect most complex sections
+ - Option D: Process in chunks (1-10, 11-20, etc.)
+
+2. **Auto-detection logic:**
+ - Calculate jargon density (technical terms per 100 words)
+ - Count assumption indicators ("as you know," references without explanation)
+ - Identify sections with no use cases or "why" statements
+ - Prioritize sections with highest complexity scores
+
+3. **Chunk processing:**
+ - Process 5-10 sections at a time
+ - Generate partial `.eli5.md` files
+ - Offer to continue with next chunk
+
+### Already-Clear Content
+
+**When content is already well-written:**
+
+```markdown
+## 📋 Simplification Overview
+
+**What was done well:**
+- Clear section headings with logical flow
+- Terms defined on first use
+- Good use of examples
+- "Why" explained before "how"
+
+**Minor improvements suggested:**
+- Could add a tech-adjacent metaphor for [concept]
+- Section 3 could benefit from a concrete use case
+- Consider adding "common pitfalls" to section 5
+
+**Overall assessment:**
+This documentation is already quite accessible. The suggestions above
+are minor enhancements rather than necessary corrections.
+```
+
+**Avoid:**
+- Adding unnecessary verbosity
+- Creating problems that don't exist
+- Over-explaining clear content
+- Padding just to have something to say
+
+### Highly Technical Content
+
+**Strategy:**
+
+1. **Maintain accuracy first**
+ - Never oversimplify to the point of incorrectness
+ - Keep technical terms when they're important
+ - Preserve necessary complexity
+
+2. **Layer explanations**
+ ```markdown
+ **High-level:** [What it accomplishes]
+ **How it works:** [Simplified mechanism]
+ **Technical details:** [Precise specifications]
+ ```
+
+3. **Add explanatory prose**
+ - Don't change technical specs
+ - Add plain-language explanations alongside
+ - Provide "reading guides" for complex sections
+
+4. **Use progressive disclosure**
+ - Start with simplest useful explanation
+ - Build to full technical detail
+ - Make it clear which sections are for whom
+
+### Code-Heavy Documentation
+
+**Strategy:**
+
+1. **Don't oversimplify code itself**
+ - Code should remain accurate
+ - Don't rewrite functional code for simplicity
+ - Preserve technical correctness
+
+2. **Add explanatory context**
+ ```markdown
+ **What this code does:**
+ [Plain-language explanation]
+
+ **Why it's structured this way:**
+ [Architectural rationale]
+
+ **Key points to understand:**
+ - [Important concept 1]
+ - [Important concept 2]
+
+ ```python
+ [Original code, unchanged]
+ ```
+ ```
+
+3. **Create "reading guides"**
+ - Walk through complex code step-by-step
+ - Explain what each section accomplishes
+ - Highlight non-obvious choices
+
+### MDX Files with Components
+
+**Strategy:**
+
+1. **Focus on prose content**
+ - Simplify documentation text
+ - Leave component code unchanged
+
+2. **Explain component purpose**
+ ```markdown
+ **What this component does:**
+ The component displays syntax-highlighted code with
+ copy functionality, making it easier for readers to use the examples.
+ ```
+
+3. **Don't explain React/framework details**
+ - Unless that's specifically what the doc is about
+ - Focus on what the component accomplishes for users
+ - Avoid diving into implementation unless relevant
+
+## Future Enhancements
+
+*Documented for future implementation*
+
+### Planned Features
+
+**1. Inline Code Comment Reading**
+
+Support for code files with inline documentation:
+
+```python
+# Input: analyze.py
+def process_webhook(payload, signature):
+ """
+ Processes incoming webhook notifications.
+
+ Verifies signature, parses payload, triggers handlers.
+ """
+ # Implementation...
+```
+
+**Planned behavior:**
+- Extract docstrings and comments
+- Simplify technical language in comments
+- Add explanatory prose for complex logic
+- Generate "code walkthrough" guides
+
+**Supported formats:**
+- `.js`, `.ts`, `.tsx` (JavaScript/TypeScript)
+- `.py` (Python)
+- `.go` (Go)
+- `.rb` (Ruby)
+- `.java` (Java)
+
+**2. Multi-Format Support**
+
+Beyond Markdown:
+
+- **HTML documentation** - Parse and simplify web-based docs
+- **PDF technical papers** - Extract and clarify academic/research content
+- **Confluence/Wiki pages** - Simplify internal documentation
+- **OpenAPI specs** - Make API specifications more accessible
+
+**3. Automated Complexity Scoring**
+
+Quantitative analysis:
+
+- **Jargon density** - Technical terms per 100 words
+- **Readability scores** - Flesch-Kincaid, SMOG index
+- **Assumption detection** - Flag phrases indicating assumed knowledge
+- **Context gap analysis** - Identify missing "why" and "when" statements
+
+**Auto-prioritization:**
+- Sort sections by complexity
+- Focus on highest-value simplifications
+- Generate complexity reports
+
+**4. Interactive Mode**
+
+Iterative refinement:
+
+- Process section-by-section with user feedback
+- Real-time refinement based on input
+- Iterative improvement cycles
+- A/B testing of different metaphors
+
+## Examples
+
+### Example 1: API Documentation
+
+**Before (Original):**
+
+```markdown
+## POST /webhooks
+
+Creates a webhook subscription for edge events.
+
+### Parameters
+
+- `endpoint` (string, required): HTTPS URL
+- `events` (array, required): Event types
+- `secret` (string, optional): HMAC signing key
+
+### Response
+
+Returns a `webhook` object.
+```
+
+**After (Simplified):**
+
+```markdown
+### ✨ Simplified Version
+
+**In Plain Language:**
+Set up automatic notifications that we'll send to your server whenever
+specific events occur.
+
+**What It Is:**
+A webhook subscription tells our system to notify your application
+when certain events happen (like a deployment completing or content
+being published). Instead of your application constantly checking for
+updates (polling), we push notifications to you the moment events occur.
+
+**Why It Matters:**
+- **Real-time updates** - Your application responds immediately
+- **Resource efficiency** - No wasted API calls checking for changes
+- **Reliability** - You never miss an event
+- **Automation** - Trigger workflows automatically
+
+**When You'd Use This:**
+- **Deployment notifications:** Trigger post-deployment tasks when builds complete
+- **Content synchronization:** Update your CMS when content changes
+- **Monitoring:** Alert your team when errors occur
+- **Integration:** Connect multiple systems to respond to events
+
+**Think of It Like:**
+A webhook is like setting up a doorbell notification on your phone.
+Instead of constantly checking your front door camera to see if someone
+arrived (polling), the doorbell alerts you the moment someone presses
+it (push notification). You only respond when there's actually something
+to respond to.
+
+**Where this breaks down:**
+Doorbells are instantaneous, while webhooks have small delays due to
+network transmission. Also, webhooks can fail if your server is down
+(like a broken doorbell), so you need retry logic.
+
+**Parameters Explained:**
+
+- **`endpoint`** - The URL where we'll send notifications (your server's
+ address that listens for webhook events). Must use HTTPS for security.
+
+- **`events`** - Which events you want to receive (like `deployment.succeeded`
+ or `content.published`). You choose only the events you care about.
+
+- **`secret`** - Optional security key for verifying notifications actually
+ come from us. We use this to create a signature you can verify.
+
+**Common Pitfalls:**
+
+- **Pitfall:** Thinking webhooks are 100% reliable
+ **Reality:** Network issues or server downtime can cause missed notifications.
+ Implement retry logic and consider periodic polling as a backup.
+
+- **Pitfall:** Not verifying signatures
+ **Reality:** Without signature verification, attackers could send fake
+ webhooks to trigger unauthorized actions.
+
+**Related Concepts:**
+If you've used RSS feeds, webhooks work similarly—both push updates to
+you. The difference is webhooks are programmable and work with any type
+of event, not just content updates.
+```
+
+### Example 2: Architecture Decision
+
+**Before (Original):**
+
+```markdown
+## Edge Deployment Architecture
+
+We've implemented a globally distributed edge architecture utilizing
+V8 isolates for multi-tenant execution with microsecond cold starts
+and automatic geographic distribution.
+```
+
+**After (Simplified):**
+
+```markdown
+### ✨ Simplified Version
+
+**In Plain Language:**
+We run your code on servers located around the world, close to your
+users, making responses nearly instant regardless of where users are.
+
+**What It Is:**
+Traditional servers run in specific data centers—if your server is in
+Virginia and your user is in Singapore, every request travels across
+the world and back (adding hundreds of milliseconds). Our edge
+architecture runs your code on servers in hundreds of cities worldwide,
+so requests are handled by the nearest server.
+
+**Why It Matters:**
+- **Speed:** Users get responses in 10-50ms instead of 200-500ms
+- **Reliability:** If one location fails, others continue serving traffic
+- **Scale:** Handles traffic spikes automatically across all locations
+- **Simplicity:** You deploy once; we handle global distribution
+
+**When You'd Use This:**
+- **Global applications:** Users are distributed worldwide
+- **API endpoints:** Need fast response times everywhere
+- **Dynamic content:** Content that can't be cached must still be fast
+- **High availability:** Can't afford regional outages
+
+**Think of It Like:**
+Instead of one central warehouse shipping products nationwide (slow
+delivery to distant customers), you have local warehouses in every major
+city. When someone orders, it ships from their nearest warehouse. Same
+product, faster delivery, handled automatically.
+
+**The Technical Approach:**
+
+We use "V8 isolates"—lightweight execution environments that start in
+microseconds (thousandths of a millisecond). Traditional "serverless"
+functions use containers that take 50-500ms to start. Isolates are
+fast enough that we don't need to keep them warm; they start on-demand
+for each request.
+
+**Why this architecture:**
+We evaluated three approaches:
+
+1. **Traditional servers:** Fast but requires manual geographic setup
+2. **Container-based serverless:** Globally distributed but slow cold starts
+3. **Isolate-based edge:** Global + fast (our choice)
+
+**Tradeoff made:**
+Isolates have some limitations compared to full containers (no arbitrary
+system libraries, limited execution time). We accepted these constraints
+for the massive speed improvement.
+
+**Common Pitfalls:**
+- **Pitfall:** Assuming it works like traditional servers
+ **Reality:** Stateless execution—no persistent local storage, no background jobs
+
+- **Pitfall:** Expecting Node.js compatibility
+ **Reality:** Implements web standards, not full Node.js APIs
+
+**Related Concepts:**
+If you've used CDNs (Content Delivery Networks), this is similar but
+for code execution, not just static files. Like a CDN distributes
+content globally, we distribute code execution globally.
+```
+
+## Remember
+
+**Your mission:**
+- Make technical concepts accessible
+- Maintain technical accuracy
+- Respect reader intelligence
+- Focus on understanding
+
+**Always include:**
+- One-sentence plain language summary
+- Clear "why" and "when" explanations
+- Tech-adjacent metaphor with limitations
+- Common pitfalls with corrections
+- Use cases grounding abstract concepts
+
+**Quality standards:**
+- Technical accuracy is non-negotiable
+- Metaphors must clarify, not confuse
+- Tone must be professional and respectful
+- No condescending language ever
+
+**Process:**
+1. Ask which sections to focus on
+2. Identify specific issues (jargon, assumptions, logic, context)
+3. Generate complete before/after comparison
+4. Prompt for next steps
+
+**Output:**
+- Create `.eli5.md` file in same directory
+- Include all required elements per section
+- Provide actionable recommendations
+- Offer clear next-step options
+
+**Philosophy:**
+Technical expertise should never be a barrier to understanding. Every
+person deserves clear, accurate, respectful documentation.
+
+---
+
+**For full philosophy and detailed agent guidelines, see:** [agent.md](./agent.md)
+
+**For working examples, see:** [examples/](./examples/)
+
+**License:** MIT
+**Version:** 1.0
+**Last Updated:** February 2026
+
diff --git a/.agents/skills/eli5/references/content-type-guide.md b/.agents/skills/eli5/references/content-type-guide.md
new file mode 100644
index 000000000000000..85d544a7c071296
--- /dev/null
+++ b/.agents/skills/eli5/references/content-type-guide.md
@@ -0,0 +1,687 @@
+# Content Type Guide
+
+Operational guide for detecting and simplifying different documentation types.
+
+---
+
+## Purpose
+
+This guide provides:
+- **Detection criteria** for identifying content types
+- **Required elements** checklist for each type
+- **Simplification patterns** specific to each type
+- **Quick reference** for operational use
+
+---
+
+## CRITICAL: Conservative Enhancement Guidelines
+
+**Target expansion: 1.5-2x original content length**
+
+For each content type below, the enhancement patterns are designed to ADD MINIMAL CONTEXT AND EXAMPLES, not restructure or massively expand.
+
+**Universal constraints:**
+- Maximum 1-2 examples per major concept
+- Each example: 5-15 lines
+- Inline "why" explanations: 1-2 sentences
+- No diagram annotations
+- Preserve all original structure
+- No separate conceptual sections before content
+- Brief troubleshooting only (1-2 issues for tutorials)
+- Minimal testing guidance (3-5 commands for tutorials)
+
+**When patterns below suggest "Add [section]":**
+- Interpret as "enhance inline" not "create separate major section"
+- Keep additions brief and integrated
+- Target 1.5-2x expansion, not 5-10x
+
+---
+
+## Content Type Overview
+
+| Type | Purpose | Key Pattern | Example |
+|------|---------|-------------|---------|
+| **Overview** | Help users decide if they need this | Problem → Solution → Benefit | Product landing pages |
+| **Concept** | Build understanding of "why" | Analogy → Plain → Technical | "What is rate limiting?" |
+| **How To** | Enable task completion | Context → Multi-path steps | "Enable HTTPS" |
+| **Reference** | Provide comprehensive specs | Use-case organization | API parameters, headers |
+| **Tutorial** | Teach through application | Build → Enhance → Polish | "Build a URL shortener" |
+
+---
+
+## 1. Overview Pages
+
+### Detection Criteria
+
+**Look for:**
+- Product/feature name in title or H1
+- Feature lists or capability descriptions
+- "What is [Product]" sections
+- Benefit statements or value propositions
+- "Get started" or call-to-action links
+- Lack of step-by-step instructions
+
+**Confidence signals:**
+- Multiple features described briefly
+- High-level product description
+- Links to detailed documentation
+- "Perfect for" or use case sections
+- Pricing or plan information
+
+**Example titles:**
+- "Cloudflare Workers"
+- "Introduction to Gateway"
+- "What is Workers KV?"
+
+### Required Elements Checklist
+
+- [ ] Opening benefit statement (what problem solved)
+- [ ] Problem/Solution/Benefit structure
+- [ ] "Perfect for" self-identification section
+- [ ] Clear call-to-action ("Get started" link)
+- [ ] Feature descriptions with benefits (not just specs)
+- [ ] Technical architecture separated/collapsed
+
+### Simplification Pattern (Conservative)
+
+**Target: 1.5-2x original length**
+
+**Minimal additions:**
+1. **Add 2-4 sentence problem statement** (if completely missing) at document start
+2. **Add 1-2 use case examples inline** (5-10 lines each) showing who benefits
+3. **Add inline "why"** (1 sentence) when introducing features
+4. **Define jargon on first use** (brief inline definition)
+
+**Structure to preserve:**
+- Keep original opening and headings
+- Don't reorganize sections
+- Don't move architecture (just add brief intro if it leads)
+
+**Example enhancement:**
+
+Original (8 lines):
+```markdown
+# Internal DNS
+
+Manage DNS records for your private network.
+
+Internal DNS zones pair with Gateway resolver policies to control
+DNS query responses.
+
+## Features
+- Create internal zones
+- Configure views
+- Link to Gateway
+```
+
+Enhanced (15 lines - 1.9x):
+```markdown
+# Internal DNS
+
+Manage DNS records for your private network without running your own DNS
+servers. This simplifies operations and integrates with Cloudflare Gateway.
+
+Internal DNS zones pair with Gateway resolver policies to control DNS query
+responses based on context (source IP, user identity, domain).
+
+**Example use case:** A multi-region company creates separate views for London
+and SF offices. Users query the same hostname (api.company.internal) but get
+different IP addresses based on location.
+
+## Features
+- Create internal zones - Private namespaces accessible only via Gateway
+- Configure views - Logical groupings that route different users to different resources
+- Link to Gateway - Resolver policies determine which view to use
+```
+
+What was added:
+- 1 sentence "why" (without running own servers)
+- Brief context for zones (source IP, user identity)
+- 1 example (3 lines)
+- Inline definitions for features (1 sentence each)
+- Total: 7 lines added to 8 original = 15 lines (1.9x) ✅
+
+### Common Issues to Fix (Conservative Approach)
+
+- **Leading with technical architecture** → Add 1-2 sentence benefit intro before it (don't move it)
+- **Feature lists without context** → Add brief inline explanations (1 sentence per feature)
+- **Missing use case** → Add 1 concrete example inline (5-10 lines)
+- **Jargon in opening** → Define on first use (parenthetical or brief clause)
+- **No "why"** → Add 1 sentence explaining problem solved
+
+---
+
+## 2. Concept Pages
+
+### Detection Criteria
+
+**Look for:**
+- "What is..." or "Understanding..." titles
+- Explanatory content (not procedural)
+- "How it works" sections
+- Conceptual diagrams or explanations
+- "Why" explanations
+- Analogies or metaphors (sometimes)
+
+**Confidence signals:**
+- Explains mechanisms, not steps
+- Educational tone
+- Links to related concepts
+- Theory before practice
+- Multiple explanation approaches
+
+**Example titles:**
+- "Understanding Rate Limiting"
+- "How Caching Works"
+- "What is Edge Computing?"
+
+### Required Elements Checklist
+
+- [ ] Opening analogy/visual (accessible to all)
+- [ ] Plain language definition
+- [ ] "Why it matters" business value
+- [ ] How it works (simplified explanation)
+- [ ] Real-world use cases (3-5 scenarios)
+- [ ] Technical details for advanced users (separated)
+- [ ] Related concepts links
+
+### Simplification Pattern
+
+**Structure:**
+```markdown
+# [Concept Name]
+
+**Think of it like:** [Tech-adjacent analogy]
+
+**What it is:** [Plain English definition without jargon]
+
+**Why you need it:**
+- [Benefit 1]
+- [Benefit 2]
+- [Benefit 3]
+
+**How it works:** [Simplified technical explanation]
+
+**Real scenarios:**
+- [Use case 1 with context]
+- [Use case 2 with context]
+- [Use case 3 with context]
+
+---
+
+**For technical users:**
+[Technical implementation, architecture, algorithms]
+```
+
+### Common Issues to Fix
+
+- **Technical jargon first** → Start with analogy
+- **Missing "why"** → Add business value/benefits section
+- **Abstract examples** → Use concrete, realistic scenarios
+- **No layering** → Add progressive disclosure (simple → technical)
+- **Buried technical details** → Separate clearly
+
+---
+
+## 3. How To Pages
+
+### Detection Criteria
+
+**Look for:**
+- Action verbs in titles (Configure, Enable, Create, Set up)
+- Numbered steps or procedures
+- "Prerequisites" sections
+- Screenshots or UI guidance
+- "Verify" or "Test" sections
+- Command examples or code blocks
+
+**Confidence signals:**
+- Clear sequential structure
+- Specific actionable steps
+- Tool/UI references
+- Expected outcomes stated
+- Troubleshooting sections
+
+**Example titles:**
+- "Enable Always Use HTTPS"
+- "Configure DNS Settings"
+- "Create a Worker"
+
+### Required Elements Checklist
+
+- [ ] Context (what this accomplishes, why)
+- [ ] Prerequisites listed upfront
+- [ ] Expected outcome stated
+- [ ] Time estimate (if > 5 minutes)
+- [ ] Dashboard path (UI steps with bold elements)
+- [ ] API/CLI path (code examples in collapsible)
+- [ ] Verification steps ("How to tell it worked")
+- [ ] Troubleshooting common issues
+
+### Simplification Pattern (Conservative)
+
+**Target: 1.5-2x original length**
+
+**For how-to guides, preserve existing steps and add minimal context:**
+
+**Minimal additions:**
+1. **Add 1-2 sentence "what this accomplishes"** at top (if missing)
+2. **Add inline "why"** (1 sentence) for non-obvious steps
+3. **Add 1 example** showing when you'd use this (3-5 lines)
+4. **Add brief verification** (2-3 commands) if completely missing
+5. **Add 1-2 troubleshooting notes** for critical failures only
+
+**Preserve:**
+- Original step numbering and flow
+- Existing Dashboard/API paths (don't create new ones)
+- All screenshots and UI elements
+- Existing structure
+
+**Example enhancement:**
+
+Original (12 lines):
+```markdown
+# Create a DNS View
+
+## Dashboard
+
+1. Go to Internal DNS
+2. Click Create View
+3. Enter view name
+4. Select zones to include
+5. Click Save
+
+## API
+
+Use the create view endpoint with zone IDs.
+```
+
+Enhanced (20 lines - 1.67x):
+```markdown
+# Create a DNS View
+
+Create a logical grouping of zones that determines which DNS records users see.
+Useful for multi-region setups or environment separation.
+
+**Example:** Create "London View" and "SF View" to route users to nearest datacenter.
+
+## Dashboard
+
+1. Go to Internal DNS → Views
+2. Click **Create View**
+3. Enter descriptive view name (e.g., "London Production View")
+4. Select zones to include - Choose which internal zones belong in this view
+5. Click **Save** - View receives unique ID for use in Gateway policies
+
+**Verify:** View appears in Views list with selected zones shown.
+
+## API
+
+Use the create view endpoint with zone IDs.
+
+\`\`\`bash
+curl -X POST /api/views -d '{"name": "London View", "zone_ids": ["id1", "id2"]}'
+\`\`\`
+
+**If view creation fails:** Check zone IDs are valid and not already in another view.
+```
+
+What was added:
+- 2-sentence purpose statement (2 lines)
+- 1 example (1 line)
+- Inline context for 2 steps (2 lines)
+- Brief verification (1 line)
+- API code example (2 lines)
+- 1 troubleshooting note (1 line)
+- Total: 8 lines added to 12 original = 20 lines (1.67x) ✅
+
+**What was NOT added:**
+- Comprehensive troubleshooting section
+- Multiple examples
+- Separate "Understanding Views" section
+- Extensive testing procedures
+```
+
+### Common Issues to Fix
+
+- **No context before steps** → Add "What this does" introduction
+- **Missing prerequisites** → State upfront what's needed
+- **Dashboard-only** → Add API/CLI path in collapsible
+- **No verification** → Add "How to tell it worked" section
+- **Missing notes** → Annotate confusing steps
+
+---
+
+## 4. Reference Pages
+
+### Detection Criteria
+
+**Look for:**
+- Tables of parameters/settings/options
+- Alphabetical organization (often)
+- Technical specifications
+- Data types, valid values, constraints
+- API endpoint documentation
+- Configuration option lists
+
+**Confidence signals:**
+- Dense technical details
+- Systematic coverage (all options listed)
+- Minimal narrative prose
+- Code/parameter examples
+- "Reference" or "API" in title
+
+**Example titles:**
+- "Cache Control Headers Reference"
+- "API Endpoints"
+- "Configuration Options"
+
+### Required Elements Checklist
+
+- [ ] Opening context ("When you'd use this reference")
+- [ ] Common scenarios upfront (not at end)
+- [ ] Use-case organization (not alphabetical)
+- [ ] Two-tier descriptions (plain + technical)
+- [ ] Practical examples for each item
+- [ ] "When to use" decision guidance
+- [ ] Real usage scenarios with expected results
+
+### Simplification Pattern
+
+**Structure:**
+```markdown
+# [Reference Title]
+
+**When to use:** [Context for entire reference]
+
+## Common Scenarios
+
+- [Scenario 1]: Use [option X]
+- [Scenario 2]: Use [option Y]
+
+---
+
+## [Category 1: Grouped by Purpose]
+
+### [Option Name]
+
+**What it does:** [Plain English description]
+
+**When to use:** [Specific use case]
+
+**Technical spec:** [Data type, range, constraints]
+
+**Example:**
+```[language]
+[Realistic usage example]
+```
+
+**Result:** [What happens when this is used]
+
+---
+
+### [Next Option]
+
+[Same structure...]
+```
+
+### Common Issues to Fix
+
+- **Alphabetical organization** → Reorganize by use case/purpose
+- **Specs without context** → Add "When to use" guidance
+- **Missing examples** → Add realistic usage for each item
+- **No decision help** → Add scenario-based recommendations
+- **Plain or technical only** → Provide both descriptions
+
+---
+
+## 5. Tutorial Pages
+
+### Detection Criteria
+
+**Look for:**
+- "Build" or "Create" in title
+- Progressive code examples
+- "What you'll build" sections
+- "Prerequisites" with skill requirements
+- Time estimates
+- Step-by-step code progression
+- "Deploy" or "Test" final sections
+
+**Confidence signals:**
+- Code builds from simple to complex
+- Each step adds functionality
+- Testing at milestones
+- Troubleshooting sections
+- Learning objectives stated
+- Complete working example
+
+**Example titles:**
+- "Build a URL Shortener"
+- "Create a Blog with Pages"
+- "Tutorial: Image Resizing API"
+
+### Required Elements Checklist
+
+- [ ] "What you'll build" with specific example
+- [ ] "Who this is for" with prerequisites
+- [ ] Time estimate
+- [ ] "What you'll learn" (key concepts)
+- [ ] Step 1: Minimal working version
+- [ ] Progressive enhancement (add features incrementally)
+- [ ] Code block explanations ("What this does")
+- [ ] Testing at each major step
+- [ ] Troubleshooting section
+- [ ] Optional enhancements (clearly marked)
+
+### Simplification Pattern (Conservative)
+
+**Target: 1.5-2x original length**
+
+**For tutorials, focus on enhancing existing steps, not restructuring:**
+
+**Minimal additions to existing tutorial:**
+1. **Add 2-3 sentence goal** at top (if missing) - what they'll build
+2. **Add inline code explanations** - Brief comments within code blocks
+3. **Add 1 example** showing typical usage scenario (5-10 lines)
+4. **Add brief testing** - 3-5 commands with expected output
+5. **Add minimal troubleshooting** - 1-2 critical issues only
+
+**DO NOT add if already present:**
+- "What you'll build" section (enhance existing instead)
+- Progressive steps (keep original structure)
+- Code examples (enhance with comments, don't replace)
+
+**Example enhancement:**
+
+Original tutorial step (20 lines):
+```markdown
+## Step 1: Create the zone
+
+Use the API to create an internal zone.
+
+\`\`\`bash
+curl -X POST https://api.cloudflare.com/zones \\
+ -d '{"name": "company.internal", "type": "internal"}'
+\`\`\`
+
+## Step 2: Add DNS records
+
+Add records to the zone.
+
+\`\`\`bash
+curl -X POST https://api.cloudflare.com/zones/ID/dns_records \\
+ -d '{"type": "A", "name": "app", "content": "192.168.1.100"}'
+\`\`\`
+```
+
+Enhanced (35 lines - 1.75x):
+```markdown
+## Step 1: Create the zone
+
+Create an internal zone that will contain your DNS records. This zone is only
+accessible via Gateway (not public DNS).
+
+\`\`\`bash
+curl -X POST https://api.cloudflare.com/zones \\
+ -d '{
+ "name": "company.internal", # Your internal domain
+ "type": "internal" # Marks as internal-only
+ }'
+\`\`\`
+
+**Example use:** A company creates company.internal for all internal apps
+(app.company.internal, api.company.internal, db.company.internal).
+
+## Step 2: Add DNS records
+
+Add records mapping hostnames to private IPs.
+
+\`\`\`bash
+curl -X POST https://api.cloudflare.com/zones/ZONE_ID/dns_records \\
+ -d '{
+ "type": "A", # Address record
+ "name": "app.company.internal", # Full hostname
+ "content": "192.168.1.100" # Private IP
+ }'
+\`\`\`
+
+**Test:**
+\`\`\`bash
+nslookup app.company.internal
+# Expected: Returns 192.168.1.100
+\`\`\`
+
+**If it doesn't resolve:** Device must use Gateway as DNS resolver. Check WARP
+connection or DNS settings.
+```
+
+What was added:
+- Brief "why" for each step (1 sentence)
+- Inline code comments (3-4 comments)
+- 1 example showing usage (2 lines)
+- Brief testing (3 lines)
+- 1 troubleshooting note (2 lines)
+- Total: 15 lines added to 20 original = 35 lines (1.75x) ✅
+
+**What was NOT added:**
+- Separate "What you'll build" section
+- Multiple examples
+- Comprehensive troubleshooting section
+- Extensive testing procedures
+
+### Common Issues to Fix (Conservative Approach)
+
+- **Code without explanation** → Add inline comments (2-4 per block)
+- **No goal stated** → Add 2-3 sentence goal at top
+- **Missing testing** → Add 3-5 line verification (not separate section)
+- **Zero troubleshooting** → Add 1-2 critical issues inline with steps
+- **No examples** → Add 1 realistic example inline (5-10 lines total)
+
+---
+
+## Detection Decision Tree
+
+```
+1. Does it have numbered procedural steps?
+ YES → Likely HOW TO
+ NO → Continue
+
+2. Does it explain "what" and "why" conceptually?
+ YES → Likely CONCEPT
+ NO → Continue
+
+3. Does it have tables/specs/parameters?
+ YES → Likely REFERENCE
+ NO → Continue
+
+4. Does it build something progressively with code?
+ YES → Likely TUTORIAL
+ NO → Likely OVERVIEW
+
+5. Validation questions:
+ - Multiple features described? → OVERVIEW
+ - Explains mechanisms? → CONCEPT
+ - Action-oriented title? → HOW TO
+ - Technical specifications? → REFERENCE
+ - Complete project? → TUTORIAL
+```
+
+---
+
+## Mixed Content Types
+
+Sometimes documentation combines types:
+
+### Overview + How To
+**Pattern:** Product intro followed by quick start steps
+**Approach:** Treat first section as Overview, steps as How To
+**Example:** "Workers Overview" with "Deploy Your First Worker" steps
+
+### Concept + Reference
+**Pattern:** Conceptual explanation followed by parameter reference
+**Approach:** Layer explanation first, reference at bottom
+**Example:** "Understanding Caching" + "Cache Headers Reference"
+
+### Tutorial + Reference
+**Pattern:** Build project + API reference at end
+**Approach:** Keep tutorial progressive, move reference to appendix
+**Example:** "Build URL Shortener" + "Workers API Reference"
+
+**Detection strategy:** Identify the primary purpose (first 50% of content), treat remainder as supporting material with appropriate pattern.
+
+---
+
+## Quick Reference Cards
+
+### Overview Page Card
+```
+✓ Opens with benefit statement
+✓ Problem/Solution structure
+✓ "Perfect for" section
+✓ CTA link prominent
+✓ Technical details at bottom
+```
+
+### Concept Page Card
+```
+✓ Analogy in first paragraph
+✓ Plain definition
+✓ "Why it matters"
+✓ Real use cases (3-5)
+✓ Technical section separated
+```
+
+### How To Page Card
+```
+✓ Context before steps
+✓ Prerequisites listed
+✓ Dashboard path
+✓ API path (collapsible)
+✓ Verification section
+```
+
+### Reference Page Card
+```
+✓ Opening context
+✓ Use-case organized
+✓ Plain + technical descriptions
+✓ Examples for each item
+✓ Decision guidance
+```
+
+### Tutorial Page Card
+```
+✓ "What you'll build"
+✓ Prerequisites + time
+✓ Minimal first step
+✓ Progressive complexity
+✓ Every code block explained
+✓ Troubleshooting included
+```
+
+---
+
+**Document Version:** 1.0
+**Last Updated:** February 2026
+**License:** MIT
diff --git a/.agents/skills/eli5/references/pattern-library.md b/.agents/skills/eli5/references/pattern-library.md
new file mode 100644
index 000000000000000..3d7b91b310a8918
--- /dev/null
+++ b/.agents/skills/eli5/references/pattern-library.md
@@ -0,0 +1,634 @@
+# ELI5 Pattern Library
+
+A reference collection of reusable before/after patterns for simplifying technical documentation.
+
+---
+
+## Purpose
+
+This library provides:
+- **Reusable patterns** for common simplification scenarios
+- **Jargon → Plain English** translations
+- **Before/after examples** demonstrating transformations
+- **Quick reference** for writers and AI agents
+
+---
+
+## CRITICAL: Conservative Enhancement Pattern
+
+**All patterns below demonstrate minimal, integrated enhancements (1.5-2x growth)**
+
+When applying these patterns:
+- ✅ Add inline, not as separate major sections
+- ✅ Integrate with existing content flow
+- ✅ Keep examples brief (5-15 lines each, max 1-2 examples)
+- ✅ Preserve original structure
+- ❌ Don't create extensive new sections
+- ❌ Don't annotate diagrams
+- ❌ Don't add multiple examples (1-2 max)
+
+**Pattern interpretation guide:**
+
+When a pattern shows "Add [section]" → Interpret as "add brief inline content" not "create major new section"
+
+**Example:**
+- Pattern says: "Add use case example"
+- **Correct:** Add 5-10 line example inline with concept
+- **Incorrect:** Create separate "Use Case Examples" section with 4 detailed scenarios
+
+**Target:** Original + minimal helpful context = 1.5-2x length
+
+---
+
+## Jargon → Plain English Dictionary
+
+Common technical terms and their accessible alternatives:
+
+| Technical Term | Plain English | Context Example |
+|----------------|---------------|-----------------|
+| **Implement** | Set up, turn on, use | "Set up two-factor authentication" not "Implement 2FA" |
+| **Utilize** | Use | "Use the API" not "Utilize the API" |
+| **Leverage** | Use, take advantage of | "Take advantage of caching" not "Leverage caching capabilities" |
+| **Execute** | Run | "Run the command" not "Execute the command" |
+| **Instantiate** | Create | "Create a new Worker" not "Instantiate a Worker" |
+| **Terminate** | Stop, end | "Stop the process" not "Terminate the process" |
+| **Subsequently** | Then, next | "Then, configure the settings" not "Subsequently, configure" |
+| **Optimal** | Best | "Best performance" not "Optimal performance" |
+| **Facilitate** | Help, enable | "This helps you deploy faster" not "Facilitates rapid deployment" |
+| **Invoke** | Call, trigger | "Call the function" not "Invoke the function" |
+| **Provision** | Set up, create | "Set up your server" not "Provision infrastructure" |
+| **Egress** | Outgoing data | "Data leaving your network" not "Egress traffic" |
+| **Ingress** | Incoming data | "Data entering your network" not "Ingress traffic" |
+| **Anycast** | Routing to nearest server | "Automatically routes to the nearest location" not "Anycast routing" |
+| **Propagation** | Spreading, updating | "Changes spread globally" not "Configuration propagates" |
+
+---
+
+## Pattern 0: Conservative Inline Enhancement (NEW - Use This Pattern)
+
+**This pattern demonstrates the CORRECT minimal enhancement approach**
+
+### Example: Internal DNS Documentation
+
+**Before (Original - 15 lines):**
+```markdown
+# Internal DNS
+
+Manage DNS records for your private network.
+
+Internal DNS zones pair with Gateway resolver policies.
+
+## Create a Zone
+
+Use the dashboard or API to create an internal zone.
+
+### Dashboard
+1. Navigate to Internal DNS
+2. Click Create Zone
+3. Enter zone name
+4. Click Save
+```
+
+**After (Enhanced - 26 lines, 1.73x growth):**
+```markdown
+# Internal DNS
+
+Manage DNS records for your private network without running your own DNS
+servers. This simplifies operations and integrates with Cloudflare Gateway.
+
+Internal DNS zones pair with Gateway resolver policies to control DNS
+responses based on source IP, user identity, or domain.
+
+**Example use case:** A multi-region company creates views for London and SF.
+Users query api.company.internal but get different IPs based on location
+(London users → 10.0.1.100, SF users → 10.0.2.100).
+
+## Create a Zone
+
+Create an internal zone that will contain your DNS records. Zones are only
+accessible via Gateway (not public DNS).
+
+### Dashboard
+1. Navigate to Internal DNS → Zones
+2. Click **Create Zone**
+3. Enter zone name (e.g., company.internal)
+4. Click **Save** - Zone receives unique ID
+
+**Verify:** Zone appears in zone list with type "internal"
+```
+
+**What was added:**
+- 1 sentence explaining "why" (without running own servers) - 1 line
+- Brief context for resolver policies (source IP, user identity) - 1 line
+- 1 concrete example (3 lines)
+- Brief zone explanation (2 lines)
+- Inline step context (1 line each for 2 steps) - 2 lines
+- Brief verification (1 line)
+- **Total added: 11 lines to 15 original = 26 lines (1.73x)** ✅
+
+**What was NOT added:**
+- No "What Problem Does Internal DNS Solve?" section
+- No "How It Works (Conceptual)" section before content
+- No diagram annotations
+- No extensive troubleshooting
+- No comprehensive testing section
+- No "Best Practices" section
+- No separate "Understanding Zones" section
+
+**Why this works:**
+- Preserves original structure completely
+- Adds context inline where readers need it
+- Provides 1 concrete example for grounding
+- Brief verification helps readers confirm success
+- Stays focused and scannable
+
+**Use this pattern as your template for all enhancements**
+
+---
+
+## Pattern 1: Technical-First → Benefit-First
+
+### Overview Pages
+
+**Before (Technical-first):**
+```markdown
+## Product X
+
+Product X is a distributed edge computing platform utilizing V8 isolates
+for low-latency serverless code execution with sub-millisecond cold start
+performance and global anycast deployment.
+```
+
+**After (Benefit-first):**
+```markdown
+## Product X
+
+Run code worldwide without managing servers. Deploy in seconds, scale
+automatically, and pay only for what you use.
+
+**What problem it solves:** Maintaining global infrastructure is expensive
+and complex. Product X runs your code in 300+ cities automatically.
+
+**Perfect for:**
+- Applications needing fast global performance
+- Teams wanting to skip server management
+- Projects with variable traffic
+
+[Get started →]
+```
+
+**Why this works:**
+- Opens with clear user value
+- Problem framing creates relevance
+- "Perfect for" helps self-identification
+- Technical details separated
+
+---
+
+## Pattern 2: Abstract Concept → Concrete Analogy
+
+### Concept Pages
+
+**Before (Abstract):**
+```markdown
+## Caching
+
+Caching stores frequently accessed data in high-speed storage layers to
+reduce origin server load and improve response times through data locality
+optimization.
+```
+
+**After (Concrete):**
+```markdown
+## Caching
+
+**Think of it like:** A library's reserve desk. Popular books stay at the
+front desk for quick access instead of requiring trips to the distant stacks.
+
+**What it is:** Caching keeps copies of your frequently accessed files
+(images, CSS, JavaScript) close to users, so they load instantly instead of
+being fetched from your origin server every time.
+
+**Why it matters:**
+- Pages load 10x faster (50ms vs 500ms)
+- Reduces server costs (fewer origin requests)
+- Handles traffic spikes (serves from cache, not origin)
+
+**When to use:** Any content that doesn't change constantly—images, stylesheets,
+blog posts, product pages.
+```
+
+**Why this works:**
+- Analogy creates immediate mental model
+- Plain language explanation builds understanding
+- Benefits are concrete and measurable
+- Use cases make it actionable
+
+---
+
+## Pattern 3: Steps-Only → Contextual Multi-Path
+
+### How To Pages
+
+**Before (Steps-only):**
+```markdown
+## Enable Feature X
+
+1. Go to Settings
+2. Click Security
+3. Toggle Feature X to On
+4. Save
+```
+
+**After (Contextual multi-path):**
+```markdown
+## Enable Feature X
+
+**What this does:** Protects your site from [specific threat] by [mechanism].
+
+**Time:** ~2 minutes
+**Prerequisites:** Admin access
+
+### Via Dashboard
+
+1. Log into your dashboard at dash.example.com
+2. Select your site from the list
+3. Click **Security** in the left sidebar
+4. Find **Feature X** and toggle it **On**
+5. Click **Save Changes** at the bottom
+
+💡 **Note:** Changes take effect immediately. Check Analytics in 5 minutes
+to see it working.
+
+### Via API
+
+
+Show API example
+
+```bash
+curl -X PATCH "https://api.example.com/v1/settings" \
+ -H "Authorization: Bearer YOUR_TOKEN" \
+ -d '{"feature_x_enabled": true}'
+```
+
+**Response:**
+```json
+{
+ "success": true,
+ "result": {"feature_x_enabled": true}
+}
+```
+
+
+
+## Verify It Worked
+
+1. Visit your site in a new tab
+2. Check browser DevTools → Network tab
+3. Look for [specific indicator]
+4. You should see [expected result]
+```
+
+**Why this works:**
+- Context explains purpose before steps
+- Prerequisites prevent confusion
+- Both UI and API paths serve different users
+- Verification builds confidence
+
+---
+
+## Pattern 4: Alphabetical Specs → Use-Case Organization
+
+### Reference Pages
+
+**Before (Alphabetical):**
+```markdown
+## Headers
+
+**Cache-Control:** Controls caching behavior. Values: public, private, no-cache
+
+**Content-Type:** MIME type. Examples: text/html, application/json
+
+**Expires:** Cache expiration date. Format: HTTP-date
+```
+
+**After (Use-case organized):**
+```markdown
+## Headers by Purpose
+
+### Controlling Cache Behavior
+
+**When to use:** Make your site faster by controlling what gets cached and
+for how long.
+
+#### Long-Term Caching (Static Assets)
+
+**`Cache-Control: public, max-age=31536000`**
+
+**What it does:** Caches content for 1 year
+
+**When to use:** Files that never change, like `logo-v2.png` or
+`style.abc123.css` with version hash in filename
+
+**Example:**
+```http
+Cache-Control: public, max-age=31536000, immutable
+```
+
+**Result:** First visitor downloads. Next year, everyone gets the cached
+version instantly.
+
+---
+
+#### Fresh Content (Blog Posts)
+
+**`Cache-Control: public, max-age=3600`**
+
+**What it does:** Caches for 1 hour
+
+**When to use:** Content that updates occasionally—blog posts, product pages
+
+**Example:**
+```http
+Cache-Control: public, max-age=3600
+```
+
+**Result:** Cached for 1 hour. After that, we check for updates.
+
+---
+
+### Setting Content Type
+
+**When to use:** Tell browsers what type of content they're receiving.
+
+[Continue pattern...]
+```
+
+**Why this works:**
+- Organized by task, not alphabet
+- Plain English + technical specs (two-tier)
+- Real examples with expected results
+- "When to use" provides decision guidance
+
+---
+
+## Pattern 5: Code Dump → Explained Progression
+
+### Tutorial Pages
+
+**Before (Code dump):**
+```markdown
+## Build X
+
+```javascript
+addEventListener('fetch', event => {
+ event.respondWith(handleRequest(event.request))
+})
+
+async function handleRequest(request) {
+ const url = new URL(request.url)
+ return new Response('Hello')
+}
+```
+```
+
+**After (Explained progression):**
+```markdown
+## Build X
+
+### What You'll Build
+
+A working [specific thing] that [specific capability].
+
+**Example:** `short.example.com/abc` → `github.com/cloudflare`
+
+### Who This Is For
+
+Developers comfortable with JavaScript. No prior experience needed with
+[platform], but you should understand HTTP requests and JSON.
+
+### Time: 30 minutes
+
+---
+
+## Step 1: Minimal Working Version
+
+Let's start with the absolute minimum—proof the concept works:
+
+```javascript
+// Entry point: listens for incoming HTTP requests
+addEventListener('fetch', event => {
+ // Send request to our handler function
+ event.respondWith(handleRequest(event.request))
+})
+
+// Handler: processes each request
+async function handleRequest(request) {
+ return new Response('Hello! It works!', {
+ headers: { 'content-type': 'text/plain' }
+ })
+}
+```
+
+**What this code does:**
+- **Line 2:** Listens for HTTP requests to your Worker
+- **Line 4:** Calls `handleRequest` to process each request
+- **Line 8-12:** Returns a simple text response
+
+**Test it:**
+1. Deploy this code
+2. Visit your Worker's URL
+3. You should see: "Hello! It works!"
+
+Great! Your Worker is running. Now let's add real functionality...
+
+## Step 2: Parse URLs
+
+[Continue building progressively with explanations...]
+```
+
+**Why this works:**
+- Sets clear expectations upfront
+- Explains every code block
+- Builds progressively (minimal → full)
+- Includes testing at each step
+
+---
+
+## Common Transformations
+
+### Transform 1: Feature List → Problem/Solution
+
+**Before:**
+```markdown
+Features:
+- Global anycast network
+- Automatic scaling
+- Pay-per-request pricing
+```
+
+**After:**
+```markdown
+**What you get:**
+- **Fast everywhere:** Code runs in 300+ cities, close to every user
+- **Auto-scaling:** Handles 10 requests or 10 million without configuration
+- **Cost-efficient:** Pay only when code runs, not for idle servers
+```
+
+### Transform 2: Jargon Explanation → Layered Understanding
+
+**Before:**
+```markdown
+DDoS mitigation employs anycast architecture to distribute volumetric attacks
+across our edge network, utilizing L3/L4 packet inspection and L7 behavioral
+analysis.
+```
+
+**After:**
+```markdown
+**In plain language:** Stops attackers from overwhelming your site with fake traffic.
+
+**How it protects you:** We have 300+ data centers. When an attack hits, we
+spread it across all locations—like opening thousands of doors instead of one.
+We also identify and block fake visitors before they reach your site.
+
+**What happens:** Your real visitors get through normally while attack traffic
+is filtered out automatically.
+
+
+For technical users
+
+Anycast distributes L3/L4 volumetric attacks across the network. L7 protection
+uses JS challenges and behavioral fingerprinting. [Architecture details →]
+
+
+```
+
+### Transform 3: Assumed Knowledge → Explicit Prerequisites
+
+**Before:**
+```markdown
+Configure your A record to point to the anycast IP.
+```
+
+**After:**
+```markdown
+Update your DNS A record to point to Cloudflare's IP address.
+
+**What's an A record?** It's the DNS entry that tells the internet where your
+website lives (like an address in a phone book).
+
+**Where to find it:** In your domain registrar's DNS settings (GoDaddy, Namecheap,
+etc.). Look for "DNS Management" or "DNS Settings."
+
+**What to enter:**
+- Type: A
+- Name: @ (means your root domain)
+- Value: 192.0.2.1 (our IP address)
+```
+
+---
+
+## Metaphor Templates
+
+### Template: API Explanation
+```markdown
+**Think of it like:** [Familiar interface concept]
+
+An API is like a restaurant menu. It shows you:
+- What's available to order (endpoints)
+- What details you need to provide (parameters: "no onions, extra cheese")
+- What you'll get back (response: your meal)
+- Pricing (rate limits, quotas)
+
+You don't need to know how the kitchen works. Just order from the menu.
+
+**Where this breaks down:** Unlike restaurants where you wait, API responses
+are usually instant. Also, APIs can return errors if your "order" is invalid.
+```
+
+### Template: Security Feature Explanation
+```markdown
+**The threat:** [What attackers do]
+
+Attackers try to [specific attack method] which could [consequence] to your site.
+
+**How [Feature] protects you:** [Protection mechanism in plain language]
+
+Think of it like [security analogy]:
+[Concrete comparison that shows the protection model]
+
+**What happens automatically:**
+- [Protection 1]
+- [Protection 2]
+
+**What you control:**
+- [Setting 1]
+- [Setting 2]
+```
+
+### Template: Infrastructure Concept
+```markdown
+**What it is:** [One-sentence plain English definition]
+
+**Real-world comparison:**
+[Physical/familiar tech analog that maps 1:1 to key concepts]
+
+**Why it matters:**
+- [Benefit 1 with measurable impact]
+- [Benefit 2 with measurable impact]
+
+**Common use case:**
+[Specific realistic scenario showing it in action]
+
+**Technical details:** [In collapsible section or bottom]
+```
+
+---
+
+## Quick Patterns Reference
+
+### When You See → Do This
+
+| **Original** | **Transform To** |
+|--------------|------------------|
+| Technical architecture first | Problem → Solution → Benefit |
+| Abstract concept | Analogy → Plain explanation → Technical |
+| Steps without context | Context → Prerequisites → Multi-path steps |
+| Alphabetical reference | Use-case groups → Two-tier descriptions |
+| Unexplained code | What you'll build → Progressive steps → Explained blocks |
+| Feature list | Problem/solution pairs with benefits |
+| Jargon without definition | Define inline or use plain alternative |
+| Missing "why" | Add value proposition upfront |
+| No use cases | Add 3-5 realistic scenarios |
+| Assumes knowledge | State prerequisites explicitly |
+
+---
+
+## Best Practices Summary
+
+### Do:
+✅ Lead with benefits and problems solved
+✅ Use tech-adjacent metaphors with stated limitations
+✅ Provide both Dashboard and API paths
+✅ Organize by use case, not alphabetically
+✅ Explain every code block
+✅ State prerequisites before steps
+✅ Include verification/testing sections
+✅ Add "For technical users" collapsible sections
+
+### Don't:
+❌ Start with technical architecture
+❌ Use condescending language ("simply," "just," "obviously")
+❌ Assume prior knowledge without stating it
+❌ Provide only one interface path (Dashboard OR API)
+❌ Organize specs alphabetically without context
+❌ Drop code without explanation
+❌ Skip the "why" to get to "how" faster
+❌ Sacrifice accuracy for brevity
+
+---
+
+**Document Version:** 1.0
+**Last Updated:** February 2026
+**License:** MIT