diff --git a/.agents/discover-skills b/.agents/discover-skills
new file mode 100755
index 0000000..8d865ae
--- /dev/null
+++ b/.agents/discover-skills
@@ -0,0 +1,90 @@
+#!/usr/bin/env bash
+set -Eo pipefail
+IFS=$'\n\t'
+
+# Discover available skills in both project and global directories
+# Usage: .agents/discover-skills
+
+PROJECT_SKILLS_DIR=".skills"
+PROJECT_SKILLS_DIR_LEGACY=".claude/skills"
+GLOBAL_SKILLS_DIR="$HOME/.skills"
+GLOBAL_SKILLS_DIR_LEGACY="$HOME/.claude/skills"
+
+process_skills_directory() {
+  local skills_dir="$1"
+  local location_label="$2"
+
+  if [[ ! -d "$skills_dir" ]]; then
+    return 0
+  fi
+
+  local count=0
+  # Count skills first
+  while IFS= read -r -d '' skill_file; do
+    count=$((count + 1))
+  done < <(find "$skills_dir" -type f -name 'SKILL.md' -print0)
+
+  if [[ $count -eq 0 ]]; then
+    return 0
+  fi
+
+  echo "$location_label ($count skill(s)):"
+  # Generate underline matching label length
+  local len=${#location_label}
+  if [[ $len -gt 0 ]]; then
+    local underline=""
+    for ((i=0; i<len; i++)); do
+      underline+="="
+    done
+    echo "$underline"
+  fi
+  echo ""
+
+  # Iterate SKILL.md files robustly (handles spaces)
+  while IFS= read -r -d '' skill_file; do
+    skill_dir=$(dirname "$skill_file")
+    skill_name=$(basename "$skill_dir")
+
+    # Check for YAML frontmatter
+    if head -n 1 "$skill_file" | grep -q "^---$"; then
+      # Extract lines between first pair of --- delimiters
+      frontmatter=$(awk 'BEGIN{inside=0; c=0} /^---$/ {inside=!inside; if(++c==3) exit} inside==1 {print}' "$skill_file")
+      name=$(printf '%s\n' "$frontmatter" | awk -F': *' '/^name:/ {sub(/^name: */,"",$0); print substr($0, index($0,$2))}' 2>/dev/null)
+      description=$(printf '%s\n' "$frontmatter" | awk -F': *' '/^description:/ {sub(/^description: */,"",$0); print substr($0, index($0,$2))}' 2>/dev/null)
+
+      echo "Skill: ${name:-$skill_name}"
+      echo "Path: $skill_file"
+      if [[ -n "$description" ]]; then
+        echo "Description: $description"
+      fi
+    else
+      echo "Skill: $skill_name"
+      echo "Path: $skill_file"
+      echo "Description:"
+      head -n 5 "$skill_file"
+    fi
+
+    echo ""
+    echo "---"
+    echo ""
+  done < <(find "$skills_dir" -type f -name 'SKILL.md' -print0)
+}
+
+echo "Available Skills:"
+echo "=================="
+echo ""
+
+# Check project skills (new location first, then legacy)
+process_skills_directory "$PROJECT_SKILLS_DIR" "Project Skills (.skills)"
+process_skills_directory "$PROJECT_SKILLS_DIR_LEGACY" "Project Skills (.claude/skills - legacy)"
+
+# Check global skills (new location first, then legacy)
+process_skills_directory "$GLOBAL_SKILLS_DIR" "Personal Skills (~/.skills)"
+process_skills_directory "$GLOBAL_SKILLS_DIR_LEGACY" "Personal Skills (~/.claude/skills - legacy)"
+
+# If no skills found at all
+if [[ ! -d "$PROJECT_SKILLS_DIR" && ! -d "$PROJECT_SKILLS_DIR_LEGACY" && ! -d "$GLOBAL_SKILLS_DIR" && ! -d "$GLOBAL_SKILLS_DIR_LEGACY" ]]; then
+  echo "No skills directories found."
+  echo "- Project skills: $PROJECT_SKILLS_DIR (or $PROJECT_SKILLS_DIR_LEGACY)"
+  echo "- Personal skills: $GLOBAL_SKILLS_DIR (or $GLOBAL_SKILLS_DIR_LEGACY)"
+fi
diff --git a/.claude/.skills/authoring-analysis/SKILL.md b/.claude/.skills/authoring-analysis/SKILL.md
new file mode 100644
index 0000000..31ab51b
--- /dev/null
+++ b/.claude/.skills/authoring-analysis/SKILL.md
@@ -0,0 +1,375 @@
+---
+name: authoring-analysis
+description: Analyze content sequences and determine authoring approach (default content vs blocks). Validates block selection and section styling for import/migration to AEM Edge Delivery Services.
+---
+
+# Authoring Analysis
+
+Determine authoring approach for EACH content sequence: default content or specific block.
+
+## When to Use This Skill
+
+Use this skill when:
+- You have page structure with content sequences (from identify-page-structure)
+- You have block inventory (local + Block Collection)
+- Ready to make authoring decisions following David's Model
+
+**Invoked by:** page-import skill (Step 3)
+
+## Prerequisites
+
+From identify-page-structure skill, you need:
+- ✅ Section boundaries with styling notes
+- ✅ Content sequences per section (neutral descriptions)
+- ✅ Block inventory (local + Block Collection with purposes)
+- ✅ screenshot.png for visual reference
+
+## Related Skills
+
+- **page-import** - Orchestrator that invokes this skill
+- **identify-page-structure** - Provides section structure and block inventory
+- **content-modeling** - This skill invokes it when block selection is unclear
+- **block-collection-and-party** - This skill invokes it to validate blocks
+- **generate-import-html** - Uses this skill's output to create HTML
+
+## **IMPORTANT: Step 3e Execution Trigger**
+
+After completing Step 3 (analyzing all sequences), you MUST execute Step 3e if:
+- ✅ At least one section contains exactly ONE sequence that became a block
+- ✅ That section has distinct background styling from identify-page-structure
+
+If NO sections meet these criteria → Skip Step 3e
+If ANY sections meet these criteria → Execute Step 3e for EACH qualifying section
+
+## Authoring Analysis Workflow
+
+**Context:** You now have:
+- Section boundaries with styles
+- Content sequences per section
+- Available block palette
+
+**FOR EACH content sequence, follow this mandatory process:**
+
+---
+
+### Step 3a: MANDATORY - Default Content Check (FIRST!)
+
+**Question:** "Can an author create this with normal typing in Word/Google Docs?"
+
+**Default content means:**
+- ✅ Headings, paragraphs, lists
+- ✅ Inline images within text
+- ✅ Simple quotes
+- ✅ Just... typing content
+
+**NOT default content means:**
+- ❌ Repeating structured patterns (card grids, feature lists)
+- ❌ Interactive components (accordions, tabs, carousels)
+- ❌ Complex layouts (side-by-side columns, split content)
+- ❌ Requires specific structure for decoration
+
+**Decision:**
+- If YES (can type normally) → **Mark as DEFAULT CONTENT, DONE** ✅
+- If NO (needs structure) → **Proceed to Step 3b**
+
+**Examples:**
+```
+"Large centered heading, paragraph, two buttons"
+→ Can author just type heading, paragraph, links? YES
+→ Decision: DEFAULT CONTENT ✅
+
+"Two centered buttons"
+→ Can author just type two links? YES
+→ Decision: DEFAULT CONTENT ✅
+
+"Four items in grid, each with image, heading, description"
+→ Can author just type this? NO - requires grid structure
+→ Decision: Proceed to Step 3b ➡️
+
+"Expandable questions and answers"
+→ Can author just type this? NO - requires interaction/decoration
+→ Decision: Proceed to Step 3b ➡️
+```
+
+---
+
+### Step 3b: Block Selection (ONLY IF NOT DEFAULT)
+
+**With block inventory context, ask:** "Which available block would an author choose for this?"
+
+**DECISION TREE: When to Invoke content-modeling**
+
+**OBVIOUS MATCH (Don't invoke content-modeling):**
+
+Pattern matches block purpose 1:1:
+- "Grid of items with images/text" + see "cards" block → USE IT ✅
+- "Expandable questions" + see "accordion" block → USE IT ✅
+- "Tabbed content panels" + see "tabs" block → USE IT ✅
+- "Side-by-side content" + see "columns" block → USE IT ✅
+- "Rotating images" + see "carousel" block → USE IT ✅
+
+**Criteria for OBVIOUS:**
+- Content description matches block purpose exactly
+- No ambiguity about structure
+- Block exists in inventory
+
+**UNCLEAR MATCH (Invoke content-modeling):**
+
+Ambiguous which block to use:
+- "Three items with images" - Could be cards? Could be columns? → INVOKE
+- "List of features with icons" - Cards? Custom list block? → INVOKE
+- "Customer quotes with photos" - Quote block? Cards? Testimonial block? → INVOKE
+
+Missing from inventory:
+- Content needs structure BUT no matching block exists → INVOKE
+- content-modeling can recommend canonical model or suggest creating custom block
+
+Complex authoring consideration:
+- "Hero-like content but in middle of page" → INVOKE
+- "Card-like items but only 2 of them" → INVOKE
+- Need validation on author mental model → INVOKE
+
+**Criteria for UNCLEAR:**
+- Multiple blocks could work
+- No obvious block match
+- Need authoring perspective validation
+- Creating custom block might be needed
+
+---
+
+### Step 3c: Validate Block Exists (IF NEEDED)
+
+**Only if block not in Block Collection common set:**
+
+Invoke **block-collection-and-party** skill to:
+- Confirm block exists
+- Get live example URL
+- Review content model
+
+---
+
+### Step 3d: Get Block HTML Structure (BEFORE generating HTML)
+
+**CRITICAL:** Before generating any HTML in next skill, fetch the pre-decoration HTML structure for ALL blocks you'll use.
+
+```bash
+# Get structure examples for each block
+node .claude/skills/block-collection-and-party/scripts/get-block-structure.js cards
+node .claude/skills/block-collection-and-party/scripts/get-block-structure.js tabs
+node .claude/skills/block-collection-and-party/scripts/get-block-structure.js accordion
+node .claude/skills/block-collection-and-party/scripts/get-block-structure.js columns
+```
+
+**Why this prevents mistakes:**
+- Shows exact row/column structure (e.g., cards: each card = 1 row with 2 columns)
+- Reveals all variants (e.g., "Cards" vs "Cards (no images)")
+- Displays clean HTML without decoration
+- Prevents the #1 HTML generation error: wrong structure
+
+**Use the output to:**
+1. Understand how many columns each row should have
+2. See where images vs content go
+3. Match your content to the correct variant
+4. Generate HTML that matches the expected structure exactly
+
+---
+
+### Step 3 Output Format
+
+**Complete analysis for all sequences:**
+
+```
+Section 1 (light):
+  - Sequence 1: "Large centered heading, paragraph, two call-to-action buttons"
+    → Decision: DEFAULT CONTENT
+    → Reason: Author can type heading, paragraph, links normally
+    → Note: Prominent styling is a CSS concern
+
+  - Sequence 2: "Two images side-by-side"
+    → Decision: Columns block (2 columns)
+    → Reason: Side-by-side layout requires structure
+    → Obvious match with "columns" block in inventory
+
+Section 2 (light):
+  - Sequence 1: "Centered heading"
+    → Decision: DEFAULT CONTENT
+    → Reason: Just a heading - author types it
+
+  - Sequence 2: "Grid of 8 items, each with icon and short text"
+    → Decision: Cards block
+    → Reason: Repeating structured pattern, needs block
+    → Obvious match with "cards" block in inventory
+
+  - Sequence 3: "Two centered buttons"
+    → Decision: DEFAULT CONTENT
+    → Reason: Just two links - author types them
+
+Section 3 (grey):
+  - Sequence 1: "Eyebrow text, heading, paragraph, button stacked vertically"
+    → Decision: DEFAULT CONTENT
+    → Reason: Author types text and link normally
+
+  - Sequence 2: "Four items in grid, each with image, category tag, heading, description"
+    → Decision: Cards block
+    → Reason: Repeating structured pattern
+    → Obvious match with "cards" block in inventory
+
+Section 4 (dark):
+  - Sequence 1: "Tab navigation with three switchable content panels"
+    → Decision: Tabs block
+    → Reason: Interactive component, needs decoration
+    → Obvious match with "tabs" block in inventory
+```
+
+---
+
+### Step 3e: Validate Section Styling (Single-Block Sections Only)
+
+**⚠️ EXECUTION TRIGGER:** This step is executed AFTER Step 3 is complete. Execute this step if and only if:
+- ✅ You have completed Step 3 (identified which sequences become blocks)
+- ✅ At least one section contains exactly ONE sequence that became a block
+- ✅ That section has distinct background styling from identify-page-structure
+
+**If NO sections meet these criteria → Skip Step 3e entirely and proceed to next skill**
+
+**If ANY sections meet these criteria → You MUST execute all sub-steps below for EACH qualifying section**
+
+---
+
+**Why this validation matters:**
+
+When a section contains a single block, the background styling might be:
+- **Block-specific design** (e.g., hero with dark background image) → Don't add section-metadata
+- **Section container styling** (e.g., dark section with tabs block) → Add section-metadata
+
+Without validation, we risk adding unnecessary section-metadata that conflicts with block styling or makes authoring more complex.
+
+**Sections with multiple sequences:** Always keep section-metadata (styling applies to all content, not validated in Step 3e)
+
+---
+
+**For EACH section with exactly one block, execute ALL these sub-steps:**
+
+**Sub-step 1: Identify the candidate sections**
+
+Review your Step 3 output. Find sections where:
+- Section contains exactly 1 content sequence
+- That sequence became a block (not default content)
+- Section has distinct background styling from identify-page-structure
+
+**Example:**
+```
+Section 1 (dark blue):
+  - Sequence 1: Large centered heading, paragraph, two buttons
+    → Decision: Hero block
+
+Section 3 (grey):
+  - Sequence 1: Tab navigation with three switchable panels
+    → Decision: Tabs block
+```
+
+---
+
+**Sub-step 2: For each candidate section, examine the screenshot**
+
+Open screenshot.png and examine the section visually.
+
+**Ask these questions:**
+
+**Q1: Is the background an image (photo, gradient, illustration)?**
+- If YES → Likely block-specific design
+- If NO (solid color) → Continue to Q2
+
+**Q2: Does the content fill the colored area edge-to-edge, or is there visible section padding?**
+- Edge-to-edge (full-bleed) → Likely block-specific design
+- Visible padding around content → Likely section container styling
+
+**Q3: Does the block type typically have its own background styling?**
+- Hero, banner, full-width CTAs → Often have own backgrounds
+- Tabs, accordion, cards, columns → Often use section backgrounds
+
+---
+
+**Sub-step 3: Make the decision**
+
+Based on your analysis, decide for each single-block section:
+
+**SKIP section-metadata if:**
+- Background is an image/gradient (block-specific)
+- Content is full-bleed/edge-to-edge (no section padding visible)
+- Block type typically has intrinsic background (hero, banner)
+
+**KEEP section-metadata if:**
+- Background is solid color with visible section padding
+- Block type typically inherits section styling (tabs, cards, accordion)
+- Styling clearly provides container context (not block design)
+
+---
+
+**Sub-step 4: Document your decisions**
+
+For each validated section, note:
+- Section number
+- Block type
+- Background analysis (image vs solid, full-bleed vs padded)
+- Decision (keep or skip section-metadata)
+- Reason
+
+**Example output:**
+```
+VALIDATED SECTIONS:
+
+Section 1 (dark blue):
+  - Block: Hero
+  - Background: Full-width dark blue gradient image
+  - Layout: Edge-to-edge, no visible section padding
+  - Decision: SKIP section-metadata
+  - Reason: Background is hero's design, not section styling
+
+Section 3 (grey):
+  - Block: Tabs
+  - Background: Solid grey (#f5f5f5)
+  - Layout: Content centered with visible padding (~80px on sides)
+  - Decision: KEEP section-metadata style="grey"
+  - Reason: Section provides container styling for tabs block
+```
+
+---
+
+**When in doubt:**
+
+If you're uncertain whether background is block-specific or section-wide:
+- **Default to KEEPING section-metadata** (safer, easier for authors to remove than add)
+- **Add a note** in your documentation explaining the ambiguity
+- Consider asking the user for guidance
+
+---
+
+**Step 3e Completion Checklist:**
+
+Before proceeding to next skill, verify you have completed:
+- ✅ Identified all single-block sections with background styling
+- ✅ Examined original screenshot for EACH candidate section
+- ✅ Answered Q1, Q2, Q3 for EACH candidate section
+- ✅ Made skip/keep decision for EACH candidate section
+- ✅ Documented reasoning for EACH decision
+- ✅ Updated section styling notes with validated decisions
+
+---
+
+## Final Output
+
+This skill provides complete authoring analysis:
+
+**1. Authoring decisions for all sequences:**
+- Each sequence marked as DEFAULT CONTENT or specific block name
+- Reasoning documented
+
+**2. Block structures fetched:**
+- HTML structure examples for all blocks to be used
+
+**3. Section styling validation (if applicable):**
+- Updated section list with validated styling decisions
+- Some sections may be marked "no section-metadata"
+
+**Next step:** Pass these outputs to generate-import-html skill
diff --git a/.claude/.skills/block-collection-and-party/SKILL.md b/.claude/.skills/block-collection-and-party/SKILL.md
new file mode 100644
index 0000000..0615d31
--- /dev/null
+++ b/.claude/.skills/block-collection-and-party/SKILL.md
@@ -0,0 +1,453 @@
+---
+name: Using the Block Collection and Block Party
+description: The Block Collection and Block Party are repositories for existing AEM blocks, build tools, code snippets, integration patterns, plugins, and more. Use this skill anytime you are developing something and want to find a reference to use as a starting point.
+---
+
+# Using the Block Collection and Block Party
+
+## Overview
+
+This skill helps you find reference implementations, code examples, and patterns from two key AEM Edge Delivery resources:
+
+- **Block Collection**: Adobe-maintained reference blocks following best practices
+- **Block Party**: Community-driven repository of blocks, plugins, tools, and integrations
+
+Use the provided search scripts to discover relevant examples, then review the code to inform your implementation approach.
+
+## When to Use This Skill
+
+Use this skill when:
+- Building a new block and want to see if similar implementations exist
+- Looking for code patterns or snippets to solve a specific problem
+- Searching for integration examples (e.g., third-party services, build tools)
+- Need reference implementations for sidekick or Document Authoring plugins
+- Want to understand best practices through working examples
+
+**Do NOT use this skill when:**
+- You need official documentation (use `docs-search` instead)
+- You're making minor CSS tweaks to existing code (just edit directly)
+- You already know exactly which block/example you need (use it directly)
+
+## Related Skills
+
+- **building-blocks**: This skill is called from building-blocks during development
+- **docs-search**: Use for official aem.live documentation
+- **content-driven-development**: Use when creating content models for blocks
+
+## Key Concepts
+
+### Block Collection vs Block Party
+
+**Block Collection** (Prefer this when available)
+- Maintained by Adobe
+- Vetted for best practices
+- Excellent content modeling
+- High performance and accessibility standards
+- Limited to commonly-needed blocks
+- Documentation: https://www.aem.live/developer/block-collection
+- Repository: https://github.com/adobe/aem-block-collection
+- Live site: https://main--aem-block-collection--adobe.aem.live
+
+**Block Party** (Use for specialized needs)
+- Community-driven contributions
+- Broader variety of content types
+- Includes experimental/innovative approaches
+- Only approved entries are returned by the search script
+- Contains blocks, plugins, build tools, integrations, and more
+- Documentation: https://www.aem.live/developer/block-party/
+- Search index: https://www.aem.live/developer/block-party/block-party.json?sheet=curated-list-new
+
+**When to prefer which:**
+- Start with Block Collection for standard blocks (carousels, accordions, cards, etc.)
+- Use Block Party when Block Collection doesn't have what you need
+- Block Party is the only source for sidekick plugins, build tools, and integrations
+- Sometimes Block Party has innovative approaches worth considering even if Block Collection has a similar block
+
+## How to Use This Skill
+
+### Step 1: Identify Search Terms
+
+Determine what you're looking for and identify relevant search terms. **Think about similar or alternative names** for the functionality.
+
+**Examples:**
+- Looking for FAQ block → search for "faq" AND "accordion" (Block Collection has accordion)
+- Looking for image gallery → search for "gallery", "carousel", "slideshow"
+- Looking for navigation → search for "navigation", "menu", "header"
+- Looking for build tooling → search for "webpack", "vite", "sass", "typescript"
+
+**Good search terms:**
+- Specific functionality names: "carousel", "tabs", "modal"
+- Tool names: "sass", "webpack", "target"
+- Component types: "navigation", "footer", "hero"
+
+**Poor search terms:**
+- Too generic: "content", "page", "website"
+- Too specific: "my-custom-carousel-with-auto-play"
+
+### Step 2: Search Block Collection
+
+**IMPORTANT:** Run BOTH search scripts in parallel for comprehensive results:
+
+```bash
+# Run both searches in parallel (preferred approach)
+node .claude/skills/block-collection-and-party/scripts/search-block-collection-github.js <search-term> & \
+node .claude/skills/block-collection-and-party/scripts/search-block-collection.js <search-term> & \
+wait
+```
+
+**Why use both scripts:**
+- `search-block-collection-github.js` - Searches actual repository folders via GitHub API (most comprehensive)
+- `search-block-collection.js` - Searches navigation page (provides display names and catches edge cases)
+- Running both ensures maximum coverage and catches blocks that might be missed by either approach alone
+
+**Examples:**
+```bash
+# Search for accordion/FAQ blocks (both scripts)
+node .claude/skills/block-collection-and-party/scripts/search-block-collection-github.js accordion & \
+node .claude/skills/block-collection-and-party/scripts/search-block-collection.js accordion & \
+wait
+
+# Search for embed block (both scripts)
+node .claude/skills/block-collection-and-party/scripts/search-block-collection-github.js embed & \
+node .claude/skills/block-collection-and-party/scripts/search-block-collection.js embed & \
+wait
+
+# If running both is problematic, prioritize the GitHub API version
+node .claude/skills/block-collection-and-party/scripts/search-block-collection-github.js carousel
+```
+
+### Step 3: Search Block Party
+
+Execute the Block Party search script from the project root:
+
+```bash
+node .claude/skills/block-collection-and-party/scripts/search-block-party.js [--category <category>] <search-term> [additional-terms...]
+```
+
+**Options:**
+- `--category <category>`: Filter by specific category (Block, Sidekick Plugin, DA Plugin, Code Snippet, Build Tooling, etc.)
+- Without `--category`: Searches all categories
+
+**Examples:**
+```bash
+# Search for breadcrumb blocks
+node .claude/skills/block-collection-and-party/scripts/search-block-party.js breadcrumb
+
+# Search for Sass integration examples
+node .claude/skills/block-collection-and-party/scripts/search-block-party.js sass
+
+# Search only for build tooling
+node .claude/skills/block-collection-and-party/scripts/search-block-party.js --category "Build Tooling" webpack
+
+# Multi-word search
+node .claude/skills/block-collection-and-party/scripts/search-block-party.js adobe target integration
+```
+
+### Step 4: Review Search Results
+
+**Block Collection Results (type: "block"):**
+```json
+{
+  "query": "accordion",
+  "source": "Adobe AEM Block Collection",
+  "totalItems": 26,
+  "matchCount": 1,
+  "results": [
+    {
+      "name": "accordion",
+      "displayName": "Accordion",
+      "type": "block",
+      "liveExampleUrl": "https://main--aem-block-collection--adobe.aem.live/block-collection/accordion",
+      "jsUrl": "https://github.com/adobe/aem-block-collection/blob/main/blocks/accordion/accordion.js",
+      "cssUrl": "https://github.com/adobe/aem-block-collection/blob/main/blocks/accordion/accordion.css"
+    }
+  ]
+}
+```
+
+**Block Collection Results (type: "default-content"):**
+```json
+{
+  "query": "breadcrumb",
+  "source": "Adobe AEM Block Collection",
+  "totalItems": 26,
+  "matchCount": 1,
+  "results": [
+    {
+      "name": "breadcrumbs",
+      "displayName": "Breadcrumbs",
+      "type": "default-content",
+      "liveExampleUrl": "https://main--aem-block-collection--adobe.aem.live/block-collection/breadcrumbs",
+      "note": "This is default content documentation, not a standalone block. Code may be part of other blocks (e.g., breadcrumbs are in the header block). Visit https://www.aem.live/developer/block-collection and the live example URL for implementation guidance.",
+      "documentationUrl": "https://www.aem.live/developer/block-collection"
+    }
+  ]
+}
+```
+
+**Block Party Results:**
+```json
+{
+  "query": "breadcrumb",
+  "category": "All categories",
+  "source": "AEM Block Party (Approved Only)",
+  "totalEntries": 90,
+  "approvedEntries": 62,
+  "matchCount": 1,
+  "results": [
+    {
+      "title": "Breadcrumbs",
+      "category": "Block",
+      "description": "A breadcrumb navigation component...",
+      "githubUrl": "https://github.com/...",
+      "showcaseUrl": "https://...",
+      "githubProfile": "https://github.com/..."
+    }
+  ]
+}
+```
+
+### Step 5: Get Block Structure Examples (CRITICAL for HTML generation)
+
+**IMPORTANT:** Before writing any HTML for a block, ALWAYS fetch the pre-decoration structure examples first.
+
+```bash
+node .claude/skills/block-collection-and-party/scripts/get-block-structure.js <block-name>
+```
+
+**Why this is critical:**
+- Shows the exact HTML structure the block expects BEFORE JavaScript decoration
+- Reveals the row/column pattern (e.g., each card is a row with 2 columns: image | content)
+- Displays multiple variants (e.g., "Cards" vs "Cards (no images)")
+- Prevents HTML structure mistakes that cause blocks to fail decoration
+
+**Examples:**
+```bash
+# Get accordion structure
+node .claude/skills/block-collection-and-party/scripts/get-block-structure.js accordion
+
+# Get cards structure (will show multiple variants)
+node .claude/skills/block-collection-and-party/scripts/get-block-structure.js cards
+
+# Get tabs structure
+node .claude/skills/block-collection-and-party/scripts/get-block-structure.js tabs
+```
+
+**Output includes:**
+- Block description and source code URL
+- All available variants with their names
+- Pre-decoration HTML for each variant (simplified, without image optimization noise)
+- Structural analysis (rows, columns, content types per column)
+
+**When to use:**
+- ✅ Before generating HTML for page migration
+- ✅ Before writing block content in HTML files
+- ✅ When block decoration is failing (verify your HTML matches expected structure)
+- ✅ When uncertain about content model (e.g., "Is each card a row or all cards in one row?")
+
+**This step prevents the most common mistake:** Writing incorrect HTML structure that doesn't match what the block's JavaScript decoration expects.
+
+### Step 6: Examine the Code
+
+Use the provided URLs to review the implementation:
+
+**For Block Collection results with `type: "block"`:**
+1. **FIRST:** Get block structure examples (Step 5) to understand the expected HTML
+2. Read the JS file to understand decoration logic
+3. Read the CSS file to see styling approach
+4. Visit the live example URL to see the block in action
+
+**For Block Collection results with `type: "default-content"`:**
+1. These represent standard HTML elements and patterns (breadcrumbs, buttons, headings, etc.)
+2. Code exists but may be part of other blocks (e.g., breadcrumbs code is in the header block)
+3. Visit the `documentationUrl` (https://www.aem.live/developer/block-collection) to find implementation details
+4. Visit the `liveExampleUrl` to see examples and understand how to author the content
+5. Search the Block Collection repository for related blocks that might contain the implementation
+
+**For Block Party entries:**
+1. Visit the GitHub URL to see the code
+2. Visit the showcase URL to see it in action (if available)
+3. Review the description to understand the purpose and approach
+
+### Step 7: Apply Learnings
+
+Use the reference implementations to inform your approach:
+- Understand the content model used
+- Study decoration patterns and techniques
+- Review CSS architecture and responsive approaches
+- Adapt (don't copy) the code to fit your specific needs
+- Ensure you follow your project's coding standards
+
+## Search Behavior Details
+
+### Block Collection Search
+
+- Searches block folder names in the GitHub repository
+- Returns exact and partial matches (case-insensitive)
+- Provides direct links to JS, CSS, and live examples
+- Fast and reliable (limited to ~16 blocks)
+
+### Block Party Search
+
+- Searches title, description, and category fields
+- Supports category filtering
+- Returns all matching entries (not limited)
+- Shows approval status for each entry
+- Includes diverse content types beyond blocks
+
+## Examples
+
+### Example 1: Building an FAQ Block
+
+**User Request:** "I need to build an FAQ section with expandable questions"
+
+**Good Approach:**
+1. Recognize FAQ often uses accordion pattern
+2. Search Block Collection with both scripts:
+   ```bash
+   node .claude/skills/block-collection-and-party/scripts/search-block-collection-github.js accordion & \
+   node .claude/skills/block-collection-and-party/scripts/search-block-collection.js accordion & \
+   wait
+   ```
+3. Review results from both searches (they should align, but running both ensures nothing is missed)
+4. Find the accordion block with JS, CSS, and live example URLs
+5. Review the implementation approach
+6. Adapt the pattern to your specific FAQ needs
+
+**Why this works:**
+- Used alternative term "accordion" for "FAQ"
+- Started with Block Collection (Adobe best practices)
+- Ran both search scripts for comprehensive coverage
+- Found a vetted, accessible, performant implementation
+
+### Example 2: Finding Breadcrumb Implementation
+
+**User Request:** "Add breadcrumb navigation to the site"
+
+**Good Approach:**
+1. Search Block Collection first with both scripts:
+   ```bash
+   node .claude/skills/block-collection-and-party/scripts/search-block-collection-github.js breadcrumb & \
+   node .claude/skills/block-collection-and-party/scripts/search-block-collection.js breadcrumb & \
+   wait
+   ```
+2. Find that breadcrumbs is "default-content" (not a standalone block)
+3. Search Block Party: `node .claude/skills/block-collection-and-party/scripts/search-block-party.js breadcrumb`
+4. Find breadcrumb block in Block Party
+5. Review the implementation, noting it's community-contributed
+6. Evaluate if it meets your needs or needs adaptation
+
+**Why this works:**
+- Checked Block Collection first with both scripts (best practices)
+- Discovered breadcrumbs exist in Block Collection but as default content (part of header block)
+- Fell back to Block Party for standalone implementation
+- Aware that Block Party code may need more review
+
+### Example 3: Integrating Sass
+
+**User Request:** "Can we use Sass for our styles instead of plain CSS?"
+
+**Good Approach:**
+1. Recognize this is a build tooling question (not a block)
+2. Skip Block Collection (doesn't have build tools)
+3. Search Block Party: `node .claude/skills/block-collection-and-party/scripts/search-block-party.js --category "Build Tooling" sass`
+4. Find Sass integration examples
+5. Review the approach and adapt to your project
+
+**Why this works:**
+- Recognized Block Party is the right resource for build tools
+- Used category filter to narrow results
+- Found community examples of the integration
+
+### Example 4: Multiple Implementations Exist
+
+**User Request:** "Build a carousel for product images"
+
+**Scenario:** Both Block Collection and Block Party have carousel implementations
+
+**Good Approach:**
+1. Search Block Collection with both scripts:
+   ```bash
+   node .claude/skills/block-collection-and-party/scripts/search-block-collection-github.js carousel & \
+   node .claude/skills/block-collection-and-party/scripts/search-block-collection.js carousel & \
+   wait
+   ```
+2. Find Block Collection carousel from both search results
+3. Also search Block Party: `node .claude/skills/block-collection-and-party/scripts/search-block-party.js carousel`
+4. Find multiple Block Party carousels
+5. **Prefer Block Collection** for best practices
+6. Review Block Party versions to see if they have innovative features worth considering
+7. Make informed decision based on requirements
+
+**Why this works:**
+- Searched Block Collection with both scripts for comprehensive coverage
+- Searched Block Party to see all options
+- Defaulted to Block Collection (Adobe vetted)
+- Considered Block Party for potential innovations
+- Made an informed decision rather than blindly copying
+
+## Important Reminders
+
+1. **Always search for alternative names** - "FAQ" = "accordion", "slideshow" = "carousel"
+2. **Prefer Block Collection when available** - it's vetted for quality and best practices
+3. **Use Block Party for specialized needs** - it has broader variety but needs more evaluation
+4. **Don't copy blindly** - understand the code and adapt it to your project
+5. **Review content models carefully** - how authors structure content is critical
+6. **Check accessibility and performance** - especially for Block Party code
+7. **Search both resources** - sometimes both have implementations with different trade-offs
+8. **Category matters for Block Party** - use filters when you know what type you need
+
+## Common Search Patterns
+
+| Need | Block Collection Search | Block Party Search |
+|------|------------------------|-------------------|
+| FAQ section | `accordion` | `faq`, `accordion` |
+| Image gallery | `carousel` | `gallery`, `carousel`, `slideshow` |
+| Tabbed content | `tabs` | `tabs`, `tabbed` |
+| Navigation | `header` | `navigation`, `menu`, `header` |
+| Footer | `footer` | `footer` |
+| Product cards | `cards` | `cards`, `product` |
+| Video embed | `video`, `embed` | `video`, `embed`, `youtube` |
+| Build tools | N/A | Use `--category "Build Tooling"` |
+| Sidekick plugins | N/A | Use `--category "Sidekick Plugin"` |
+| Integrations | N/A | Search for service name (e.g., `target`, `analytics`) |
+
+## Troubleshooting
+
+**No results from both Block Collection scripts:**
+- Running both scripts ensures comprehensive coverage
+- If neither script returns results, the block likely doesn't exist in Block Collection
+- Try alternative search terms (e.g., "embed" vs "video", "faq" vs "accordion")
+- Fall back to Block Party search
+- If user insists the block exists, use WebFetch to manually check:
+  - `https://github.com/adobe/aem-block-collection/tree/main/blocks`
+- Consider building from scratch with guidance from `building-blocks` skill
+
+**Different results between the two scripts:**
+- This is normal - the GitHub API script searches folder names, the nav script searches the navigation
+- Both results are valid - review both to ensure you haven't missed anything
+- Prefer GitHub API results if there's a discrepancy (it's more direct)
+
+**IMPORTANT - When search returns no results but block likely exists:**
+- Don't immediately accept "no results" as definitive
+- Running both scripts maximizes chances of finding existing blocks
+- If the user suggests a block should exist, investigate further
+- Common blocks that may exist: embed, video, form, consent-management
+- Use WebFetch to manually browse the GitHub repo
+- Cross-reference with blocks you know exist (like video, accordion, carousel)
+
+**Too many results in Block Party:**
+- Use `--category` to filter
+- Refine search terms to be more specific
+- Review descriptions to find best matches
+
+**Found code but seems outdated:**
+- Check Block Collection for newer patterns
+- Review official docs with `docs-search` skill
+- Consider using as inspiration but implementing with modern approaches
+
+**Multiple implementations, unsure which to use:**
+- Prefer Block Collection for standard functionality
+- Choose Block Party for specialized or innovative features
+- Consider your specific requirements (performance, accessibility, features)
+- Review code quality and documentation before deciding
diff --git a/.claude/.skills/block-collection-and-party/scripts/get-block-structure.js b/.claude/.skills/block-collection-and-party/scripts/get-block-structure.js
new file mode 100644
index 0000000..31c8888
--- /dev/null
+++ b/.claude/.skills/block-collection-and-party/scripts/get-block-structure.js
@@ -0,0 +1,240 @@
+#!/usr/bin/env node
+
+/*
+ * Copyright 2025 Adobe. All rights reserved.
+ * This file is licensed to you under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License. You may obtain a copy
+ * of the License at http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software distributed under
+ * the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS
+ * OF ANY KIND, either express or implied. See the License for the specific language
+ * governing permissions and limitations under the License.
+ */
+
+/**
+ * Fetch and parse block structure examples from Adobe Block Collection
+ *
+ * This script retrieves the .plain.html version of a block's documentation page,
+ * which contains pre-decoration HTML structure examples showing the expected
+ * content model for the block.
+ *
+ * Usage:
+ *   node get-block-structure.js <block-name>
+ *   node get-block-structure.js accordion
+ *   node get-block-structure.js cards
+ *
+ * Output: JSON with block metadata, variants, and HTML structure examples
+ */
+
+import { JSDOM } from 'jsdom';
+
+const BLOCK_COLLECTION_BASE = 'https://main--aem-block-collection--adobe.aem.live';
+
+/**
+ * Simplify HTML by removing optimized picture elements and showing essential structure
+ */
+function simplifyHTML(html) {
+  // Remove picture optimization attributes that clutter the output
+  let simplified = html
+    .replace(/\s+srcset="[^"]*"/g, '')
+    .replace(/\s+type="[^"]*"/g, '')
+    .replace(/\s+media="[^"]*"/g, '')
+    .replace(/\s+loading="[^"]*"/g, '')
+    .replace(/\s+width="[^"]*"/g, '')
+    .replace(/\s+height="[^"]*"/g, '')
+    .replace(/\?width=[^"'\s]*/g, ''); // Remove image optimization params
+
+  // Replace multi-line picture elements with simplified version
+  simplified = simplified.replace(
+    /<picture>\s*(<source[^>]*>\s*)*\s*<img\s+([^>]*?)src="([^"]*)"([^>]*?)>\s*<\/picture>/gs,
+    (match, sources, beforeSrc, src, afterSrc) => {
+      const altMatch = match.match(/alt="([^"]*)"/);
+      const alt = altMatch ? ` alt="${altMatch[1]}"` : '';
+      return `<picture><img src="${src}"${alt}></picture>`;
+    }
+  );
+
+  // Compact whitespace but preserve structure
+  simplified = simplified
+    .replace(/>\s+</g, '>\n<')
+    .replace(/\n\s*\n/g, '\n')
+    .trim();
+
+  return simplified;
+}
+
+/**
+ * Analyze HTML structure to provide a human-readable description
+ */
+function analyzeStructure(html, blockName) {
+  const dom = new JSDOM(html);
+  const doc = dom.window.document;
+  const block = doc.querySelector(`.${blockName}`);
+
+  if (!block) return 'Structure analysis unavailable';
+
+  const rows = Array.from(block.children);
+  const analysis = [];
+
+  analysis.push(`Block has ${rows.length} row(s)`);
+
+  rows.forEach((row, i) => {
+    const cols = Array.from(row.children);
+    const colDescriptions = cols.map(col => {
+      const elements = [];
+      if (col.querySelector('picture')) elements.push('image');
+      if (col.querySelector('h1, h2, h3, h4, h5, h6')) elements.push('heading');
+      if (col.querySelector('p')) elements.push('paragraph(s)');
+      if (col.querySelector('ul, ol')) elements.push('list');
+      if (col.querySelector('a')) elements.push('link(s)');
+      return elements.length > 0 ? elements.join(', ') : 'content';
+    });
+
+    analysis.push(`  Row ${i + 1}: ${cols.length} column(s) [${colDescriptions.join(' | ')}]`);
+  });
+
+  return analysis.join('\n');
+}
+
+/**
+ * Fetch and parse block structure from Block Collection
+ */
+async function getBlockStructure(blockName) {
+  const url = `${BLOCK_COLLECTION_BASE}/block-collection/${blockName}.plain.html`;
+
+  try {
+    const response = await fetch(url);
+
+    if (!response.ok) {
+      if (response.status === 404) {
+        return {
+          success: false,
+          error: `Block "${blockName}" not found in Block Collection`,
+          url,
+          suggestion: 'Use search-block-collection-github.js to find available blocks'
+        };
+      }
+      throw new Error(`HTTP ${response.status}: ${response.statusText}`);
+    }
+
+    const html = await response.text();
+    const dom = new JSDOM(html);
+    const doc = dom.window.document;
+
+    // Find all sections (top-level divs in body)
+    const sections = Array.from(doc.body.children);
+
+    const variants = [];
+    let description = null;
+    let sourceCodeUrl = null;
+
+    // Process each section
+    sections.forEach(section => {
+      const metadata = section.querySelector('.library-metadata');
+
+      if (metadata) {
+        // Extract metadata
+        const metadataRows = Array.from(metadata.children);
+        const metadataObj = {};
+
+        metadataRows.forEach(row => {
+          const cells = Array.from(row.children);
+          if (cells.length === 2) {
+            const key = cells[0].textContent.trim();
+            const value = cells[1].textContent.trim();
+            metadataObj[key] = value;
+
+            // Extract source code link if present
+            const link = cells[1].querySelector('a[href*="github.com"]');
+            if (link) {
+              sourceCodeUrl = link.href;
+            }
+          }
+        });
+
+        // Store description (usually in last metadata block)
+        if (metadataObj.description) {
+          description = metadataObj.description.replace(/\s*Source Code\s*$/, '').trim();
+        }
+
+        // Find the block content (div with class matching block name)
+        const blockDiv = section.querySelector(`[class*="${blockName}"]`);
+
+        if (blockDiv && metadataObj.name) {
+          const blockHTML = blockDiv.outerHTML;
+          const simplifiedHTML = simplifyHTML(blockHTML);
+          const structure = analyzeStructure(blockHTML, blockName);
+
+          variants.push({
+            name: metadataObj.name,
+            html: simplifiedHTML,
+            structure
+          });
+        }
+      }
+    });
+
+    if (variants.length === 0) {
+      return {
+        success: false,
+        error: `No block examples found in ${url}`,
+        url
+      };
+    }
+
+    return {
+      success: true,
+      blockName,
+      url,
+      description,
+      sourceCodeUrl,
+      liveExampleUrl: `${BLOCK_COLLECTION_BASE}/block-collection/${blockName}`,
+      variants,
+      totalVariants: variants.length,
+      usage: {
+        purpose: 'Pre-decoration HTML structure examples',
+        note: 'This shows the HTML structure BEFORE JavaScript decoration. Use this to understand the expected content model when authoring content or generating HTML.'
+      }
+    };
+
+  } catch (error) {
+    return {
+      success: false,
+      error: error.message,
+      url,
+      blockName
+    };
+  }
+}
+
+// CLI execution
+async function main() {
+  const blockName = process.argv[2];
+
+  if (!blockName) {
+    console.error(JSON.stringify({
+      success: false,
+      error: 'Missing block name argument',
+      usage: 'node get-block-structure.js <block-name>',
+      examples: [
+        'node get-block-structure.js accordion',
+        'node get-block-structure.js cards',
+        'node get-block-structure.js tabs'
+      ]
+    }, null, 2));
+    process.exit(1);
+  }
+
+  const result = await getBlockStructure(blockName);
+  console.log(JSON.stringify(result, null, 2));
+
+  if (!result.success) {
+    process.exit(1);
+  }
+}
+
+// Run if called directly
+if (import.meta.url === `file://${process.argv[1]}`) {
+  main();
+}
diff --git a/.claude/.skills/block-collection-and-party/scripts/package.json b/.claude/.skills/block-collection-and-party/scripts/package.json
new file mode 100644
index 0000000..3dbc1ca
--- /dev/null
+++ b/.claude/.skills/block-collection-and-party/scripts/package.json
@@ -0,0 +1,3 @@
+{
+  "type": "module"
+}
diff --git a/.claude/.skills/block-collection-and-party/scripts/search-block-collection-github.js b/.claude/.skills/block-collection-and-party/scripts/search-block-collection-github.js
new file mode 100644
index 0000000..7084501
--- /dev/null
+++ b/.claude/.skills/block-collection-and-party/scripts/search-block-collection-github.js
@@ -0,0 +1,165 @@
+#!/usr/bin/env node
+
+/**
+ * Search the Adobe AEM Block Collection for blocks matching a search term
+ * This version uses GitHub API to get actual block folders
+ *
+ * Usage: node search-block-collection-github.js <search-term>
+ *
+ * Example: node search-block-collection-github.js accordion
+ */
+
+import https from 'https';
+
+// Block Collection constants
+const REPO_OWNER = 'adobe';
+const REPO_NAME = 'aem-block-collection';
+const BLOCKS_PATH = 'blocks';
+const REPO_BASE_URL = `https://github.com/${REPO_OWNER}/${REPO_NAME}`;
+const SITE_BASE_URL = 'https://main--aem-block-collection--adobe.aem.live';
+const API_URL = `https://api.github.com/repos/${REPO_OWNER}/${REPO_NAME}/contents/${BLOCKS_PATH}`;
+
+/**
+ * Fetch JSON from a URL using HTTPS
+ */
+function fetchUrl(url) {
+  return new Promise((resolve, reject) => {
+    https.get(url, {
+      headers: {
+        'User-Agent': 'AEM-Block-Search-Script',
+        'Accept': 'application/vnd.github.v3+json'
+      }
+    }, (res) => {
+      let data = '';
+
+      res.on('data', (chunk) => {
+        data += chunk;
+      });
+
+      res.on('end', () => {
+        if (res.statusCode === 200) {
+          try {
+            resolve(JSON.parse(data));
+          } catch (e) {
+            reject(new Error(`Failed to parse JSON: ${e.message}`));
+          }
+        } else {
+          reject(new Error(`HTTP ${res.statusCode}: ${res.statusMessage}`));
+        }
+      });
+    }).on('error', (err) => {
+      reject(err);
+    });
+  });
+}
+
+/**
+ * Get all block folders from the GitHub repository
+ */
+async function getBlocks() {
+  try {
+    const contents = await fetchUrl(API_URL);
+
+    // Filter for directories only
+    return contents
+      .filter(item => item.type === 'dir')
+      .map(item => ({
+        name: item.name,
+        displayName: item.name.split('-').map(word =>
+          word.charAt(0).toUpperCase() + word.slice(1)
+        ).join(' ')
+      }));
+  } catch (error) {
+    throw new Error(`Failed to fetch Block Collection from GitHub: ${error.message}`);
+  }
+}
+
+/**
+ * Determine if a block is "Default Content" (no block code) or a "Sample Block"
+ */
+function isDefaultContent(blockName) {
+  // Default Content items don't have block implementations
+  const defaultContentItems = [
+    'breadcrumbs', 'buttons', 'code', 'headings', 'icons', 'images',
+    'links', 'lists', 'metadata', 'section-metadata', 'sections', 'text'
+  ];
+  return defaultContentItems.includes(blockName.toLowerCase());
+}
+
+/**
+ * Search for blocks matching the search term
+ */
+function searchBlocks(blocks, searchTerm) {
+  const lowerSearchTerm = searchTerm.toLowerCase();
+
+  return blocks
+    .filter(block => {
+      // Search in both the URL slug and display name
+      return block.name.toLowerCase().includes(lowerSearchTerm) ||
+             block.displayName.toLowerCase().includes(lowerSearchTerm);
+    })
+    .map(block => {
+      const result = {
+        name: block.name,
+        displayName: block.displayName,
+        type: isDefaultContent(block.name) ? 'default-content' : 'block',
+        liveExampleUrl: `${SITE_BASE_URL}/block-collection/${block.name}`
+      };
+
+      // Only add code URLs for actual blocks (not default content)
+      if (result.type === 'block') {
+        result.jsUrl = `${REPO_BASE_URL}/blob/main/${BLOCKS_PATH}/${block.name}/${block.name}.js`;
+        result.cssUrl = `${REPO_BASE_URL}/blob/main/${BLOCKS_PATH}/${block.name}/${block.name}.css`;
+      } else {
+        result.note = 'This is default content documentation, not a standalone block. Code may be part of other blocks (e.g., breadcrumbs are in the header block). Visit https://www.aem.live/developer/block-collection and the live example URL for implementation guidance.';
+        result.documentationUrl = 'https://www.aem.live/developer/block-collection';
+      }
+
+      return result;
+    });
+}
+
+/**
+ * Main function
+ */
+async function main() {
+  const args = process.argv.slice(2);
+
+  if (args.length === 0) {
+    console.error('Usage: node search-block-collection-github.js <search-term>');
+    console.error('Example: node search-block-collection-github.js accordion');
+    process.exit(1);
+  }
+
+  const searchTerm = args[0];
+
+  try {
+    // Fetch all blocks from GitHub API
+    const blocks = await getBlocks();
+
+    // Search for matching blocks
+    const results = searchBlocks(blocks, searchTerm);
+
+    // Output results as JSON
+    const output = {
+      query: searchTerm,
+      source: 'Adobe AEM Block Collection (via GitHub API)',
+      repository: `${REPO_BASE_URL}`,
+      totalItems: blocks.length,
+      matchCount: results.length,
+      results: results
+    };
+
+    console.log(JSON.stringify(output, null, 2));
+
+    // Exit with code 0 if results found, 1 if no results
+    process.exit(results.length > 0 ? 0 : 1);
+
+  } catch (error) {
+    console.error('Error:', error.message);
+    process.exit(1);
+  }
+}
+
+// Run the script
+main();
diff --git a/.claude/.skills/block-collection-and-party/scripts/search-block-collection.js b/.claude/.skills/block-collection-and-party/scripts/search-block-collection.js
new file mode 100755
index 0000000..1ad1ea7
--- /dev/null
+++ b/.claude/.skills/block-collection-and-party/scripts/search-block-collection.js
@@ -0,0 +1,181 @@
+#!/usr/bin/env node
+
+/**
+ * Search the Adobe AEM Block Collection for blocks matching a search term
+ *
+ * Usage: node search-block-collection.js <search-term>
+ *
+ * Example: node search-block-collection.js accordion
+ */
+
+import https from 'https';
+
+// Block Collection constants
+const REPO_OWNER = 'adobe';
+const REPO_NAME = 'aem-block-collection';
+const BLOCKS_PATH = 'blocks';
+const REPO_BASE_URL = `https://github.com/${REPO_OWNER}/${REPO_NAME}`;
+const SITE_BASE_URL = 'https://main--aem-block-collection--adobe.aem.live';
+const NAV_URL = `${SITE_BASE_URL}/nav.plain.html`;
+
+/**
+ * Fetch HTML/text from a URL using HTTPS
+ */
+function fetchUrl(url, parseJson = false) {
+  return new Promise((resolve, reject) => {
+    https.get(url, {
+      headers: {
+        'User-Agent': 'AEM-Block-Search-Script'
+      }
+    }, (res) => {
+      let data = '';
+
+      res.on('data', (chunk) => {
+        data += chunk;
+      });
+
+      res.on('end', () => {
+        if (res.statusCode === 200) {
+          if (parseJson) {
+            try {
+              resolve(JSON.parse(data));
+            } catch (e) {
+              reject(new Error(`Failed to parse JSON: ${e.message}`));
+            }
+          } else {
+            resolve(data);
+          }
+        } else {
+          reject(new Error(`HTTP ${res.statusCode}: ${res.statusMessage}`));
+        }
+      });
+    }).on('error', (err) => {
+      reject(err);
+    });
+  });
+}
+
+/**
+ * Parse nav.plain.html to extract block names
+ */
+function parseBlocksFromNav(html) {
+  const blocks = [];
+
+  // Match all <a href="/block-collection/{block-name}">Display Name</a>
+  const linkPattern = /<a href="\/block-collection\/([^"]+)">([^<]+)<\/a>/g;
+  let match;
+
+  while ((match = linkPattern.exec(html)) !== null) {
+    const urlSlug = match[1];
+    const displayName = match[2];
+
+    blocks.push({
+      name: urlSlug,
+      displayName: displayName
+    });
+  }
+
+  return blocks;
+}
+
+/**
+ * Get all blocks from the Block Collection navigation
+ */
+async function getBlocks() {
+  try {
+    const html = await fetchUrl(NAV_URL, false);
+    return parseBlocksFromNav(html);
+  } catch (error) {
+    throw new Error(`Failed to fetch Block Collection navigation: ${error.message}`);
+  }
+}
+
+/**
+ * Determine if a block is "Default Content" (no block code) or a "Sample Block"
+ */
+function isDefaultContent(blockName) {
+  // Default Content items don't have block implementations
+  const defaultContentItems = [
+    'breadcrumbs', 'buttons', 'code', 'headings', 'icons', 'images',
+    'links', 'lists', 'metadata', 'section-metadata', 'sections', 'text'
+  ];
+  return defaultContentItems.includes(blockName.toLowerCase());
+}
+
+/**
+ * Search for blocks matching the search term
+ */
+function searchBlocks(blocks, searchTerm) {
+  const lowerSearchTerm = searchTerm.toLowerCase();
+
+  return blocks
+    .filter(block => {
+      // Search in both the URL slug and display name
+      return block.name.toLowerCase().includes(lowerSearchTerm) ||
+             block.displayName.toLowerCase().includes(lowerSearchTerm);
+    })
+    .map(block => {
+      const result = {
+        name: block.name,
+        displayName: block.displayName,
+        type: isDefaultContent(block.name) ? 'default-content' : 'block',
+        liveExampleUrl: `${SITE_BASE_URL}/block-collection/${block.name}`
+      };
+
+      // Only add code URLs for actual blocks (not default content)
+      if (result.type === 'block') {
+        result.jsUrl = `${REPO_BASE_URL}/blob/main/${BLOCKS_PATH}/${block.name}/${block.name}.js`;
+        result.cssUrl = `${REPO_BASE_URL}/blob/main/${BLOCKS_PATH}/${block.name}/${block.name}.css`;
+      } else {
+        result.note = 'This is default content documentation, not a standalone block. Code may be part of other blocks (e.g., breadcrumbs are in the header block). Visit https://www.aem.live/developer/block-collection and the live example URL for implementation guidance.';
+        result.documentationUrl = 'https://www.aem.live/developer/block-collection';
+      }
+
+      return result;
+    });
+}
+
+/**
+ * Main function
+ */
+async function main() {
+  const args = process.argv.slice(2);
+
+  if (args.length === 0) {
+    console.error('Usage: node search-block-collection.js <search-term>');
+    console.error('Example: node search-block-collection.js accordion');
+    process.exit(1);
+  }
+
+  const searchTerm = args[0];
+
+  try {
+    // Fetch all blocks from navigation
+    const blocks = await getBlocks();
+
+    // Search for matching blocks
+    const results = searchBlocks(blocks, searchTerm);
+
+    // Output results as JSON
+    const output = {
+      query: searchTerm,
+      source: 'Adobe AEM Block Collection',
+      repository: `${REPO_BASE_URL}`,
+      totalItems: blocks.length,
+      matchCount: results.length,
+      results: results
+    };
+
+    console.log(JSON.stringify(output, null, 2));
+
+    // Exit with code 0 if results found, 1 if no results
+    process.exit(results.length > 0 ? 0 : 1);
+
+  } catch (error) {
+    console.error('Error:', error.message);
+    process.exit(1);
+  }
+}
+
+// Run the script
+main();
diff --git a/.claude/.skills/block-collection-and-party/scripts/search-block-party.js b/.claude/.skills/block-collection-and-party/scripts/search-block-party.js
new file mode 100755
index 0000000..8528dff
--- /dev/null
+++ b/.claude/.skills/block-collection-and-party/scripts/search-block-party.js
@@ -0,0 +1,331 @@
+#!/usr/bin/env node
+
+/**
+ * Search the AEM Block Party index for blocks, plugins, tools, and integrations
+ *
+ * Note: Only searches approved entries from the Block Party index
+ *
+ * Usage: node search-block-party.js [--category <category>] <search-term> [additional-terms...]
+ *
+ * Examples:
+ *   node search-block-party.js breadcrumb
+ *   node search-block-party.js --category "Build Tooling" sass
+ *   node search-block-party.js adobe target integration
+ */
+
+import https from 'https';
+import fs from 'fs';
+import path from 'path';
+import { fileURLToPath } from 'url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+// Block Party constants
+const BLOCK_PARTY_INDEX_URL = 'https://www.aem.live/developer/block-party/block-party.json?sheet=curated-list-new';
+const CACHE_DIR = path.join(__dirname, '..', '.cache');
+const CACHE_FILE = path.join(CACHE_DIR, 'block-party-index.json');
+const CACHE_TTL = 24 * 60 * 60 * 1000; // 24 hours in milliseconds
+
+/**
+ * Fetch data from a URL using HTTPS
+ */
+function fetchUrl(url) {
+  return new Promise((resolve, reject) => {
+    https.get(url, {
+      headers: {
+        'User-Agent': 'AEM-Block-Party-Search-Script'
+      }
+    }, (res) => {
+      let data = '';
+
+      res.on('data', (chunk) => {
+        data += chunk;
+      });
+
+      res.on('end', () => {
+        if (res.statusCode === 200) {
+          try {
+            resolve(JSON.parse(data));
+          } catch (e) {
+            reject(new Error(`Failed to parse JSON: ${e.message}`));
+          }
+        } else {
+          reject(new Error(`HTTP ${res.statusCode}: ${res.statusMessage}`));
+        }
+      });
+    }).on('error', (err) => {
+      reject(err);
+    });
+  });
+}
+
+/**
+ * Check if cached index is still valid
+ */
+function isCacheValid() {
+  if (!fs.existsSync(CACHE_FILE)) {
+    return false;
+  }
+
+  const stats = fs.statSync(CACHE_FILE);
+  const age = Date.now() - stats.mtimeMs;
+
+  return age < CACHE_TTL;
+}
+
+/**
+ * Load index from cache
+ */
+function loadFromCache() {
+  try {
+    const data = fs.readFileSync(CACHE_FILE, 'utf8');
+    return JSON.parse(data);
+  } catch (error) {
+    return null;
+  }
+}
+
+/**
+ * Save index to cache
+ */
+function saveToCache(data) {
+  try {
+    if (!fs.existsSync(CACHE_DIR)) {
+      fs.mkdirSync(CACHE_DIR, { recursive: true });
+    }
+    fs.writeFileSync(CACHE_FILE, JSON.stringify(data, null, 2), 'utf8');
+  } catch (error) {
+    // Silently fail - caching is not critical
+    console.error('Warning: Failed to save cache:', error.message);
+  }
+}
+
+/**
+ * Fetch the Block Party index (with caching)
+ */
+async function getBlockPartyIndex() {
+  // Try cache first
+  if (isCacheValid()) {
+    const cached = loadFromCache();
+    if (cached) {
+      return cached;
+    }
+  }
+
+  // Fetch fresh data
+  try {
+    const data = await fetchUrl(BLOCK_PARTY_INDEX_URL);
+    saveToCache(data);
+    return data;
+  } catch (error) {
+    throw new Error(`Failed to fetch Block Party index: ${error.message}`);
+  }
+}
+
+/**
+ * Get all unique categories from entries (case-insensitive, preserving first occurrence)
+ */
+function getUniqueCategories(entries) {
+  const categoryMap = new Map(); // lowercase -> original case
+  entries.forEach(entry => {
+    if (entry.category && entry.category.trim()) {
+      const trimmed = entry.category.trim();
+      const lower = trimmed.toLowerCase();
+      if (!categoryMap.has(lower)) {
+        categoryMap.set(lower, trimmed);
+      }
+    }
+  });
+  return Array.from(categoryMap.values()).sort((a, b) =>
+    a.toLowerCase().localeCompare(b.toLowerCase())
+  );
+}
+
+/**
+ * Validate category against available categories
+ */
+function validateCategory(category, availableCategories) {
+  if (!category) {
+    return { valid: true };
+  }
+
+  const lowerCategory = category.toLowerCase();
+  const matchingCategory = availableCategories.find(cat =>
+    cat.toLowerCase() === lowerCategory || cat.toLowerCase().includes(lowerCategory)
+  );
+
+  if (!matchingCategory) {
+    return {
+      valid: false,
+      error: `Category "${category}" not found.`,
+      availableCategories
+    };
+  }
+
+  return { valid: true };
+}
+
+/**
+ * Filter entries by category
+ */
+function filterByCategory(entries, category) {
+  if (!category) {
+    return entries;
+  }
+
+  const lowerCategory = category.toLowerCase();
+
+  return entries.filter(entry => {
+    const entryCategory = (entry.category || '').toLowerCase();
+    return entryCategory.includes(lowerCategory);
+  });
+}
+
+/**
+ * Search entries by search terms
+ */
+function searchEntries(entries, searchTerms) {
+  if (searchTerms.length === 0) {
+    return entries;
+  }
+
+  return entries.filter(entry => {
+    const searchableText = [
+      entry.title || '',
+      entry.description || '',
+      entry.category || '',
+      entry.githubProfile || ''
+    ].join(' ').toLowerCase();
+
+    // Match all search terms (AND logic)
+    return searchTerms.every(term =>
+      searchableText.includes(term.toLowerCase())
+    );
+  });
+}
+
+/**
+ * Format results for output
+ */
+function formatResults(entries) {
+  return entries.map(entry => ({
+    title: entry.title || 'Untitled',
+    category: entry.category || 'Unknown',
+    description: entry.description || '',
+    githubUrl: entry.githubUrl || '',
+    showcaseUrl: entry.showcaseUrl || '',
+    githubProfile: entry.githubProfile || ''
+  }));
+}
+
+/**
+ * Parse command line arguments
+ */
+function parseArgs(args) {
+  const result = {
+    category: null,
+    searchTerms: []
+  };
+
+  for (let i = 0; i < args.length; i++) {
+    if (args[i] === '--category') {
+      if (i + 1 < args.length) {
+        result.category = args[i + 1];
+        i++; // Skip the next argument
+      } else {
+        throw new Error('--category flag requires a value');
+      }
+    } else {
+      result.searchTerms.push(args[i]);
+    }
+  }
+
+  return result;
+}
+
+/**
+ * Main function
+ */
+async function main() {
+  const args = process.argv.slice(2);
+
+  if (args.length === 0) {
+    console.error('Usage: node search-block-party.js [--category <category>] <search-term> [additional-terms...]');
+    console.error('');
+    console.error('Examples:');
+    console.error('  node search-block-party.js breadcrumb');
+    console.error('  node search-block-party.js --category "Build Tooling" sass');
+    console.error('  node search-block-party.js adobe target integration');
+    console.error('');
+    console.error('Common categories:');
+    console.error('  - Block');
+    console.error('  - Sidekick Plugin');
+    console.error('  - DA Plugin');
+    console.error('  - Code Snippet');
+    console.error('  - Build Tooling');
+    process.exit(1);
+  }
+
+  try {
+    // Parse arguments
+    const { category, searchTerms } = parseArgs(args);
+
+    // Fetch the index
+    const indexData = await getBlockPartyIndex();
+    const allEntries = indexData.data || [];
+
+    // Filter to only approved entries
+    const approvedEntries = allEntries.filter(entry =>
+      entry.approved === 'Yes' || entry.approved === true || entry.approved === 'true'
+    );
+
+    // Get available categories (from approved entries only)
+    const availableCategories = getUniqueCategories(approvedEntries);
+
+    // Validate category if provided
+    const validation = validateCategory(category, availableCategories);
+    if (!validation.valid) {
+      console.error('Error:', validation.error);
+      console.error('');
+      console.error('Available categories:');
+      validation.availableCategories.forEach(cat => {
+        console.error(`  - ${cat}`);
+      });
+      process.exit(1);
+    }
+
+    // Filter by category if specified (using approved entries only)
+    let entries = filterByCategory(approvedEntries, category);
+
+    // Search by terms
+    entries = searchEntries(entries, searchTerms);
+
+    // Format results
+    const results = formatResults(entries);
+
+    // Output results as JSON
+    const output = {
+      query: searchTerms.join(' '),
+      category: category || 'All categories',
+      source: 'AEM Block Party (Approved Only)',
+      indexUrl: BLOCK_PARTY_INDEX_URL,
+      totalEntries: allEntries.length,
+      approvedEntries: approvedEntries.length,
+      matchCount: results.length,
+      results: results
+    };
+
+    console.log(JSON.stringify(output, null, 2));
+
+    // Exit with code 0 if results found, 1 if no results
+    process.exit(results.length > 0 ? 0 : 1);
+
+  } catch (error) {
+    console.error('Error:', error.message);
+    process.exit(1);
+  }
+}
+
+// Run the script
+main();
diff --git a/.claude/.skills/block-inventory/SKILL.md b/.claude/.skills/block-inventory/SKILL.md
new file mode 100644
index 0000000..cab764f
--- /dev/null
+++ b/.claude/.skills/block-inventory/SKILL.md
@@ -0,0 +1,257 @@
+---
+name: block-inventory
+description: Survey available blocks from local AEM Edge Delivery Services project and Block Collection to understand the block palette available for authoring. Returns block inventory with purposes to inform content modeling decisions.
+---
+
+# Block Inventory
+
+Survey and catalog available blocks to understand what authoring options exist.
+
+## When to Use This Skill
+
+Use this skill when:
+- Starting a page import to understand available blocks
+- Planning content structure and need to know block options
+- An author would see a block library and choose from available options
+
+**Do NOT use this skill when:**
+- You already know which specific block you need
+- Building new blocks from scratch
+- Only checking if one specific block exists (use block-collection-and-party directly)
+
+## Why This Skill Exists
+
+Real authors see a block library in their authoring tools. They think: "I want a hero section... oh, there's a Hero block!"
+
+This skill provides that same context - understanding what blocks are available BEFORE making authoring decisions.
+
+## Related Skills
+
+- **page-import** - Top-level orchestrator
+- **identify-page-structure** - Invokes this skill to survey blocks (Step 2.5)
+- **block-collection-and-party** - This skill uses it to search Block Collection
+- **content-modeling** - Can reference block inventory but maintains independent judgment
+
+## Block Inventory Workflow
+
+### Step 1: Scan Local Project Blocks
+
+Check what blocks already exist in the project:
+
+```bash
+# List all local blocks
+ls -d blocks/*/
+```
+
+**For each block found:**
+- Record block name
+- Note: Purpose/description comes from block code or documentation
+
+**Output:** List of local block names
+
+---
+
+### Step 2: Search Block Collection for Common Blocks
+
+Search for commonly-used blocks that might not be in the project yet.
+
+**Common blocks to search (run in parallel):**
+
+```bash
+# Search all common blocks in parallel
+node .claude/skills/block-collection-and-party/scripts/search-block-collection-github.js hero &
+node .claude/skills/block-collection-and-party/scripts/search-block-collection-github.js cards &
+node .claude/skills/block-collection-and-party/scripts/search-block-collection-github.js columns &
+node .claude/skills/block-collection-and-party/scripts/search-block-collection-github.js accordion &
+node .claude/skills/block-collection-and-party/scripts/search-block-collection-github.js tabs &
+node .claude/skills/block-collection-and-party/scripts/search-block-collection-github.js carousel &
+node .claude/skills/block-collection-and-party/scripts/search-block-collection-github.js quote &
+node .claude/skills/block-collection-and-party/scripts/search-block-collection-github.js fragment &
+wait
+```
+
+**Why these specific blocks:**
+- hero - Large prominent content at page top
+- cards - Grid of items with images/text
+- columns - Side-by-side content layouts
+- accordion - Expandable Q&A sections
+- tabs - Switchable content panels
+- carousel - Rotating image/content displays
+- quote - Highlighted testimonials or quotes
+- fragment - Reusable content sections
+
+**Output:** Block Collection blocks with live example URLs
+
+---
+
+### Step 3: Get Block Purposes
+
+For each block found (local or Block Collection):
+
+**If from Block Collection:**
+- Purpose is clear from live example URL
+- Visit live example to understand usage: `https://main--aem-block-collection--adobe.aem.live/block-collection/{block-name}`
+
+**If local block:**
+- Check for README or comments in block code
+- Infer from block name and structure
+- May need to describe based on code examination
+
+**Output:** Block name + purpose/description
+
+---
+
+### Step 4: Consolidate Block Inventory
+
+Create comprehensive block palette:
+
+**Format:**
+```
+Available Blocks:
+
+LOCAL BLOCKS:
+- {block-name}: {purpose}
+- {block-name}: {purpose}
+
+BLOCK COLLECTION (can be added):
+- hero: Large heading, text, and buttons at top of page
+- cards: Grid of items with images, headings, and descriptions
+- columns: Side-by-side content in 2-3 columns
+- accordion: Expandable questions and answers
+- tabs: Content organized in switchable tabs
+- carousel: Rotating images or content panels
+- quote: Highlighted testimonial or pullquote
+- fragment: Reusable content section
+```
+
+**Important notes in output:**
+- Local blocks are already available for use
+- Block Collection blocks can be added if needed
+- Link to Block Collection for authors to see examples
+
+**Output:** Complete block inventory
+
+---
+
+## Usage Example
+
+**Scenario:** Starting WKND Trendsetters homepage import
+
+**Step 1 - Local blocks:**
+```bash
+ls -d blocks/*/
+# Output: (none found - new project)
+```
+
+**Step 2 - Block Collection search:**
+```bash
+# Run parallel searches
+node .claude/skills/block-collection-and-party/scripts/search-block-collection-github.js hero &
+node .claude/skills/block-collection-and-party/scripts/search-block-collection-github.js cards &
+# ... (all common blocks)
+wait
+```
+
+**Results:**
+- hero ✅ Found
+- cards ✅ Found
+- columns ✅ Found
+- accordion ✅ Found
+- tabs ✅ Found
+- carousel ✅ Found
+- quote ✅ Found
+- fragment ✅ Found
+
+**Step 3 - Get purposes:**
+Visit live examples or read descriptions from search results
+
+**Step 4 - Consolidated output:**
+```
+Block Inventory for Migration:
+
+LOCAL BLOCKS:
+(None - new project)
+
+BLOCK COLLECTION AVAILABLE:
+- hero: Large heading, paragraph, and call-to-action buttons for page introductions
+  Example: https://main--aem-block-collection--adobe.aem.live/block-collection/hero
+
+- cards: Grid layout of content items with images, headings, and descriptions
+  Example: https://main--aem-block-collection--adobe.aem.live/block-collection/cards
+
+- columns: Side-by-side content in 2-3 columns for comparisons or layouts
+  Example: https://main--aem-block-collection--adobe.aem.live/block-collection/columns
+
+- accordion: Expandable sections for FAQs or collapsed content
+  Example: https://main--aem-block-collection--adobe.aem.live/block-collection/accordion
+
+- tabs: Tabbed interface for organizing related content
+  Example: https://main--aem-block-collection--adobe.aem.live/block-collection/tabs
+
+- carousel: Rotating slideshow of images or content
+  Example: https://main--aem-block-collection--adobe.aem.live/block-collection/carousel
+
+- quote: Highlighted testimonial or pullquote with attribution
+  Example: https://main--aem-block-collection--adobe.aem.live/block-collection/quote
+
+- fragment: Reusable content section that can be embedded across pages
+  Example: https://main--aem-block-collection--adobe.aem.live/block-collection/fragment
+```
+
+---
+
+## Key Principles
+
+**Completeness over perfection:**
+- Better to show too many blocks than miss one
+- Authors can ignore blocks they don't need
+- Discovering a perfect-fit block later is frustrating
+
+**Practical purposes:**
+- Describe blocks in author language, not developer terms
+- "Grid of items" not "repeating collection pattern"
+- "Expandable Q&A" not "interactive disclosure widget"
+
+**Block Collection focus:**
+- Prioritize Block Collection blocks (vetted, accessible, performant)
+- These are the canonical implementations
+- Can be added to any project
+
+**Speed matters:**
+- Run searches in parallel
+- Don't visit every live example (time-consuming)
+- Get enough info to understand purpose
+
+---
+
+## Common Blocks Reference
+
+Here's a quick reference for the most common blocks:
+
+| Block | Purpose | When Authors Use It |
+|-------|---------|-------------------|
+| hero | Page introduction | "I want a big heading at the top" |
+| cards | Content grid | "I want items in a grid with pictures" |
+| columns | Side-by-side | "I want two things next to each other" |
+| accordion | Collapsible Q&A | "I have FAQs that should expand/collapse" |
+| tabs | Tabbed content | "I want content in switchable tabs" |
+| carousel | Image slider | "I want images that rotate/slide" |
+| quote | Testimonial | "I want to highlight a customer quote" |
+| fragment | Reusable content | "I want to reuse this section on multiple pages" |
+
+---
+
+## Limitations
+
+This skill does NOT:
+- Determine which block to use (that's content-modeling's job)
+- Validate if blocks work correctly
+- Create new blocks
+- Search Block Party (focuses on Block Collection + local)
+- Provide detailed implementation guidance
+
+For those needs, use the appropriate skills:
+- content-modeling: Determine which block fits
+- block-collection-and-party: Deep search and code examination
+- building-blocks: Create new blocks
+- content-driven-development: Implementation guidance
diff --git a/.claude/.skills/building-blocks/SKILL.md b/.claude/.skills/building-blocks/SKILL.md
new file mode 100644
index 0000000..ac911fa
--- /dev/null
+++ b/.claude/.skills/building-blocks/SKILL.md
@@ -0,0 +1,199 @@
+---
+name: Building Blocks
+description: Guide for creating new AEM Edge Delivery blocks or modifying existing blocks. Use this skill whenever you are creating a new block from scratch or making significant changes to existing blocks that involve JavaScript decoration, CSS styling, or content model changes.
+---
+
+# Building Blocks
+
+This skill guides you through creating new AEM Edge Delivery blocks or modifying existing ones, following Content Driven Development (CDD) principles. Blocks are the reusable building blocks of AEM sites - each transforms authored content into rich, interactive experiences through JavaScript decoration and CSS styling. This skill covers the complete development process: understanding content models, implementing decoration logic, applying styles, and maintaining code quality standards.
+
+## Related Skills
+
+- **content-driven-development**: MUST be invoked before using this skill to ensure content and content models are ready
+- **block-collection-and-party**: Use to find similar blocks for patterns
+- **testing-blocks**: Automatically invoked after implementation for comprehensive testing
+
+## When to Use This Skill
+
+This skill should ONLY be invoked from the **content-driven-development** skill during Phase 2 (Implementation).
+
+If you are not already following the CDD process:
+- **STOP** - Do not proceed with this skill
+- **Invoke the content-driven-development skill first**
+- The CDD skill will ensure test content and content models are ready before implementation
+
+This skill handles:
+- Creating new block files and structure
+- Implementing JavaScript decoration
+- Adding CSS styling
+- Code quality and testing
+
+## Prerequisites
+
+**REQUIRED before using this skill:**
+- ✅ Test content must exist (in CMS or local drafts)
+- ✅ Content model must be defined
+- ✅ Test content URL must be available
+
+**Information needed:**
+1. **Block name**: What should the block be called?
+2. **Content model**: The defined structure authors will use
+3. **Test content URL**: Path to test content for development
+
+## Process Overview
+
+1. Verify Prerequisites (CDD completed)
+2. Find Similar Blocks (for patterns and reuse)
+3. Create or Modify Block Structure (files and directories)
+4. Implement JavaScript Decoration (DOM transformation)
+5. Add CSS Styling (scoped, responsive styles)
+6. Test the Implementation (local testing, linting)
+7. Document Block (developer and author-facing docs)
+
+## Detailed Process
+
+### 1. Verify Prerequisites
+
+**Before proceeding, confirm with the user:**
+
+"Do you have:
+- ✅ Test content created (URL or path)?
+- ✅ Content model defined?
+
+If not, we need to use the content-driven-development skill first."
+
+If prerequisites are not met, STOP and invoke the **content-driven-development** skill.
+
+If prerequisites are met, get the test content URL from the user and proceed to step 2.
+
+### 2. Find Similar Blocks
+
+**For new blocks or major modifications:**
+
+1. Search the codebase for similar blocks that might provide useful patterns or code we can re-use
+2. Use the **block-collection-and-party** skill to find relevant reference blocks
+
+Review the implementation patterns in similar blocks to inform your approach.
+
+**For minor modifications to existing blocks:** Skip to step 3.
+
+### 3. Create or Modify Block Structure
+
+**For new blocks:**
+
+1. Create directory: `blocks/{block-name}/`
+2. Create files: `{block-name}.js` and `{block-name}.css`
+3. Use the boilerplate structure (or reference templates in `resources/` if helpful):
+   - JS file exports a default `decorate(block)` function (can be async if needed)
+   - CSS file targets the `.{block-name}` class
+
+**For existing blocks:**
+
+1. Locate the existing block directory in `blocks/{block-name}/`
+2. Review the current implementation before making changes
+3. Understand the existing decoration logic and styles
+
+### 4. Implement JavaScript Decoration
+
+Follow patterns and conventions in `resources/js-guidelines.md`:
+
+- Use DOM APIs to transform the initial block HTML structure
+- Keep decoration logic focused and single-purpose
+- Handle variants appropriately (check block.classList for variant classes)
+- Follow established patterns from similar blocks
+
+**Read `resources/js-guidelines.md` for detailed examples, code standards, and best practices.**
+
+### 5. Add CSS Styling
+
+Follow patterns and conventions in `resources/css-guidelines.md`:
+
+- All CSS selectors must be scoped to the block (start with `.{block-name}`)
+- Use BEM-like naming within the block scope
+- Leverage CSS custom properties for theming
+- Write mobile-first responsive styles
+- Keep specificity low
+- Follow established patterns from similar blocks
+
+**Read `resources/css-guidelines.md` for detailed examples, code standards, and best practices.**
+
+### 6. Test the Implementation
+
+**After implementation is complete, invoke the testing-blocks skill:**
+
+The testing-blocks skill will guide you through:
+- Writing unit tests for any logic-heavy utilities
+- Browser testing to validate block behavior
+- Taking screenshots for validation and PR documentation
+- Running linting and fixing issues
+- Verifying GitHub checks pass
+
+Provide the testing-blocks skill with:
+- Block name being tested
+- Test content URL (from CDD process)
+- Any variants that need testing
+
+Return to this skill after testing is complete to proceed to step 7.
+
+### 7. Document Block
+
+Blocks require two types of documentation:
+
+#### Developer Documentation
+
+- Most blocks are simple and self-contained and only need code comments for documentation
+- If a block is especially complex (has many variants, or especially complex code) consider adding a brief README.md in the block folder
+- Keep any README documentation very brief so it can be consumed at a glance
+
+#### Author-Facing Documentation
+
+Author-facing documentation helps content authors understand how to use the block in the CMS. This documentation typically exists as draft/library content in the CMS itself, not in the codebase.
+
+**When author documentation is needed:**
+
+Almost all blocks should have author-facing documentation. The only exceptions are:
+- Deprecated blocks that should no longer be used but can't be removed yet
+- Special-purpose blocks used very infrequently on a need-to-know basis
+- Auto-blocked blocks that shouldn't be used directly by authors
+
+**Maintaining author documentation:**
+
+Author documentation must be kept in sync with the block implementation:
+- Update when variants are added, removed, or modified
+- Update when the content structure changes
+- Update when block behavior or functionality changes
+
+**Where author documentation lives:**
+
+Different projects use different approaches for author documentation:
+
+1. **Sidekick Library** (Google Drive/SharePoint authoring):
+   - Uses https://github.com/adobe/franklin-sidekick-library
+   - Check for `/tools/sidekick/library.html` in the codebase
+   - If present, guide user to add/update block documentation in the library
+
+2. **Document Authoring (DA) Library**:
+   - Uses https://docs.da.live/administrators/guides/setup-library
+   - Different implementation than Sidekick Library
+   - If in use, guide user to update block documentation in DA library
+
+3. **Universal Editor (UE) projects**:
+   - Often skip dedicated author documentation libraries
+   - May use inline help or other mechanisms
+
+4. **Simple documentation pages**:
+   - Some projects maintain documentation under `/drafts` or `/docs`
+   - Pages contain authoring guides and block examples
+
+**What to include in author documentation:**
+
+The specific content of author documentation varies by project. As an agent:
+1. Identify that author documentation needs to be created or updated
+2. Determine which documentation approach the project uses (check for `/tools/sidekick/library.html` as a signal)
+3. Guide the user on what aspects of the block should be documented based on the changes made
+4. Provide specific guidance based on the project's documentation approach
+
+## Reference Materials
+
+- `resources/js-guidelines.md`
+- `resources/css-guidelines.md`
diff --git a/.claude/.skills/building-blocks/resources/css-guidelines.md b/.claude/.skills/building-blocks/resources/css-guidelines.md
new file mode 100644
index 0000000..e3e876e
--- /dev/null
+++ b/.claude/.skills/building-blocks/resources/css-guidelines.md
@@ -0,0 +1,412 @@
+# CSS Guidelines for AEM Blocks
+
+## Block Scoping
+
+**All CSS selectors must be scoped to the block.** This is critical to prevent style leakage between blocks.
+
+**✅ Good - scoped to block:**
+```css
+main .my-block {
+  padding: 1rem;
+}
+
+main .my-block h2 {
+  font-size: var(--heading-font-size-m);
+}
+```
+
+**❌ Bad - not scoped:**
+```css
+/* This will affect ALL h2 elements on the page */
+h2 {
+  font-size: var(--heading-font-size-m);
+}
+
+/* This will affect elements outside the block */
+.item {
+  padding: 1rem;
+}
+```
+
+**Scoping pattern:**
+- Always start selectors with `main .{block-name}`
+- This ensures styles only apply within your block
+- Use additional classes for sub-elements within the block
+
+**⚠️ Special note on `-wrapper` and `-container` classes:**
+
+The platform automatically adds `.{block-name}-wrapper` and `.{block-name}-container` divs *outside* your block. If you need to style elements with these class names *inside* your block, you must scope them carefully:
+
+```css
+/* ❌ Bad - will affect the wrapper OUTSIDE your block */
+main .my-block-wrapper {
+  padding: 2rem;
+}
+
+/* ✅ Good - only affects wrappers INSIDE your block */
+main .my-block .my-block-wrapper {
+  padding: 2rem;
+}
+
+/* Better - avoid using these class names inside your block */
+main .my-block .inner-wrapper {
+  padding: 2rem;
+}
+```
+
+**Best practice:** Avoid using `-wrapper` or `-container` suffix for classes inside your block to prevent confusion.
+
+## Naming Conventions
+
+Use BEM-like naming for elements within your block:
+
+```css
+/* Block */
+main .my-block {
+  /* block styles */
+}
+
+/* Element - using descriptive class names */
+main .my-block .item {
+  /* item styles */
+}
+
+main .my-block .item-title {
+  /* item title styles */
+}
+
+/* Modifier/variant */
+main .my-block.dark {
+  /* dark variant styles */
+}
+
+main .my-block.wide .item {
+  /* item styles in wide variant */
+}
+```
+
+**Key points:**
+- Use lowercase with hyphens for class names (kebab-case)
+- Choose descriptive, semantic names
+- Avoid generic names like `.container`, `.wrapper` - be specific to your block
+
+## CSS Custom Properties (Variables)
+
+Leverage CSS custom properties defined in `styles/styles.css` for consistency:
+
+**Colors:**
+```css
+main .my-block {
+  background-color: var(--background-color);
+  color: var(--text-color);
+}
+
+main .my-block a:any-link {
+  color: var(--link-color);
+}
+
+main .my-block a:hover {
+  color: var(--link-hover-color);
+}
+```
+
+**Typography:**
+```css
+main .my-block h2 {
+  font-family: var(--heading-font-family);
+  font-size: var(--heading-font-size-m);
+}
+
+main .my-block p {
+  font-family: var(--body-font-family);
+  font-size: var(--body-font-size-m);
+}
+```
+
+**Layout:**
+```css
+main .my-block {
+  max-width: var(--max-content-width);
+  padding-inline: var(--inline-section-padding);
+}
+```
+
+**Available custom properties:**
+- Colors: `--clr-*`, `--link-color`, `--background-color`, `--text-color`, etc.
+- Fonts: `--body-font-family`, `--heading-font-family`, `--fixed-font-family`
+- Font sizes: `--heading-font-size-*`, `--body-font-size-*`
+- Layout: `--max-content-width`, `--inline-section-padding`
+
+See `styles/styles.css` for the complete list.
+
+## Mobile-First Responsive Design
+
+Write styles mobile-first, then add media queries for larger screens:
+
+```css
+/* Mobile styles (default) */
+main .my-block {
+  padding: 1rem;
+  flex-direction: column;
+}
+
+/* Tablet and up */
+@media (width >= 600px) {
+  main .my-block {
+    padding: 2rem;
+  }
+}
+
+/* Desktop and up */
+@media (width >= 900px) {
+  main .my-block {
+    flex-direction: row;
+    padding: 4rem;
+  }
+}
+```
+
+**Standard breakpoints:**
+- Mobile: default (< 600px)
+- Tablet: `@media (width >= 600px)`
+- Desktop: `@media (width >= 900px)`
+
+**Modern syntax:**
+- Use range syntax: `(width >= 600px)` instead of `(min-width: 600px)`
+- Use logical properties where appropriate
+
+## Modern CSS Features
+
+Use modern CSS features for better maintainability and performance:
+
+**Logical properties:**
+```css
+/* Use logical properties for internationalization */
+main .my-block {
+  padding-inline: 1rem; /* left/right in LTR, right/left in RTL */
+  padding-block: 2rem; /* top/bottom */
+  margin-inline-start: 1rem; /* left in LTR */
+  border-inline-start: 2px solid black;
+}
+```
+
+**Modern layout:**
+```css
+/* Flexbox */
+main .my-block {
+  display: flex;
+  gap: 1rem; /* Better than margin hacks */
+  flex-wrap: wrap;
+}
+
+/* Grid */
+main .my-block {
+  display: grid;
+  grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
+  gap: 2rem;
+}
+```
+
+**Modern color syntax:**
+```css
+main .my-block {
+  background-color: rgb(0 0 0 / 20%); /* Modern RGB with alpha */
+  color: hsl(200 50% 50%); /* HSL syntax */
+}
+```
+
+## Keep Specificity Low
+
+Avoid overly specific selectors:
+
+**✅ Good - low specificity:**
+```css
+main .my-block .item {
+  padding: 1rem;
+}
+
+main .my-block .item-title {
+  font-size: 1.5rem;
+}
+```
+
+**❌ Bad - high specificity:**
+```css
+main .my-block div div div.item {
+  padding: 1rem;
+}
+
+main div.my-block > div > h2.item-title {
+  font-size: 1.5rem;
+}
+```
+
+**Best practices:**
+- Use classes, not tag names when possible
+- Avoid ID selectors
+- Keep selector chains short (2-3 levels max)
+- Don't nest deeper than necessary
+
+## Handling Variants
+
+Use the variant class alongside the block class:
+
+```css
+/* Base block */
+main .my-block {
+  background-color: var(--background-color);
+  color: var(--text-color);
+}
+
+/* Dark variant */
+main .my-block.dark {
+  background-color: var(--dark-color);
+  color: var(--clr-white);
+}
+
+/* Wide variant */
+main .my-block.wide {
+  max-width: 100%;
+}
+
+/* Combining variants */
+main .my-block.dark.wide {
+  /* Styles for both dark and wide */
+}
+```
+
+## Performance Considerations
+
+**Minimize reflows and repaints:**
+```css
+/* Prefer transforms over position changes */
+main .my-block .item {
+  transform: translateX(10px); /* Better performance */
+}
+
+/* Avoid this: */
+main .my-block .item {
+  left: 10px; /* Triggers reflow */
+}
+```
+
+**Use will-change sparingly:**
+```css
+/* Only for elements that will definitely animate */
+main .my-block .animated-item {
+  will-change: transform;
+}
+```
+
+**Avoid expensive properties on large elements:**
+```css
+/* Be careful with these on large areas: */
+/* box-shadow, border-radius, opacity, filters */
+```
+
+## Code Style
+
+**Formatting:**
+- Use 2-space indentation
+- One selector per line for multiple selectors
+- Opening brace on same line as selector
+- One property per line
+- Space after colon in property declarations
+- No space before colon
+- End all declarations with semicolon
+
+**Example:**
+```css
+main .my-block,
+main .my-block .item {
+  display: flex;
+  padding: 1rem;
+  gap: 1rem;
+}
+```
+
+**Order of properties** (recommended):
+1. Layout (display, position, top, left, etc.)
+2. Box model (width, height, margin, padding, border)
+3. Visual (background, color, font, etc.)
+4. Animation/transform
+
+## Common Patterns
+
+### Reset list styles
+```css
+main .my-block ul {
+  list-style: none;
+  margin: 0;
+  padding: 0;
+}
+```
+
+### Center content
+```css
+main .my-block {
+  max-width: var(--max-content-width);
+  margin-inline: auto;
+}
+```
+
+### Aspect ratio containers
+```css
+main .my-block .video-container {
+  aspect-ratio: 16 / 9;
+}
+```
+
+### Truncate text
+```css
+main .my-block .truncated {
+  overflow: hidden;
+  text-overflow: ellipsis;
+  white-space: nowrap;
+}
+```
+
+## Anti-Patterns to Avoid
+
+**❌ Don't use !important:**
+```css
+/* Avoid this */
+main .my-block {
+  color: red !important;
+}
+
+/* Fix specificity issues properly instead */
+```
+
+**❌ Don't style elements outside your block:**
+```css
+/* Bad - modifies header globally */
+main .my-block {
+  /* ... */
+}
+
+header {
+  background: red;
+}
+```
+
+**❌ Don't hardcode values when variables exist:**
+```css
+/* Bad */
+main .my-block {
+  font-family: 'Lato', sans-serif;
+  color: #666;
+}
+
+/* Good */
+main .my-block {
+  font-family: var(--body-font-family);
+  color: var(--text-color);
+}
+```
+
+**❌ Don't use absolute positioning for layout:**
+```css
+/* Prefer flexbox or grid for layout */
+/* Use absolute positioning only for visual effects */
+```
diff --git a/.claude/.skills/building-blocks/resources/js-guidelines.md b/.claude/.skills/building-blocks/resources/js-guidelines.md
new file mode 100644
index 0000000..b3cffd1
--- /dev/null
+++ b/.claude/.skills/building-blocks/resources/js-guidelines.md
@@ -0,0 +1,336 @@
+# JavaScript Guidelines for AEM Blocks
+
+## Basic Block Structure
+
+Every block must export a default `decorate` function that receives the block element as a parameter. The function can be async if needed.
+
+**Basic structure:**
+
+```javascript
+/**
+ * decorate the block
+ * @param {Element} block the block
+ */
+export default async function decorate(block) {
+  // Your decoration logic here
+}
+```
+
+**Key points:**
+- Always export the decorate function as the default export
+- The function receives the block DOM element as the first parameter
+- Use `async` if you need to await operations (fetching data, loading modules, etc.)
+- Include JSDoc comments describing the functions
+
+## DOM Manipulation Patterns
+
+### Good Patterns
+
+**✅ Re-use existing DOM elements when possible:**
+```javascript
+// Good - re-use the existing element
+const paragraph = block.querySelector('p');
+paragraph.classList.add('decorated');
+
+// Also good - extract and re-use
+const picture = block.querySelector('picture');
+const figure = document.createElement('figure');
+figure.append(picture); // Re-uses the picture element
+block.replaceChildren(figure);
+
+// Avoid - creating new elements unnecessarily
+const text = block.querySelector('p').textContent;
+const newP = document.createElement('p');
+newP.textContent = text;
+// This throws away the original <p> and creates a new one
+```
+
+**✅ Use semantic HTML:**
+```javascript
+const blockquote = document.createElement('blockquote');
+const figure = document.createElement('figure');
+```
+
+**✅ Use spread operator for multiple elements:**
+```javascript
+const pars = block.querySelectorAll('p');
+const container = document.createElement('div');
+container.append(...pars);
+```
+
+**✅ Replace content efficiently:**
+```javascript
+block.replaceChildren(newElement);
+```
+
+**✅ Query within the block scope:**
+```javascript
+// Good - scoped to block
+const links = block.querySelectorAll('a');
+
+// Avoid - queries entire document
+const links = document.querySelectorAll('a');
+```
+
+### Bad Patterns
+
+**❌ Don't use innerHTML for complex structures:**
+```javascript
+// Bad - hard to maintain, XSS risk
+block.innerHTML = '<div class="wrapper"><p>Text</p></div>';
+
+// Good - use DOM APIs
+const wrapper = document.createElement('div');
+wrapper.className = 'wrapper';
+const p = document.createElement('p');
+p.textContent = 'Text';
+wrapper.append(p);
+block.append(wrapper);
+```
+
+**❌ Don't mutate elements from other blocks:**
+```javascript
+// Bad - affects global state
+const header = document.querySelector('header');
+header.classList.add('modified-by-my-block');
+
+// Good - only modify your block
+block.classList.add('has-special-behavior');
+```
+
+**❌ Don't leave temporary DOM elements:**
+```javascript
+// Bad - leaves empty paragraphs
+const text = block.querySelector('p').textContent;
+const newDiv = document.createElement('div');
+newDiv.textContent = text;
+block.append(newDiv);
+
+// Good - remove the original
+const p = block.querySelector('p');
+const newDiv = document.createElement('div');
+newDiv.textContent = p.textContent;
+p.replaceWith(newDiv);
+```
+
+## Handling Variants
+
+Blocks can have variant classes applied (e.g., `<div class="my-block dark">`). Check for variants using `classList`:
+
+```javascript
+export default async function decorate(block) {
+  const isDark = block.classList.contains('dark');
+  const isWide = block.classList.contains('wide');
+
+  // Apply variant-specific logic
+  if (isDark) {
+    // Handle dark variant
+  }
+}
+```
+
+**Key points:**
+- Variant classes are added alongside the block class
+- Use `classList.contains()` to check for variants
+- CSS should handle most variant styling; use JS only for behavior changes
+
+## Common Patterns
+
+### Working with Images
+
+Images in authored content come with srcset and alt attributes from the platform. You can also create optimized images programmatically using `createOptimizedPicture()` from aem.js:
+
+```javascript
+import { createOptimizedPicture } from '../../scripts/aem.js';
+
+export default async function decorate(block) {
+  // Working with existing images
+  const images = block.querySelectorAll('img');
+  images.forEach((img) => {
+    // Images come with srcset and alt from the platform
+    // Wrap in figure if needed
+    const figure = document.createElement('figure');
+    img.replaceWith(figure);
+    figure.append(img);
+  });
+
+  // Creating optimized pictures programmatically
+  const picture = createOptimizedPicture('/path/to/image.jpg', 'Alt text', false, [{ width: '750' }]);
+  block.append(picture);
+}
+```
+
+### Fetching Data
+
+Use async/await for data fetching:
+
+```javascript
+export default async function decorate(block) {
+  try {
+    const response = await fetch('/path/to/data.json');
+    const data = await response.json();
+
+    // Use the data
+    renderData(block, data);
+  } catch (error) {
+    // eslint-disable-next-line no-console
+    console.error('Failed to load data:', error);
+  }
+}
+```
+
+### Loading Additional Modules
+
+Use regular imports for modules that are always needed:
+
+```javascript
+import { someFunction } from '../../scripts/utils.js';
+
+export default async function decorate(block) {
+  someFunction(block);
+}
+```
+
+Use dynamic imports for modules that are conditionally needed or can be loaded later:
+
+```javascript
+export default async function decorate(block) {
+  // Conditionally load a module
+  if (block.classList.contains('advanced')) {
+    const { advancedFunction } = await import('../../scripts/advanced.js');
+    advancedFunction(block);
+  }
+
+  // Or defer loading until later
+  setTimeout(async () => {
+    const { heavyModule } = await import('../../scripts/heavy.js');
+    heavyModule.init(block);
+  }, 0);
+}
+```
+
+### Handling Multiple Content Patterns
+
+Sometimes a block might have different content structures:
+
+```javascript
+export default async function decorate(block) {
+  const rows = block.querySelectorAll(':scope > div');
+
+  // Pattern 1: Single row with image and text
+  if (rows.length === 1) {
+    // Handle simple pattern
+  }
+
+  // Pattern 2: Multiple rows
+  if (rows.length > 1) {
+    // Handle complex pattern
+  }
+}
+```
+
+**Note:** Try to avoid this. Multiple content patterns increase complexity. Work with content authors to agree on a single, clear content model when possible.
+
+## Code Style
+
+This project uses Airbnb ESLint configuration with some modifications:
+
+**Key rules:**
+- Use ES6+ features (const, let, arrow functions, template literals)
+- Always include `.js` extension in imports: `import { foo } from './bar.js';`
+- Use single quotes for strings
+- No semicolons are enforced, but be consistent
+- Use 2-space indentation
+- Unix line endings (LF)
+- Parameter reassignment is allowed for properties: `block.foo = 'bar'`
+
+**Naming conventions:**
+- Use camelCase for variables and functions
+- Use PascalCase for classes
+- Use UPPER_CASE for constants
+
+**File naming:**
+- Block files must match block name: `my-block.js`, `my-block.css`
+- Use kebab-case for file names
+
+## Performance Considerations
+
+**Minimize work in the decoration function:**
+- Only do what's necessary to achieve the desired structure
+- Defer expensive operations (heavy calculations, large data fetching) when possible
+- Remember: blocks in the first section load eagerly and affect LCP
+
+**Example - defer heavy work:**
+```javascript
+export default async function decorate(block) {
+  // Do minimal initial decoration
+  block.classList.add('initialized');
+
+  // Defer expensive work
+  setTimeout(async () => {
+    const data = await fetchHeavyData();
+    renderComplexUI(block, data);
+  }, 0);
+}
+```
+
+**Example - use Intersection Observer to load only when viewed:**
+```javascript
+export default async function decorate(block) {
+  // Useful for embeds like YouTube videos, heavy widgets, etc.
+  const observer = new IntersectionObserver((entries) => {
+    if (entries[0].isIntersecting) {
+      observer.disconnect();
+      // Load heavy content only when block is visible
+      loadYouTubeEmbed(block);
+    }
+  });
+
+  observer.observe(block);
+}
+```
+
+## Helper Functions
+
+You can import helpful utilities from `scripts/aem.js`:
+
+```javascript
+import {
+  buildBlock,
+  decorateBlock,
+  loadBlock,
+  loadCSS,
+  loadScript,
+  toClassName,
+  getMetadata,
+  createOptimizedPicture,
+} from '../../scripts/aem.js';
+```
+
+Common helpers:
+- `toClassName(text)` - Converts text to a valid CSS class name
+- `getMetadata(name)` - Gets page metadata value
+- `loadCSS(href)` - Loads a CSS file and returns a promise that resolves when loaded
+- `loadScript(url, attrs)` - Loads a JavaScript file with optional attributes (async, type, etc.)
+- `createOptimizedPicture(src, alt, eager, breakpoints)` - Creates a responsive picture element with optimized images
+- `buildBlock(name, cells)` - Programmatically creates a block DOM structure. **Note:** For the block to fully display, it must be decorated and loaded after being built and added to the DOM. In most cases, you'll need to call `decorateBlock()` and `loadBlock()` after building.
+
+**Example - building and loading a block:**
+```javascript
+// Create the block
+const myBlock = buildBlock('my-block', [[document.createElement('p')]]);
+
+// Blocks must be wrapped in a div and placed inside a section
+const wrapper = document.createElement('div');
+wrapper.append(myBlock);
+
+// Add to a section (either find existing or create new)
+const section = document.querySelector('main .section') || document.querySelector('main > div');
+section.append(wrapper);
+
+// Decorate and load (required in most contexts)
+decorateBlock(myBlock);
+await loadBlock(myBlock);
+```
+
+See `scripts/aem.js` for the complete list (but remember: NEVER MODIFY aem.js).
diff --git a/.claude/.skills/code-review/SKILL.md b/.claude/.skills/code-review/SKILL.md
new file mode 100644
index 0000000..dbe6b5d
--- /dev/null
+++ b/.claude/.skills/code-review/SKILL.md
@@ -0,0 +1,1235 @@
+---
+name: Code Review
+description: Review code for AEM Edge Delivery Services projects. Use at the end of development (before PR) for self-review, or to review pull requests. Validates code quality, performance, accessibility, and adherence to EDS best practices.
+---
+
+# Code Review
+
+Review code for AEM Edge Delivery Services (EDS) projects following established coding standards, performance requirements, and best practices.
+
+## When to Use This Skill
+
+This skill supports **two modes** of operation:
+
+### Mode 1: Self-Review (End of Development)
+
+Use this mode when you've finished writing code and want to review it before committing or opening a PR. This is the recommended workflow integration point.
+
+**When to invoke:**
+- After completing implementation in the **content-driven-development** workflow (between Step 5 and Step 6)
+- Before running `git add` and `git commit`
+- When you want to catch issues early, before they reach PR review
+
+**How to invoke:**
+- Automatically: CDD workflow invokes this skill after implementation
+- Manually: `/code-review` (reviews uncommitted changes in working directory)
+
+**What it does:**
+- Reviews all modified/new files in working directory
+- Checks code quality, patterns, and best practices
+- Validates against EDS standards
+- Identifies issues to fix before committing
+- Captures visual screenshots for validation
+
+### Mode 2: PR Review
+
+Use this mode to review an existing pull request (your own or someone else's).
+
+**When to invoke:**
+- Reviewing a PR before merge
+- Automated review via GitHub Actions workflow
+- Manual review of a specific PR
+
+**How to invoke:**
+- Manually: `/code-review <PR-number>` or `/code-review <PR-URL>`
+- Automated: Via GitHub workflow on `pull_request` event
+
+**What it does:**
+- Fetches PR diff and changed files
+- Validates PR structure (preview URLs, description)
+- Reviews code quality
+- Posts review comment with findings and screenshots
+- Provides actionable fixes via GitHub suggestions or commits
+- Explains reasoning for each fix with references to review feedback
+
+---
+
+## Review Workflow
+
+### Step 1: Identify Review Mode and Gather Context
+
+**For Self-Review (no PR number provided):**
+
+```bash
+# See what files have been modified
+git status
+
+# See the actual changes
+git diff
+
+# For staged changes
+git diff --staged
+```
+
+**Understand the scope:**
+- What files were modified?
+- What type of change is this? (new block, bug fix, feature, styling, refactor)
+- What is the test content URL? (from CDD workflow)
+
+**For PR Review (PR number provided):**
+
+```bash
+# Get PR details
+gh pr view <PR-number> --json title,body,author,baseRefName,headRefName,files,additions,deletions
+
+# Get changed files
+gh pr diff <PR-number>
+
+# Get PR comments and reviews
+gh api repos/{owner}/{repo}/pulls/<PR-number>/comments
+gh api repos/{owner}/{repo}/pulls/<PR-number>/reviews
+```
+
+**Understand the scope:**
+- What type of change is this? (new block, bug fix, feature, styling, refactor)
+- What files are modified?
+- Is there a related GitHub issue?
+- Are there test/preview URLs provided?
+
+---
+
+### Step 2: Validate Structure (PR Review Mode Only)
+
+**Skip this step for Self-Review mode.**
+
+**Required elements for PRs (MUST HAVE):**
+
+| Element | Requirement | Check |
+|---------|-------------|-------|
+| Preview URLs | Before/After URLs showing the change | Required |
+| Description | Clear explanation of what changed and why | Required |
+| Scope alignment | Changes match PR title and description | Required |
+| Issue reference | Link to GitHub issue (if applicable) | Recommended |
+
+**Preview URL format:**
+- Before: `https://main--{repo}--{owner}.aem.page/{path}`
+- After: `https://{branch}--{repo}--{owner}.aem.page/{path}`
+
+**Flag if missing:**
+- Missing preview URLs (blocks automated PSI checks)
+- Vague or missing description
+- Scope creep (changes unrelated to stated purpose)
+- Missing issue reference for bug fixes
+
+---
+
+### Step 3: Code Quality Review
+
+#### 3.1 JavaScript Review
+
+**Linting & Style:**
+- [ ] Code passes ESLint (airbnb-base configuration)
+- [ ] No `eslint-disable` comments without justification
+- [ ] No global `eslint-disable` directives
+- [ ] ES6+ features used appropriately
+- [ ] `.js` extensions included in imports
+
+**Architecture:**
+- [ ] No frameworks in critical rendering path (LCP/TBT impact)
+- [ ] Third-party libraries loaded via `loadScript()` in blocks, not `head.html`
+- [ ] Consider `IntersectionObserver` for heavy libraries
+- [ ] `aem.js` is NOT modified (submit upstream PRs for improvements)
+- [ ] No build steps introduced without team consensus
+
+**Code Patterns:**
+- [ ] Existing DOM elements re-used, not recreated
+- [ ] Block selectors scoped appropriately
+- [ ] No hardcoded values that should be configurable
+- [ ] Console statements cleaned up (no debug logs)
+- [ ] Proper error handling where needed
+
+**Common Issues to Flag:**
+```javascript
+// BAD: CSS in JavaScript
+element.style.backgroundColor = 'blue';
+
+// GOOD: Use CSS classes
+element.classList.add('highlighted');
+
+// BAD: Hardcoded configuration
+const temperature = 0.7;
+
+// GOOD: Use config or constants
+const { temperature } = CONFIG;
+
+// BAD: Global eslint-disable
+/* eslint-disable */
+
+// GOOD: Specific, justified disables
+/* eslint-disable-next-line no-console -- intentional debug output */
+```
+
+#### 3.2 CSS Review
+
+**Linting & Style:**
+- [ ] Code passes Stylelint (standard configuration)
+- [ ] No `!important` unless absolutely necessary (with justification)
+- [ ] Property order maintained (don't reorder in functional PRs)
+
+**Scoping & Selectors:**
+- [ ] All selectors scoped to block: `.{block-name} .selector` or `main .{block-name}`
+- [ ] Private classes/variables prefixed with block name
+- [ ] Simple, readable selectors (add classes rather than complex selectors)
+- [ ] ARIA attributes used for styling when appropriate (`[aria-expanded="true"]`)
+
+**Responsive Design:**
+- [ ] Mobile-first approach (base styles for mobile, media queries for larger)
+- [ ] Standard breakpoints used: `600px`, `900px`, `1200px` (all `min-width`)
+- [ ] No mixing of `min-width` and `max-width` queries
+- [ ] Layout works across all viewports
+
+**Frameworks & Preprocessors:**
+- [ ] No CSS preprocessors (Sass, Less, PostCSS) without team consensus
+- [ ] No CSS frameworks (Tailwind, etc.) without team consensus
+- [ ] Native CSS features used (supported by evergreen browsers)
+
+**Common Issues to Flag:**
+```css
+/* BAD: Unscoped selector */
+.title { color: red; }
+
+/* GOOD: Scoped to block */
+main .my-block .title { color: red; }
+
+/* BAD: !important abuse */
+.button { color: white !important; }
+
+/* GOOD: Increase specificity instead */
+main .my-block .button { color: white; }
+
+/* BAD: Mixed breakpoint directions */
+@media (max-width: 600px) { }
+@media (min-width: 900px) { }
+
+/* GOOD: Consistent mobile-first */
+@media (min-width: 600px) { }
+@media (min-width: 900px) { }
+
+/* BAD: CSS in JS patterns */
+element.innerHTML = '<style>.foo { color: red; }</style>';
+
+/* GOOD: Use external CSS files */
+```
+
+#### 3.3 HTML Review
+
+- [ ] Semantic HTML5 elements used appropriately
+- [ ] Proper heading hierarchy maintained
+- [ ] Accessibility attributes present (ARIA labels, alt text)
+- [ ] No inline styles or scripts in `head.html`
+- [ ] Marketing tech NOT in `<head>` (performance impact)
+
+---
+
+### Step 4: Performance Review
+
+**Critical Requirements:**
+- [ ] Lighthouse scores green (ideally 100) for mobile AND desktop
+- [ ] No third-party libraries in critical path (`head.html`)
+- [ ] No layout shifts introduced (CLS impact)
+- [ ] Images optimized and lazy-loaded appropriately
+
+**Performance Checklist:**
+- [ ] Heavy operations use `IntersectionObserver` or delayed loading
+- [ ] No synchronous operations blocking render
+- [ ] Bundle size reasonable (no minification unless measurable Lighthouse gain)
+- [ ] Fonts loaded efficiently
+
+**Preview URL Verification:**
+If preview URLs provided, check:
+- PageSpeed Insights scores
+- Core Web Vitals (LCP, CLS, INP)
+- Mobile and desktop performance
+
+---
+
+### Step 5: Visual Validation with Screenshots
+
+**Purpose:** Capture screenshots of the preview URL to validate visual appearance. For self-review, this confirms your changes look correct before committing. For PR review, this provides visual evidence in the review comment.
+
+**When to capture screenshots:**
+- Always capture at least one screenshot of the primary changed page/component
+- For responsive changes, capture mobile (375px), tablet (768px), and desktop (1200px)
+- For visual changes (styling, layout), capture before AND after for comparison
+- For block changes, capture the specific block area
+
+**How to capture screenshots:**
+
+**Option 1: Playwright (Recommended for automation)**
+
+```javascript
+// capture-screenshots.js
+import { chromium } from 'playwright';
+
+async function captureScreenshots(afterUrl, outputDir = './screenshots') {
+  const browser = await chromium.launch();
+  const page = await browser.newPage();
+
+  // Desktop screenshot
+  await page.setViewportSize({ width: 1200, height: 800 });
+  await page.goto(afterUrl, { waitUntil: 'networkidle' });
+  await page.waitForTimeout(1000); // Wait for animations
+  await page.screenshot({
+    path: `${outputDir}/desktop.png`,
+    fullPage: true
+  });
+
+  // Tablet screenshot
+  await page.setViewportSize({ width: 768, height: 1024 });
+  await page.screenshot({
+    path: `${outputDir}/tablet.png`,
+    fullPage: true
+  });
+
+  // Mobile screenshot
+  await page.setViewportSize({ width: 375, height: 667 });
+  await page.screenshot({
+    path: `${outputDir}/mobile.png`,
+    fullPage: true
+  });
+
+  // Optional: Capture specific block/element
+  const block = page.locator('.my-block');
+  if (await block.count() > 0) {
+    await block.screenshot({ path: `${outputDir}/block.png` });
+  }
+
+  await browser.close();
+
+  return {
+    desktop: `${outputDir}/desktop.png`,
+    tablet: `${outputDir}/tablet.png`,
+    mobile: `${outputDir}/mobile.png`
+  };
+}
+
+// Usage
+captureScreenshots('https://branch--repo--owner.aem.page/path');
+```
+
+**Option 2: Using MCP Browser Tools**
+
+If you have MCP browser or Playwright tools available:
+1. Navigate to the After preview URL
+2. Take screenshots at different viewport sizes
+3. Optionally take element-specific screenshots of changed blocks
+
+**Option 3: Manual capture with guidance**
+
+Instruct the reviewer or PR author to:
+1. Open the After preview URL
+2. Use browser DevTools to set viewport sizes
+3. Take screenshots and attach to PR
+
+**Uploading screenshots to GitHub:**
+
+```bash
+# Upload screenshot as PR comment with image
+# First, upload to a hosting service or use GitHub's image upload
+
+# Option A: Embed in PR comment (drag & drop in GitHub UI)
+gh pr comment <PR-number> --body "## Visual Preview
+
+### Desktop (1200px)
+![Desktop Screenshot](screenshot-url-or-drag-drop)
+
+### Mobile (375px)
+![Mobile Screenshot](screenshot-url-or-drag-drop)
+"
+
+# Option B: Use GitHub's attachment API (for automation)
+# Screenshots can be uploaded as part of the comment body
+```
+
+**Screenshot checklist:**
+- [ ] Primary page/component captured at desktop width
+- [ ] Mobile viewport captured (if responsive changes)
+- [ ] Specific block/component captured (if block changes)
+- [ ] Before/After comparison (if significant visual changes)
+- [ ] No sensitive data visible in screenshots
+- [ ] Screenshots uploaded and embedded in PR comment
+
+**Visual issues to look for:**
+- Layout breaks or misalignment
+- Text overflow or truncation
+- Image sizing or aspect ratio issues
+- Color/contrast problems (especially in dark mode)
+- Missing or broken icons
+- Responsive layout issues at breakpoints
+- Unexpected visual differences from main branch
+
+---
+
+### Step 6: Content & Authoring Review
+
+**Content Model (if applicable):**
+- [ ] Content structure author-friendly
+- [ ] Backward compatibility maintained with existing content
+- [ ] No breaking changes requiring content migration
+- [ ] New content features only available after preview/publish
+
+**Static Resources:**
+- [ ] No binaries/static assets committed (unless code-referenced)
+- [ ] User-facing strings sourced from content (placeholders, spreadsheets)
+- [ ] No hardcoded literals that should be translatable
+
+---
+
+### Step 7: Security Review
+
+- [ ] No sensitive data committed (API keys, passwords, secrets)
+- [ ] No XSS vulnerabilities (unsafe innerHTML, unsanitized user input)
+- [ ] No SQL injection or command injection vectors
+- [ ] CSP headers appropriate for tool pages
+- [ ] External links have `rel="noopener noreferrer"`
+
+---
+
+### Step 8: Generate Review Summary
+
+**Output depends on the review mode:**
+
+#### For Self-Review Mode (End of Development)
+
+Report findings directly to continue the development workflow:
+
+```markdown
+## Code Review Summary
+
+### Files Reviewed
+- `blocks/my-block/my-block.js` (new)
+- `blocks/my-block/my-block.css` (new)
+
+### Visual Validation
+![Desktop Screenshot](path/to/screenshot.png)
+
+✅ Layout renders correctly across viewports
+✅ No console errors
+✅ Responsive behavior verified
+
+### Issues Found
+
+#### Must Fix Before Committing
+- [ ] `blocks/my-block/my-block.js:45` - Remove console.log debug statement
+- [ ] `blocks/my-block/my-block.css:12` - Selector `.title` needs block scoping
+
+#### Recommendations
+- [ ] Consider using `loadScript()` for the external library
+
+### Ready to Commit?
+- [ ] All "Must Fix" issues resolved
+- [ ] Linting passes: `npm run lint`
+- [ ] Visual validation complete
+```
+
+**After self-review:** Fix any issues found, then proceed with committing and opening a PR.
+
+#### For PR Review Mode
+
+Structure the review comment for GitHub:
+
+```markdown
+## PR Review Summary
+
+### Overview
+[Brief summary of the PR and its purpose]
+
+### Preview URLs Validated
+- [ ] Before: [URL]
+- [ ] After: [URL]
+
+### Visual Preview
+
+#### Desktop (1200px)
+![Desktop Screenshot](url-or-embedded-image)
+
+#### Mobile (375px)
+![Mobile Screenshot](url-or-embedded-image)
+
+<details>
+<summary>Additional Screenshots</summary>
+
+#### Tablet (768px)
+![Tablet Screenshot](url-or-embedded-image)
+
+#### Block Detail
+![Block Screenshot](url-or-embedded-image)
+
+</details>
+
+### Visual Assessment
+- [ ] Layout renders correctly across viewports
+- [ ] No visual regressions from main branch
+- [ ] Colors and typography consistent
+- [ ] Images and icons display properly
+
+### Checklist Results
+
+#### Must Fix (Blocking)
+- [ ] [Critical issue with file:line reference]
+
+#### Should Fix (High Priority)
+- [ ] [Important issue with file:line reference]
+
+#### Consider (Suggestions)
+- [ ] [Nice-to-have improvement]
+
+### Detailed Findings
+
+#### [Category: e.g., JavaScript, CSS, Performance]
+**File:** `path/to/file.js:123`
+**Issue:** [Description of the issue]
+**Suggestion:** [How to fix it]
+```
+
+---
+
+### Step 9: Provide Actionable Fixes (PR Review Mode Only)
+
+**Skip this step for Self-Review mode** - in self-review, you fix issues directly in your working directory.
+
+After identifying issues in a PR review, provide actionable fixes to make it easier for the PR author to address them. **The goal is to provide one-click fixes whenever possible.**
+
+#### Quick Reference
+
+**PRIMARY METHOD: GitHub Suggestions** (use for ~70-80% of fixable issues)
+- One-click acceptance by PR author
+- Proper git attribution
+- Works for changes < 20 lines
+- Native GitHub UI integration
+
+**SECONDARY: Guidance Comments** (~20-30% of issues)
+- For subjective or architectural issues
+- When multiple approaches exist
+- "Consider" level suggestions
+
+**RARE: Fix Commits** (avoid unless necessary)
+- Only when suggestions won't work
+- Multi-file complex refactors
+- Changes requiring extensive testing
+
+---
+
+#### Decision Tree: When to Use Which Approach
+
+| Approach | When to Use | Examples |
+|----------|-------------|----------|
+| **GitHub Suggestions** (PRIMARY) | Any change that can be expressed as a code replacement | Remove console.log, fix typos, add comments, refactor selectors, update functions, add error handling |
+| **Fix Commits** (SECONDARY) | Changes that need testing, span many files, or are too large for suggestions | Complex multi-file refactors, security fixes requiring validation, changes >20 lines |
+| **Guidance Only** (FALLBACK) | Architectural changes, subjective improvements, or when multiple approaches exist | "Consider using IntersectionObserver", design pattern suggestions, performance optimizations |
+
+**IMPORTANT:** Always prefer GitHub Suggestions when possible - they provide the best user experience with one-click acceptance and proper git attribution.
+
+#### Approach 1: GitHub Inline Suggestions (PRIMARY APPROACH - Recommended)
+
+Use GitHub's native suggestion feature for most fixes. This provides the best user experience with **one-click acceptance** and proper git attribution.
+
+**When to use:**
+- ✅ ANY change that can be expressed as a line replacement
+- ✅ Single-line to multi-line changes (up to ~20 lines works well)
+- ✅ Clear, actionable fixes with known solutions
+- ✅ Independent changes that can be applied separately
+- ✅ Changes that don't require extensive testing before commit
+
+**When NOT to use:**
+- ❌ Changes requiring testing/validation before commit
+- ❌ Very large changes (>20 lines become unwieldy in GitHub UI)
+- ❌ Changes spanning many files (better as fix commits)
+- ❌ Subjective/architectural suggestions with multiple valid approaches
+
+**Benefits:**
+- 🚀 One-click acceptance by PR author
+- ✅ Proper co-author attribution in git history
+- 🎯 Batch multiple suggestions into single commit
+- 📱 Works in GitHub mobile app
+- ⚡ Zero copy/paste errors
+- 🔍 Clear before/after diff in GitHub UI
+
+**How to create suggestions:**
+
+GitHub suggestions are created using the Pull Request Reviews API with a special markdown syntax in the comment body:
+
+````markdown
+```suggestion
+// The corrected code here
+```
+````
+
+**Complete workflow with examples:**
+
+```bash
+# Step 1: Get PR information
+PR_NUMBER=196
+OWNER="adobe"
+REPO="helix-tools-website"
+
+# Get the current HEAD commit SHA (required for review API)
+COMMIT_SHA=$(gh api repos/$OWNER/$REPO/pulls/$PR_NUMBER --jq '.head.sha')
+
+# Step 2: Analyze the diff to find line positions
+# IMPORTANT: Use 'position' in the diff, NOT 'line' in the original file
+# Position is the line number in the unified diff output starting from the first diff hunk
+
+# Get the diff to understand positions
+gh pr diff $PR_NUMBER --repo $OWNER/$REPO > /tmp/pr-$PR_NUMBER.diff
+
+# Step 3: Create review JSON with suggestions
+# Each comment needs:
+# - path: file path relative to repo root
+# - position: line number IN THE DIFF (not in the file!)
+# - body: description + ```suggestion block
+
+cat > /tmp/review-suggestions.json <<JSON
+{
+  "commit_id": "$COMMIT_SHA",
+  "event": "COMMENT",
+  "comments": [
+    {
+      "path": "tools/page-status/diff.js",
+      "position": 58,
+      "body": "**Fix: Add XSS Safety Documentation** (BLOCKING)\\n\\nAdd a comment to document that this HTML injection is safe:\\n\\n\`\`\`suggestion\\n      const previewBodyHtml = previewDom.querySelector('body').innerHTML;\\n\\n      // XSS Safe: previewBodyHtml is sanitized by mdToDocDom from trusted admin API\\n      const newPageHtml = \\\`\\n\`\`\`\\n\\nThis addresses the security concern by making it clear that XSS has been considered."
+    },
+    {
+      "path": "tools/page-status/diff.js",
+      "position": 6,
+      "body": "**Fix: Improve Error Handling Pattern**\\n\\nAdd an \\\`ok\\\` flag for more consistent error handling:\\n\\n\`\`\`suggestion\\n  * @returns {Promise<{content: string|null, status: number, ok: boolean}>} Content, status, and success flag\\n\`\`\`"
+    },
+    {
+      "path": "tools/page-status/diff.js",
+      "position": 12,
+      "body": "**Fix: Return consistent result object**\\n\\n\`\`\`suggestion\\n    return { content: null, status: res.status, ok: false };\\n\`\`\`"
+    },
+    {
+      "path": "tools/page-status/diff.js",
+      "position": 16,
+      "body": "**Fix: Include ok flag in success case**\\n\\n\`\`\`suggestion\\n  return { content, status: res.status, ok: true };\\n\`\`\`"
+    },
+    {
+      "path": "tools/page-status/diff.css",
+      "position": 41,
+      "body": "**Fix: Remove stylelint-disable by refactoring selector**\\n\\nUse \\\`.diff-new-page\\\` as intermediate selector to avoid specificity conflict:\\n\\n\`\`\`suggestion\\n.page-diff .diff-new-page .doc-diff-side-header {\\n  padding: var(--spacing-s) var(--spacing-m);\\n\`\`\`"
+    }
+  ]
+}
+JSON
+
+# Step 4: Submit the review with all suggestions at once
+gh api \
+  --method POST \
+  -H "Accept: application/vnd.github+json" \
+  repos/$OWNER/$REPO/pulls/$PR_NUMBER/reviews \
+  --input /tmp/review-suggestions.json
+
+# Step 5: Add a friendly summary comment
+gh pr comment $PR_NUMBER --repo $OWNER/$REPO --body "$(cat <<'EOF'
+## ✨ One-Click Fix Suggestions Added!
+
+I've added **GitHub Suggestions** that you can apply with a single click! 
+
+### How to Apply
+
+1. Go to the **Files changed** tab
+2. Find the inline comments with suggestions
+3. Click **"Commit suggestion"** to apply individually
+4. Or click **"Add suggestion to batch"** on multiple, then **"Commit suggestions"** to batch
+
+### What's Included
+
+- ✅ [BLOCKING] XSS safety documentation
+- ✅ Error handling improvements  
+- ✅ CSS selector refactoring (removes linter disables)
+
+After applying, run \`npm run lint\` to verify all checks pass!
+EOF
+)"
+
+echo "✅ Review with suggestions posted successfully!"
+echo "View at: https://github.com/$OWNER/$REPO/pull/$PR_NUMBER"
+```
+
+**Key points:**
+- **Use `position` (diff position) NOT `line` (file line number)** - This is critical!
+- The `position` is the line number in the unified diff output, counting from the first `@@` hunk marker
+- Multiple suggestions in one review enables batch application
+- Each suggestion creates a properly attributed co-authored commit when accepted
+- Escape special characters in JSON (quotes, backticks, newlines)
+- Always include context in the body before the suggestion block
+
+**How to determine the correct `position` value:**
+
+The `position` is the line number in the unified diff, NOT the line number in the file. Here's how to find it:
+
+1. **Get the diff:**
+   ```bash
+   gh pr diff <PR-number> > pr.diff
+   ```
+
+2. **Open the diff and count lines** from the top, including:
+   - File headers (`--- a/file` and `+++ b/file`)
+   - Hunk headers (`@@ -old,lines +new,lines @@`)
+   - Context lines (no prefix or space prefix)
+   - Removed lines (- prefix)
+   - Added lines (+ prefix)
+
+3. **The position is the line number of the ADDED line** you want to comment on
+
+**Example from actual diff:**
+```diff
+--- a/tools/page-status/diff.js
++++ b/tools/page-status/diff.js
+  async function fetchContent(url) {
+    const res = await fetch(url);
+-   if (!res.ok) throw new Error(`Failed to fetch ${url}: ${res.status}`);
+-   return res.text();
++   if (!res.ok) {
++     return { content: null, status: res.status };  ← Position 12 (counting from top)
++   }
+```
+
+**Best practices for suggestions:**
+- Keep suggestions focused and atomic (one fix per suggestion)
+- **Always include context** - explain WHY the change is needed before the suggestion block
+- Test the suggestion mentally or locally before posting
+- Only suggest changes you're confident are correct
+- Include surrounding lines for context (GitHub shows ~3 lines of context)
+- Use `position` in the diff, not `line` in the file (critical!)
+- Batch related suggestions in one review for easier application
+- Add a friendly summary comment explaining how to apply
+- Format suggestion body with markdown (bold headers, inline code)
+- Escape special characters properly in JSON (quotes, backticks, backslashes)
+
+#### Approach 2: Fix Commits (For Complex or Multi-File Fixes)
+
+For more complex fixes, create commits directly on the PR branch. This is especially useful when:
+- Fixes span multiple files
+- Changes need to be tested together
+- Refactoring is required
+- You want to demonstrate the fix working
+
+**Prerequisites:**
+- Ensure you have write access to the repository or the PR is from a fork you can access
+- Verify the PR author has enabled maintainer edits (usually default for same-org PRs)
+
+**Workflow:**
+
+```bash
+# 1. Get PR branch information
+PR_INFO=$(gh pr view <PR-number> --json headRefName,headRepository,headRepositoryOwner)
+BRANCH=$(echo $PR_INFO | jq -r '.headRefName')
+REPO_OWNER=$(echo $PR_INFO | jq -r '.headRepositoryOwner.login')
+
+# 2. Fetch the PR branch
+git fetch origin pull/<PR-number>/head:pr-<PR-number>
+
+# 3. Check out the PR branch
+git checkout pr-<PR-number>
+
+# 4. Make fixes based on review findings
+# Example: Fix CSS linter issues by refactoring selectors
+
+# 5. Test your fixes
+npm run lint
+# Run any relevant tests
+
+# 6. Commit with detailed reasoning
+git commit -m "$(cat <<'EOF'
+fix: refactor CSS selectors to eliminate linter disables
+
+Refactored CSS selectors in diff.css to resolve specificity conflicts
+without using stylelint-disable comments. Changes:
+
+- Increased specificity using .diff-new-page parent selector
+- Reordered rules to prevent descending specificity issues
+- Maintains same visual appearance and functionality
+
+Addresses code review feedback: https://github.com/{owner}/{repo}/pull/<PR-number>#issuecomment-XXXXX
+EOF
+)"
+
+# 7. Push to the PR branch
+git push origin pr-<PR-number>:$BRANCH
+
+# 8. Add comment to PR explaining what you fixed
+gh pr comment <PR-number> --body "$(cat <<'EOF'
+## Fixes Applied
+
+I've pushed commits to address some of the review findings:
+
+### Commit 1: Refactor CSS selectors
+- ✅ Eliminated all `stylelint-disable` comments
+- ✅ Resolved specificity conflicts properly
+- ✅ Maintained visual appearance
+
+### Commit 2: Standardize error handling  
+- ✅ Updated fetchContent to return consistent result objects
+- ✅ Updated all callers to use new pattern
+- ✅ Added JSDoc for clarity
+
+### Still Need Action From You:
+- [ ] **[BLOCKING]** Add XSS safety comment (see suggestion in review)
+- [ ] Consider extracting renderDiffPanel helper (optional)
+
+All linting passes now. Please review the commits and address the remaining item.
+EOF
+)"
+```
+
+**Commit message format for fixes:**
+
+```
+fix: <short description>
+
+<Detailed explanation of what was fixed and why>
+
+Changes:
+- <specific change 1>
+- <specific change 2>
+
+Addresses review feedback: <link to review comment>
+```
+
+#### Approach 3: Hybrid Approach (RECOMMENDED FOR MOST PRs)
+
+**For the majority of PRs, use this hybrid strategy:**
+
+1. **GitHub suggestions** for all fixable issues (primary method)
+2. **Guidance/comments** for subjective or architectural issues
+3. **Fix commits** only for very complex multi-file refactors
+
+**Typical workflow:**
+
+```bash
+# 1. Post comprehensive review comment with summary (from Step 8)
+gh pr comment <PR-number> --repo {owner}/{repo} --body "<detailed review summary>"
+
+# 2. Submit a review with GitHub suggestions for ALL fixable issues
+# (Create JSON as shown in Approach 1 with all suggestions)
+gh api POST repos/{owner}/{repo}/pulls/<PR-number>/reviews \
+  --input /tmp/review-suggestions.json
+
+# 3. Add a friendly summary about the suggestions
+gh pr comment <PR-number> --repo {owner}/{repo} --body "$(cat <<'EOF'
+## ✨ One-Click Suggestions Added!
+
+I've added GitHub Suggestions for the fixable issues:
+- ✅ [BLOCKING] Security documentation
+- ✅ Error handling improvements
+- ✅ CSS selector refactoring
+
+Go to **Files changed** tab and click **"Commit suggestion"** to apply!
+EOF
+)"
+
+# 4. For subjective/architectural issues, add guidance comments separately
+# (Only if needed - most issues should have suggestions)
+```
+
+**Real-world example distribution:**
+
+For a typical PR with 10 issues:
+- **GitHub suggestions**: 7-8 issues (concrete fixes)
+- **Guidance comments**: 2-3 issues (architectural, subjective, or "consider" level)
+- **Fix commits**: 0-1 (only if critically needed)
+
+**This approach provides:**
+- ✅ Maximum ease of use (one-click fixes)
+- ✅ Clear distinction between concrete fixes and suggestions
+- ✅ Reduced review cycles
+- ✅ Better PR author experience
+
+#### Real-World Example
+
+**PR #196: Support unpublished pages in diff tool**
+
+Issues identified in review:
+1. XSS safety documentation needed (BLOCKING)
+2. Four CSS stylelint-disable comments (should fix)
+3. Inconsistent error handling (should fix)
+4. CSS variable fallback inconsistency (optional)
+
+**Action taken:**
+```bash
+# Created two reviews with 9 total GitHub Suggestions
+# - 4 suggestions for diff.js (XSS comment, error handling)
+# - 5 suggestions for diff.css (selector refactoring)
+
+# Posted friendly summary comment explaining one-click application
+
+# Result: PR author can fix all issues in ~30 seconds vs 5-10 minutes of manual work
+```
+
+**View the actual implementation:**
+- JavaScript suggestions: https://github.com/adobe/helix-tools-website/pull/196#pullrequestreview-3747855930
+- CSS suggestions: https://github.com/adobe/helix-tools-website/pull/196#pullrequestreview-3747857266
+- Summary comment: https://github.com/adobe/helix-tools-website/pull/196#issuecomment-3843945119
+
+**Time saved:**
+- Traditional review: Author spends 5-10 minutes copying code, editing files, testing
+- With suggestions: Author spends 30 seconds clicking "Commit suggestions"
+- **Time savings: 90%+ reduction in fix application time**
+
+#### Guidelines for Choosing Approach
+
+**Use GitHub Suggestions when:** (DEFAULT - use this ~70-80% of the time)
+- ✅ You know the exact fix needed
+- ✅ Change is < 20 lines (works well in GitHub UI)
+- ✅ Fix is objective and unambiguous
+- ✅ Can be applied without extensive testing
+- ✅ Independent of other changes
+- ✅ **Examples:** Add comments, remove debug code, fix typos, refactor selectors, update error handling, add JSDoc, fix linting issues
+
+**Use Fix Commits when:** (RARE - use only when suggestions won't work)
+- ✅ Changes span many files (>5 files)
+- ✅ Complex refactoring requiring testing
+- ✅ Changes are interdependent and must be tested together
+- ✅ Security fixes that need immediate attention and validation
+- ✅ You're already working on the PR branch for other reasons
+- ✅ **Examples:** Large refactors, multi-file renames, complex security patches
+
+**Use Guidance Only when:** (~20-30% of issues)
+- ✅ Architectural decisions needed
+- ✅ Multiple valid approaches exist
+- ✅ Requires domain knowledge or context from PR author
+- ✅ Subjective improvements ("Consider", "Think about")
+- ✅ Performance optimizations with trade-offs
+- ✅ **Examples:** "Consider using IntersectionObserver", "You might want to extract this to a util", "Have you thought about caching?"
+
+**Decision flowchart:**
+```
+Issue identified
+    ↓
+Do I know the exact fix? ──NO──→ Use Guidance
+    ↓ YES
+Is it < 20 lines? ──NO──→ Use Fix Commit or Guidance
+    ↓ YES
+Use GitHub Suggestion ✅ (BEST OPTION)
+```
+
+#### Quality Standards for Fixes
+
+**Before posting suggestions or commits:**
+
+1. **Verify correctness:** Test locally or mentally verify the fix is correct
+2. **Check scope:** Ensure your fix doesn't introduce new issues
+3. **Maintain style:** Match existing code style and patterns
+4. **Run linters:** Ensure fixes don't break linting
+5. **Be respectful:** Frame fixes as helpful suggestions, not criticism
+6. **Link context:** Reference the review comment explaining WHY
+
+**Don't:**
+- Don't fix issues outside the PR scope
+- Don't change code style unrelated to the issue
+- Don't add features or enhancements
+- Don't push commits without explaining what you fixed
+- Don't fix subjective issues without discussion
+
+#### Troubleshooting GitHub Suggestions
+
+**Common issues and solutions:**
+
+| Problem | Cause | Solution |
+|---------|-------|----------|
+| "Validation Failed: line could not be resolved" | Used `line` instead of `position` | Use `position` (diff line number) not `line` (file line number) |
+| Suggestion doesn't appear inline | Wrong position value | Count lines in the diff carefully, including headers |
+| Can't apply suggestion | Merge conflict or branch updated | Author needs to update branch first |
+| Suggestion formatting broken | Unescaped JSON characters | Escape quotes, backticks, newlines in JSON |
+| "Invalid commit_id" | Used old commit SHA | Get current HEAD SHA before creating review |
+
+**How to verify your review before posting:**
+
+```bash
+# 1. Validate JSON syntax
+cat /tmp/review-suggestions.json | jq . > /dev/null && echo "✅ Valid JSON"
+
+# 2. Check position values against diff
+gh pr diff <PR-number> > pr.diff
+# Manually verify each position value in your JSON matches an added line
+
+# 3. Test with one suggestion first
+# Before posting 10 suggestions, test with 1 to ensure positions are correct
+```
+
+#### Success Criteria
+
+A good fix provision should:
+- [ ] **Use GitHub Suggestions as the primary method** (for ~70-80% of fixable issues)
+- [ ] Make it easy for the author to address issues (one-click accept)
+- [ ] Provide working, tested code (not untested suggestions)
+- [ ] Explain the reasoning behind each fix in the comment body
+- [ ] Reference the original review feedback from Step 8
+- [ ] Be respectful and collaborative in tone
+- [ ] Focus only on issues identified in the review
+- [ ] Not introduce new issues or regressions
+- [ ] Include a friendly summary comment explaining how to apply suggestions
+- [ ] Use proper `position` values (diff lines, not file lines)
+- [ ] Batch related suggestions in one review for efficient application
+
+---
+
+### Quick Start Template
+
+**Copy this template to quickly create a review with GitHub Suggestions:**
+
+```bash
+#!/bin/bash
+# Quick script to create GitHub Suggestions for PR review
+
+PR_NUMBER=YOUR_PR_NUMBER
+OWNER="adobe"
+REPO="helix-tools-website"
+
+# Get commit SHA
+COMMIT_SHA=$(gh api repos/$OWNER/$REPO/pulls/$PR_NUMBER --jq '.head.sha')
+echo "✅ PR Head SHA: $COMMIT_SHA"
+
+# Create review JSON
+cat > /tmp/review-$PR_NUMBER.json <<JSON
+{
+  "commit_id": "$COMMIT_SHA",
+  "event": "COMMENT",
+  "comments": [
+    {
+      "path": "path/to/file.js",
+      "position": DIFF_LINE_NUMBER,
+      "body": "**Fix: Issue Title**\\n\\nExplanation of the issue.\\n\\n\`\`\`suggestion\\nYour fixed code here\\n\`\`\`\\n\\nReasoning for the fix."
+    }
+  ]
+}
+JSON
+
+# Submit review
+gh api POST repos/$OWNER/$REPO/pulls/$PR_NUMBER/reviews \
+  --input /tmp/review-$PR_NUMBER.json
+
+# Add summary comment
+gh pr comment $PR_NUMBER --repo $OWNER/$REPO --body "✨ GitHub Suggestions added! Go to **Files changed** tab and click **Commit suggestion** to apply."
+
+echo "✅ Review posted! View at: https://github.com/$OWNER/$REPO/pull/$PR_NUMBER"
+```
+
+**To use:**
+1. Set `PR_NUMBER`, `OWNER`, `REPO`
+2. Replace the comments array with your actual suggestions
+3. Run the script
+
+---
+
+## Review Priority Levels
+
+### Must Fix (Blocking)
+Issues that MUST be resolved before merge:
+- Missing preview URLs
+- Linting failures
+- Security vulnerabilities
+- Breaking existing functionality
+- Performance regressions (Lighthouse score drop)
+- Accessibility violations
+- Modifications to `aem.js`
+
+### Should Fix (High Priority)
+Issues that SHOULD be resolved:
+- `!important` usage without justification
+- Unscoped CSS selectors
+- Hardcoded values that should be configurable
+- Missing error handling
+- Console statements left in code
+- CSS in JavaScript
+
+### Consider (Suggestions)
+Improvements to consider:
+- Code organization
+- Naming conventions
+- Documentation
+- Additional test coverage
+- Modern API usage opportunities
+
+---
+
+## Common Review Patterns
+
+Based on actual PR reviews, watch for these patterns:
+
+### CSS Issues
+- **"No CSS in JS, please"** - Inline styles should use CSS classes
+- **"Use proper CSS"** - Avoid style manipulation in JavaScript
+- **"Do we need the `!important`?"** - Strong preference against `!important`
+- **"Solvable with more CSS specificity"** - Increase specificity instead of `!important`
+
+### JavaScript Issues
+- **"Why is it hardcoded here?"** - Configuration should be externalized
+- **"No global eslint-disable directives"** - Specific, justified disables only
+- **"Clean up console messages"** - Remove debug logging
+- **"Use proper feature (e.g., decorateIcons, loadScript)"** - Leverage existing utilities
+
+### Architecture Issues
+- **"Use existing patterns"** - Check if similar functionality exists
+- **"Consider IntersectionObserver"** - For lazy loading
+- **"Extract and align design tokens"** - Use CSS custom properties
+
+### Content Issues
+- **"Check the type in content config"** - Validate against expected schema
+- **"Is this feature needed?"** - Question value vs complexity
+
+---
+
+## Review Response Templates
+
+### Approval
+```markdown
+## Approved
+
+Preview URLs verified and changes look good.
+
+### Visual Preview
+![Desktop Screenshot](url-or-embedded-image)
+
+<details>
+<summary>Mobile View</summary>
+
+![Mobile Screenshot](url-or-embedded-image)
+
+</details>
+
+**Verified:**
+- [x] Code quality and linting
+- [x] Performance (Lighthouse scores)
+- [x] Visual appearance (screenshots captured)
+- [x] Responsive behavior
+- [x] Accessibility basics
+
+[Any additional notes]
+```
+
+### Request Changes
+```markdown
+## Changes Requested
+
+### Blocking Issues
+[List with file:line references]
+
+### Suggestions
+[List of recommendations]
+
+Please address the blocking issues before merge.
+```
+
+### Comment
+```markdown
+## Review Notes
+
+[Non-blocking observations and questions]
+```
+
+---
+
+## Integration with GitHub Workflow
+
+When triggered via GitHub Actions, the skill should:
+
+1. **Receive:** PR number, repository info, event context
+2. **Execute:** Full review workflow above
+3. **Output:**
+   - Review comment on the PR
+   - Appropriate review status (approve/request-changes/comment)
+   - Summary posted as PR comment
+
+**GitHub Actions integration points:**
+- `pull_request` event triggers
+- `gh pr review` for posting reviews
+- `gh pr comment` for detailed feedback
+
+---
+
+## Resources
+
+### EDS-Specific Resources
+- **EDS Development Guidelines:** https://www.aem.live/docs/dev-collab-and-good-practices
+- **Performance Best Practices:** https://www.aem.live/developer/keeping-it-100
+- **Block Development:** https://www.aem.live/developer/block-collection
+- **David's Model:** https://www.aem.live/docs/davidsmodel
+
+### GitHub Code Review Resources
+- **GitHub Suggestions Documentation:** https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request
+- **Pull Request Reviews API:** https://docs.github.com/en/rest/pulls/reviews
+- **Review Comments API:** https://docs.github.com/en/rest/pulls/comments
+- **Creating Review Comments:** https://docs.github.com/en/rest/pulls/comments#create-a-review-comment-for-a-pull-request
+
+---
+
+## Success Criteria
+
+### For Self-Review Mode
+
+A complete self-review should:
+- [ ] Review all modified/new files
+- [ ] Check code against all quality criteria
+- [ ] Run linting and fix issues
+- [ ] Capture visual screenshots of test content
+- [ ] Verify responsive behavior across viewports
+- [ ] Identify issues to fix before committing
+- [ ] Confirm code is ready for commit and PR
+
+### For PR Review Mode
+
+A complete PR review should:
+- [ ] Validate all PR structure requirements (preview URLs, description)
+- [ ] Check code against all quality criteria
+- [ ] Verify performance requirements
+- [ ] Capture and include visual screenshots
+- [ ] Assess visual appearance for regressions
+- [ ] Assess content/authoring impact
+- [ ] Identify security concerns
+- [ ] Provide actionable feedback with specific references
+- [ ] Include screenshots in PR review comment
+- [ ] **Provide GitHub Suggestions for all fixable issues (primary method - ~70-80% of issues)**
+- [ ] **Submit suggestions as a single review for batch application**
+- [ ] **Include a friendly summary comment explaining how to apply suggestions**
+- [ ] **Explain reasoning for each fix in the suggestion comment body**
+- [ ] Use guidance comments only for subjective/architectural issues
+- [ ] Use fix commits only when suggestions won't work (rare)
+- [ ] Use appropriate review status (approve/request-changes/comment)
+
+---
+
+## Integration with Content-Driven Development
+
+This skill integrates with the **content-driven-development** workflow:
+
+```
+CDD Workflow:
+Step 1: Start dev server
+Step 2: Analyze & plan
+Step 3: Design content model
+Step 4: Identify/create test content
+Step 5: Implement (building-blocks skill)
+    └── testing-blocks skill (browser testing)
+        └── **code-review skill (self-review)** ← Invoke here
+Step 6: Lint & test
+Step 7: Final validation
+Step 8: Ship it (commit & PR)
+```
+
+**Recommended invocation point:** After implementation and testing-blocks skill complete, before final linting and committing.
+
+**What this catches before PR:**
+- Code quality issues
+- EDS pattern violations
+- Security concerns
+- Performance problems
+- Visual regressions
+
+**Benefits of self-review:**
+- Catch issues early (cheaper to fix)
+- Cleaner PRs with fewer review cycles
+- Learn from immediate feedback
+- Consistent code quality
diff --git a/.claude/.skills/code-review/resources/review-checklist.md b/.claude/.skills/code-review/resources/review-checklist.md
new file mode 100644
index 0000000..4c5d35c
--- /dev/null
+++ b/.claude/.skills/code-review/resources/review-checklist.md
@@ -0,0 +1,394 @@
+# PR Review Checklist
+
+Detailed checklist for reviewing Edge Delivery Services pull requests. Use this as a reference when reviewing PRs.
+
+## PR Structure Checklist
+
+### Required Elements
+
+| Item | Description | Priority |
+|------|-------------|----------|
+| Preview URL (Before) | URL showing current state on main branch | BLOCKING |
+| Preview URL (After) | URL showing changes on feature branch | BLOCKING |
+| PR Description | Clear explanation of what and why | BLOCKING |
+| Scope Alignment | Changes match title/description | HIGH |
+| Issue Reference | Link to GitHub issue (for bug fixes) | RECOMMENDED |
+| Test Plan | How changes were tested | RECOMMENDED |
+
+### Preview URL Format
+
+```
+Before: https://main--{repo}--{owner}.aem.page/{path-to-test-content}
+After: https://{branch}--{repo}--{owner}.aem.page/{path-to-test-content}
+```
+
+### PR Description Template
+
+```markdown
+## Description
+[What changed and why]
+
+## Related Issue
+Fix #<issue-number>
+
+## Test URLs
+- Before: https://main--{repo}--{owner}.aem.page/{path}
+- After: https://{branch}--{repo}--{owner}.aem.page/{path}
+
+## Types of Changes
+- [ ] Bug fix
+- [ ] New feature
+- [ ] Breaking change
+- [ ] Styling change
+- [ ] Refactor
+
+## Checklist
+- [ ] Linting passes
+- [ ] Tested across viewports
+- [ ] No console errors
+- [ ] Performance validated
+```
+
+---
+
+## JavaScript Checklist
+
+### Linting & Style
+
+| Check | Severity | Notes |
+|-------|----------|-------|
+| ESLint passes | BLOCKING | airbnb-base config |
+| No `eslint-disable` without justification | HIGH | Specific disables with comments OK |
+| No global `eslint-disable` | BLOCKING | Never acceptable |
+| ES6+ features | MEDIUM | Use modern syntax |
+| Import extensions | MEDIUM | Include `.js` extensions |
+
+### Architecture
+
+| Check | Severity | Notes |
+|-------|----------|-------|
+| No frameworks in critical path | HIGH | Affects LCP/TBT |
+| Libraries via `loadScript()` | HIGH | Not in head.html |
+| Consider IntersectionObserver | MEDIUM | For heavy libraries |
+| aem.js unmodified | BLOCKING | Submit upstream PRs |
+| No new build steps | HIGH | Without team consensus |
+
+### Code Patterns
+
+| Check | Severity | Notes |
+|-------|----------|-------|
+| Re-use existing DOM | MEDIUM | Don't recreate elements |
+| Scoped selectors | HIGH | Block-specific |
+| No hardcoded config | MEDIUM | Externalize values |
+| No debug console logs | HIGH | Clean up before merge |
+| Proper error handling | MEDIUM | Where appropriate |
+| No CSS in JS | HIGH | Use CSS classes |
+
+### Anti-Patterns to Flag
+
+```javascript
+// ANTI-PATTERN: Inline styles
+element.style.color = 'red';
+element.style.display = 'none';
+
+// PREFERRED: CSS classes
+element.classList.add('error');
+element.classList.add('hidden');
+
+// ANTI-PATTERN: innerHTML with styles
+el.innerHTML = '<style>.foo { color: red; }</style>';
+
+// PREFERRED: External CSS
+// Add styles to block's CSS file
+
+// ANTI-PATTERN: Hardcoded values
+const API_URL = 'https://api.example.com';
+const TIMEOUT = 5000;
+
+// PREFERRED: Configuration
+import { API_URL, TIMEOUT } from './config.js';
+
+// ANTI-PATTERN: Global disable
+/* eslint-disable */
+function doSomething() { }
+
+// PREFERRED: Specific disable with reason
+/* eslint-disable-next-line no-param-reassign -- DOM element modification */
+element.disabled = true;
+```
+
+---
+
+## CSS Checklist
+
+### Linting & Style
+
+| Check | Severity | Notes |
+|-------|----------|-------|
+| Stylelint passes | BLOCKING | Standard config |
+| No `!important` without justification | HIGH | Prefer specificity |
+| Property order preserved | MEDIUM | Don't reorder in functional PRs |
+
+### Scoping & Selectors
+
+| Check | Severity | Notes |
+|-------|----------|-------|
+| Block-scoped selectors | BLOCKING | `.block-name .selector` |
+| Prefixed private classes | MEDIUM | `block-name-private` |
+| Simple, readable selectors | MEDIUM | Add classes vs complex selectors |
+| ARIA attributes for states | LOW | `[aria-expanded="true"]` |
+
+### Responsive Design
+
+| Check | Severity | Notes |
+|-------|----------|-------|
+| Mobile-first approach | HIGH | Base = mobile, media queries for larger |
+| Standard breakpoints | HIGH | 600px, 900px, 1200px |
+| min-width only | MEDIUM | Don't mix with max-width |
+| All viewports tested | HIGH | Mobile, tablet, desktop |
+
+### Frameworks & Preprocessors
+
+| Check | Severity | Notes |
+|-------|----------|-------|
+| No Sass/Less/PostCSS | HIGH | Without team consensus |
+| No Tailwind/etc | HIGH | Without team consensus |
+| Native CSS features | MEDIUM | Evergreen browser support |
+
+### Anti-Patterns to Flag
+
+```css
+/* ANTI-PATTERN: Unscoped selector */
+.title {
+  font-size: 2rem;
+}
+
+/* PREFERRED: Block-scoped */
+main .hero .title {
+  font-size: 2rem;
+}
+
+/* ANTI-PATTERN: !important overuse */
+.button {
+  background: blue !important;
+  color: white !important;
+}
+
+/* PREFERRED: Higher specificity */
+main .hero .button {
+  background: blue;
+  color: white;
+}
+
+/* ANTI-PATTERN: Mixed breakpoint directions */
+@media (max-width: 599px) {
+  .block { padding: 1rem; }
+}
+@media (min-width: 900px) {
+  .block { padding: 2rem; }
+}
+
+/* PREFERRED: Consistent mobile-first */
+.block {
+  padding: 1rem; /* mobile */
+}
+@media (min-width: 600px) {
+  .block { padding: 1.5rem; }
+}
+@media (min-width: 900px) {
+  .block { padding: 2rem; }
+}
+
+/* ANTI-PATTERN: Complex, unreadable selectors */
+.block > div:first-child > ul > li:nth-child(2) > a {
+  color: red;
+}
+
+/* PREFERRED: Add semantic classes */
+.block .nav-link-secondary {
+  color: red;
+}
+```
+
+---
+
+## Performance Checklist
+
+| Check | Severity | Notes |
+|-------|----------|-------|
+| Lighthouse mobile green | BLOCKING | Ideally 100 |
+| Lighthouse desktop green | BLOCKING | Ideally 100 |
+| No libs in head.html | BLOCKING | Critical path |
+| No layout shifts | HIGH | CLS impact |
+| Images optimized | HIGH | Size and format |
+| IntersectionObserver for heavy ops | MEDIUM | Defer loading |
+| No sync blocking operations | HIGH | Render blocking |
+| Reasonable bundle size | MEDIUM | No unnecessary minification |
+
+### Performance Testing
+
+```bash
+# Check preview URLs with PSI
+# Mobile
+https://pagespeed.web.dev/analysis?url=https://{branch}--{repo}--{owner}.aem.page/{path}&form_factor=mobile
+
+# Desktop
+https://pagespeed.web.dev/analysis?url=https://{branch}--{repo}--{owner}.aem.page/{path}&form_factor=desktop
+```
+
+---
+
+## Content & Authoring Checklist
+
+| Check | Severity | Notes |
+|-------|----------|-------|
+| Author-friendly structure | MEDIUM | Easy to understand |
+| Backward compatibility | HIGH | Existing content works |
+| No breaking migrations | HIGH | Content shouldn't need updates |
+| No hardcoded strings | MEDIUM | Use placeholders/spreadsheets |
+| No committed binaries | HIGH | Unless code-referenced |
+
+---
+
+## Security Checklist
+
+| Check | Severity | Notes |
+|-------|----------|-------|
+| No secrets committed | BLOCKING | API keys, passwords, etc |
+| No XSS vulnerabilities | BLOCKING | Sanitize user input |
+| No innerHTML with user data | BLOCKING | Use textContent |
+| CSP headers (tools) | HIGH | For tool pages |
+| External links safe | MEDIUM | rel="noopener noreferrer" |
+| No eval() or Function() | BLOCKING | Code injection risk |
+
+### Security Patterns
+
+```javascript
+// ANTI-PATTERN: XSS vulnerability
+element.innerHTML = userInput;
+
+// PREFERRED: Safe text content
+element.textContent = userInput;
+
+// ANTI-PATTERN: Unsafe URL construction
+const url = `https://api.example.com?q=${userInput}`;
+
+// PREFERRED: URL encoding
+const url = `https://api.example.com?q=${encodeURIComponent(userInput)}`;
+
+// ANTI-PATTERN: Missing rel attribute
+<a href="https://external.com" target="_blank">Link</a>
+
+// PREFERRED: Secure external links
+<a href="https://external.com" target="_blank" rel="noopener noreferrer">Link</a>
+```
+
+---
+
+## Visual Validation Checklist
+
+### Screenshot Capture
+
+| Check | Severity | Notes |
+|-------|----------|-------|
+| Desktop screenshot captured | HIGH | 1200px viewport |
+| Mobile screenshot captured | HIGH | 375px viewport |
+| Tablet screenshot captured | MEDIUM | 768px viewport |
+| Block-specific screenshot | MEDIUM | If block changes |
+| Before/After comparison | MEDIUM | For visual changes |
+
+### Visual Assessment
+
+| Check | Severity | Notes |
+|-------|----------|-------|
+| Layout correct across viewports | HIGH | No broken layouts |
+| No visual regressions | HIGH | Compare to main branch |
+| Colors consistent | MEDIUM | With design system |
+| Typography correct | MEDIUM | Font sizes, weights |
+| Images display properly | HIGH | Size, aspect ratio |
+| Icons visible | HIGH | All icons render |
+| Dark mode works | MEDIUM | If applicable |
+| Animations smooth | LOW | If applicable |
+
+### Common Visual Issues
+
+| Issue | What to Look For |
+|-------|------------------|
+| Layout breaks | Elements overlapping, overflowing, misaligned |
+| Text issues | Truncation, overflow, wrong font, poor contrast |
+| Image problems | Wrong size, aspect ratio, missing, broken |
+| Responsive failures | Layout not adapting to viewport |
+| Spacing issues | Inconsistent margins, padding |
+| Color problems | Wrong colors, poor contrast, dark mode issues |
+| Icon issues | Missing, wrong size, wrong color |
+
+### Screenshot Commands
+
+```bash
+# Using the capture-screenshots.js utility
+cd .claude/skills/pr-review/scripts
+npm install
+node capture-screenshots.js <after-url> [before-url] [output-dir] [block-selector]
+
+# Examples
+node capture-screenshots.js https://branch--repo--owner.aem.page/path
+node capture-screenshots.js https://branch--repo--owner.aem.page/path https://main--repo--owner.aem.page/path
+node capture-screenshots.js https://branch--repo--owner.aem.page/path "" ./screenshots ".hero"
+```
+
+### Embedding Screenshots in PR Comment
+
+```markdown
+## Visual Preview
+
+### Desktop (1200px)
+![Desktop Screenshot](path/to/desktop.png)
+
+### Mobile (375px)
+![Mobile Screenshot](path/to/mobile.png)
+
+<details>
+<summary>Additional Screenshots</summary>
+
+### Tablet (768px)
+![Tablet Screenshot](path/to/tablet.png)
+
+### Block Detail
+![Block Screenshot](path/to/block.png)
+
+</details>
+```
+
+---
+
+## Accessibility Checklist
+
+| Check | Severity | Notes |
+|-------|----------|-------|
+| Semantic HTML | HIGH | Proper element usage |
+| Heading hierarchy | HIGH | Sequential, no skips |
+| Alt text for images | HIGH | Descriptive |
+| ARIA labels | MEDIUM | For interactive elements |
+| Keyboard navigation | HIGH | Tab order, focus states |
+| Color contrast | HIGH | WCAG AA compliance |
+| Focus visible | MEDIUM | Clear focus indicators |
+
+---
+
+## Review Severity Guide
+
+### BLOCKING (Must Fix)
+- PR cannot be merged until resolved
+- Examples: security issues, linting failures, missing preview URLs, breaking changes
+
+### HIGH (Should Fix)
+- Should be resolved before merge
+- Examples: performance issues, accessibility violations, code quality concerns
+
+### MEDIUM (Recommended)
+- Strong recommendation to fix
+- Examples: best practice violations, maintainability concerns
+
+### LOW (Consider)
+- Nice-to-have improvements
+- Examples: code style preferences, documentation enhancements
diff --git a/.claude/.skills/code-review/scripts/capture-screenshots.js b/.claude/.skills/code-review/scripts/capture-screenshots.js
new file mode 100644
index 0000000..0be0497
--- /dev/null
+++ b/.claude/.skills/code-review/scripts/capture-screenshots.js
@@ -0,0 +1,223 @@
+/**
+ * Screenshot capture utility for PR reviews
+ *
+ * Captures screenshots of preview URLs at multiple viewport sizes
+ * for visual validation during PR review.
+ *
+ * Usage:
+ *   node capture-screenshots.js <after-url> [before-url] [output-dir]
+ *
+ * Examples:
+ *   node capture-screenshots.js https://branch--repo--owner.aem.page/path
+ *   node capture-screenshots.js https://branch--repo--owner.aem.page/path https://main--repo--owner.aem.page/path
+ *   node capture-screenshots.js https://branch--repo--owner.aem.page/path "" ./my-screenshots
+ */
+
+import { chromium } from 'playwright';
+import { mkdir, writeFile } from 'fs/promises';
+import { existsSync } from 'fs';
+import path from 'path';
+
+// Viewport configurations
+const VIEWPORTS = {
+  mobile: { width: 375, height: 667, name: 'mobile' },
+  tablet: { width: 768, height: 1024, name: 'tablet' },
+  desktop: { width: 1200, height: 800, name: 'desktop' },
+};
+
+/**
+ * Capture screenshots of a URL at multiple viewport sizes
+ * @param {string} url - The URL to capture
+ * @param {string} outputDir - Directory to save screenshots
+ * @param {string} prefix - Filename prefix (e.g., 'after' or 'before')
+ * @param {string} [blockSelector] - Optional CSS selector to capture specific block
+ * @returns {Promise<Object>} - Paths to captured screenshots
+ */
+async function captureUrl(browser, url, outputDir, prefix, blockSelector = null) {
+  const page = await browser.newPage();
+  const screenshots = {};
+
+  try {
+    // Navigate and wait for page to load
+    await page.goto(url, { waitUntil: 'networkidle', timeout: 30000 });
+
+    // Wait for any animations to settle
+    await page.waitForTimeout(1500);
+
+    // Capture at each viewport size
+    for (const [key, viewport] of Object.entries(VIEWPORTS)) {
+      await page.setViewportSize({ width: viewport.width, height: viewport.height });
+      await page.waitForTimeout(500); // Wait for responsive adjustments
+
+      const filename = `${prefix}-${viewport.name}.png`;
+      const filepath = path.join(outputDir, filename);
+
+      await page.screenshot({
+        path: filepath,
+        fullPage: true,
+      });
+
+      screenshots[key] = filepath;
+      console.log(`  Captured ${viewport.name} (${viewport.width}x${viewport.height}): ${filename}`);
+    }
+
+    // Capture specific block if selector provided
+    if (blockSelector) {
+      const block = page.locator(blockSelector);
+      if (await block.count() > 0) {
+        // Use desktop viewport for block screenshot
+        await page.setViewportSize({ width: VIEWPORTS.desktop.width, height: VIEWPORTS.desktop.height });
+        await page.waitForTimeout(500);
+
+        const filename = `${prefix}-block.png`;
+        const filepath = path.join(outputDir, filename);
+
+        await block.first().screenshot({ path: filepath });
+        screenshots.block = filepath;
+        console.log(`  Captured block (${blockSelector}): ${filename}`);
+      } else {
+        console.log(`  Block selector "${blockSelector}" not found, skipping block screenshot`);
+      }
+    }
+  } finally {
+    await page.close();
+  }
+
+  return screenshots;
+}
+
+/**
+ * Generate markdown for PR comment with embedded screenshots
+ * @param {Object} afterScreenshots - Paths to "after" screenshots
+ * @param {Object} beforeScreenshots - Paths to "before" screenshots (optional)
+ * @returns {string} - Markdown content
+ */
+function generateMarkdown(afterScreenshots, beforeScreenshots = null) {
+  let markdown = '## Visual Preview\n\n';
+
+  if (beforeScreenshots) {
+    // Side-by-side comparison format
+    markdown += '### Comparison\n\n';
+    markdown += '| Viewport | Before | After |\n';
+    markdown += '|----------|--------|-------|\n';
+
+    for (const [key, afterPath] of Object.entries(afterScreenshots)) {
+      if (key === 'block') continue;
+      const beforePath = beforeScreenshots[key];
+      const viewportName = key.charAt(0).toUpperCase() + key.slice(1);
+      markdown += `| ${viewportName} | ![Before](${beforePath}) | ![After](${afterPath}) |\n`;
+    }
+
+    if (afterScreenshots.block || beforeScreenshots?.block) {
+      markdown += '\n### Block Detail\n\n';
+      if (beforeScreenshots?.block) {
+        markdown += `**Before:**\n![Before Block](${beforeScreenshots.block})\n\n`;
+      }
+      if (afterScreenshots.block) {
+        markdown += `**After:**\n![After Block](${afterScreenshots.block})\n`;
+      }
+    }
+  } else {
+    // After-only format
+    markdown += '### Desktop (1200px)\n';
+    markdown += `![Desktop Screenshot](${afterScreenshots.desktop})\n\n`;
+
+    markdown += '### Mobile (375px)\n';
+    markdown += `![Mobile Screenshot](${afterScreenshots.mobile})\n\n`;
+
+    markdown += '<details>\n<summary>Additional Screenshots</summary>\n\n';
+    markdown += '### Tablet (768px)\n';
+    markdown += `![Tablet Screenshot](${afterScreenshots.tablet})\n\n`;
+
+    if (afterScreenshots.block) {
+      markdown += '### Block Detail\n';
+      markdown += `![Block Screenshot](${afterScreenshots.block})\n\n`;
+    }
+    markdown += '</details>\n';
+  }
+
+  markdown += '\n### Visual Assessment\n';
+  markdown += '- [ ] Layout renders correctly across viewports\n';
+  markdown += '- [ ] No visual regressions from main branch\n';
+  markdown += '- [ ] Colors and typography consistent\n';
+  markdown += '- [ ] Images and icons display properly\n';
+
+  return markdown;
+}
+
+/**
+ * Main function
+ */
+async function main() {
+  const args = process.argv.slice(2);
+
+  if (args.length < 1) {
+    console.log('Usage: node capture-screenshots.js <after-url> [before-url] [output-dir] [block-selector]');
+    console.log('');
+    console.log('Examples:');
+    console.log('  node capture-screenshots.js https://branch--repo--owner.aem.page/path');
+    console.log('  node capture-screenshots.js https://branch--repo--owner.aem.page/path https://main--repo--owner.aem.page/path');
+    console.log('  node capture-screenshots.js https://branch--repo--owner.aem.page/path "" ./screenshots ".hero"');
+    process.exit(1);
+  }
+
+  const afterUrl = args[0];
+  const beforeUrl = args[1] && args[1] !== '' ? args[1] : null;
+  const outputDir = args[2] || './pr-screenshots';
+  const blockSelector = args[3] || null;
+
+  // Create output directory
+  if (!existsSync(outputDir)) {
+    await mkdir(outputDir, { recursive: true });
+  }
+
+  console.log('PR Screenshot Capture');
+  console.log('=====================');
+  console.log(`After URL: ${afterUrl}`);
+  if (beforeUrl) {
+    console.log(`Before URL: ${beforeUrl}`);
+  }
+  console.log(`Output directory: ${outputDir}`);
+  if (blockSelector) {
+    console.log(`Block selector: ${blockSelector}`);
+  }
+  console.log('');
+
+  const browser = await chromium.launch();
+
+  try {
+    // Capture "after" screenshots
+    console.log('Capturing "After" screenshots...');
+    const afterScreenshots = await captureUrl(browser, afterUrl, outputDir, 'after', blockSelector);
+
+    // Capture "before" screenshots if URL provided
+    let beforeScreenshots = null;
+    if (beforeUrl) {
+      console.log('\nCapturing "Before" screenshots...');
+      beforeScreenshots = await captureUrl(browser, beforeUrl, outputDir, 'before', blockSelector);
+    }
+
+    // Generate markdown
+    const markdown = generateMarkdown(afterScreenshots, beforeScreenshots);
+
+    // Save markdown file
+    const markdownPath = path.join(outputDir, 'visual-preview.md');
+    await writeFile(markdownPath, markdown);
+    console.log(`\nMarkdown saved to: ${markdownPath}`);
+
+    // Output markdown to console
+    console.log('\n--- PR Comment Markdown ---\n');
+    console.log(markdown);
+    console.log('--- End Markdown ---\n');
+
+    console.log('Screenshots captured successfully!');
+    console.log(`Files saved in: ${outputDir}`);
+  } finally {
+    await browser.close();
+  }
+}
+
+main().catch((error) => {
+  console.error('Error capturing screenshots:', error.message);
+  process.exit(1);
+});
diff --git a/.claude/.skills/code-review/scripts/package.json b/.claude/.skills/code-review/scripts/package.json
new file mode 100644
index 0000000..5f59bf1
--- /dev/null
+++ b/.claude/.skills/code-review/scripts/package.json
@@ -0,0 +1,12 @@
+{
+  "name": "code-review-scripts",
+  "version": "1.0.0",
+  "description": "Screenshot capture utilities for code review skill",
+  "type": "module",
+  "scripts": {
+    "capture": "node capture-screenshots.js"
+  },
+  "dependencies": {
+    "playwright": "^1.40.0"
+  }
+}
diff --git a/.claude/.skills/content-driven-development/SKILL.md b/.claude/.skills/content-driven-development/SKILL.md
new file mode 100644
index 0000000..1a4b4e1
--- /dev/null
+++ b/.claude/.skills/content-driven-development/SKILL.md
@@ -0,0 +1,294 @@
+---
+name: Using Content Driven Development
+description: Apply a Content Driven Development process to AEM Edge Delivery Services development. Use for all development tasks, including building new blocks, modifying existing blocks, making changes to core decoration functionality, etc.
+---
+
+# Using Content Driven Development (CDD)
+
+Content Driven Development is a mandatory process for AEM Edge Delivery Services development that prioritizes content and author needs over developer convenience. This skill orchestrates the development workflow to ensure code is built against real content with author-friendly content models.
+
+## Why Content-First Matters
+
+**Author needs come before developer needs.** When building for AEM Edge Delivery, authors are the primary users of the structures we create. Content models must be intuitive and easy to work with, even if that means more complex decoration code.
+
+**Efficiency through preparation.** Creating or identifying test content before coding provides:
+- **Immediate testing capability**: No need to stop development to create test content
+- **Better PR workflows**: Test content doubles as PR validation links for PSI checks
+- **Living documentation**: Test content often serves as author documentation and examples
+- **Fewer assumptions**: Real content reveals edge cases code-first approaches miss
+
+**NEVER start writing or modifying code without first identifying or creating the content you will use to test your changes.**
+
+## When to Apply This Skill
+
+Apply Content Driven Development principles to ALL AEM development tasks:
+
+- ✅ Creating new blocks
+- ✅ Modifying existing blocks (structural or functional changes)
+- ✅ Changes to core decoration functionality
+- ✅ Bug fixes that require validation
+- ✅ Any code that affects how authors create or structure content
+
+Skip CDD only for:
+- ⚠️ Trivial CSS-only styling tweaks (but still identify test content for validation)
+- ⚠️ Configuration changes that don't affect authoring
+
+When in doubt, follow the CDD process. The time invested pays dividends in quality and efficiency.
+
+## Related Skills
+
+This skill orchestrates other skills at the appropriate stages:
+
+- **content-modeling**: Invoked when new content models need to be designed or existing models modified
+- **building-blocks**: Invoked during implementation phase for block creation or modification
+- **testing-blocks**: Referenced during validation phase for comprehensive testing
+- **block-collection-and-party**: Used to find similar blocks and reference implementations
+
+## The Content-First Process
+
+Follow these phases in order. Do not skip steps.
+
+### Phase 1: Content Discovery and Modeling
+
+The first phase establishes what content you're working with and ensures the content model is author-friendly.
+
+#### Step 1.1: Determine Content Availability
+
+**For new blocks:**
+
+Skip to Step 1.2 (Content Model Design). Searching for content that doesn't exist is a waste of time.
+
+**For modifications to existing blocks:**
+
+Ask the user: "Does content using this block already exist that we can use for testing?"
+
+- **YES** → Identify existing content to test against
+  - Use the `scripts/find-block-content.js` script to search for pages containing the block
+  - Or ask the user: "What are the path(s) to page(s) with this block?"
+  - Validate the content loads correctly in your local dev environment
+  - Proceed to Phase 2 (skip content modeling if structure isn't changing)
+
+- **NO existing content** → Proceed to Step 1.2
+
+#### Step 1.2: Content Model Design
+
+**REQUIRED for:**
+- All new blocks
+- Structural changes to existing blocks (adding/removing/modifying sections, variants, or the authoring structure)
+
+**Ask the user:**
+"This requires a new content model. Would you like me to use the content-modeling skill to design an author-friendly content model now?"
+
+- **YES** → Invoke the **content-modeling** skill
+  - Follow the content modeling process completely
+  - Return to this skill when content model is defined
+  - Proceed to Step 1.3
+
+- **NO** → The user may want to define it themselves
+  - Ask: "Please describe the content structure authors will use"
+  - Document their description for reference
+  - Proceed to Step 1.3
+
+#### Step 1.3: Content Creation
+
+Once the content model is defined (from Step 1.2), you need test content.
+
+**Ask the user:**
+"We need test content for development and validation. This content will serve multiple purposes:
+- Testing during development
+- PR validation link for PSI checks
+- Author documentation and examples
+
+Would you like to:
+1. Create this content in the CMS now (Google Drive/SharePoint/DA/Universal Editor)
+2. Create temporary local HTML files for testing (will need CMS content before PR)"
+
+**Option 1: CMS Content (Recommended)**
+- Guide the user through creating content in their CMS
+- Wait for user confirmation that content is created and published
+- Get the content URL(s) from the user
+- Validate content loads in local dev environment
+- Proceed to Phase 2
+
+**Option 2: Local HTML Files (Temporary)**
+- Create HTML file(s) in `drafts/` folder matching the content model structure
+- Reference the [HTML Structure Guide](resources/html-structure.md) for proper file format
+- Remind user: "Restart your dev server with: `aem up --html-folder drafts`"
+- Note: "You will need to create actual CMS content before raising a PR"
+- Proceed to Phase 2
+
+##### Making Test Content Serve as Author Documentation
+
+Test content can often double as author-facing documentation, saving time and keeping documentation current. Consider this when creating test content:
+
+**When test content IS sufficient as author documentation:**
+- The block is straightforward with clear patterns
+- Test content shows all variants and use cases
+- Content demonstrates best practices authors should follow
+- Examples are realistic and relatable to actual use cases
+
+**When separate author documentation is needed:**
+- Block has complex configuration or many variants requiring explanation
+- There are edge cases or gotchas authors need to understand
+- Project standards require formal documentation in a specific location/format
+- Block behavior isn't self-evident from examples alone
+
+**Structuring test content to serve both purposes:**
+1. **Create comprehensive examples**: Show all variants, edge cases, and common patterns
+2. **Use realistic content**: Avoid "lorem ipsum" or technical placeholders
+3. **Demonstrate best practices**: Structure content the way authors should
+4. **Consider location**: Place content where it can serve as documentation
+   - Sidekick Library projects: Consider creating in `/tools/sidekick/library/` or appropriate library location
+   - Document Authoring: Place in DA Library structure
+   - Simple documentation: Use `/drafts/docs/` or `/drafts/library/`
+   - Universal Editor: Follow project-specific documentation patterns
+
+**Ask the user about documentation approach:**
+"Should this test content also serve as author documentation? If so, we can structure it accordingly and place it in an appropriate location (e.g., `/drafts/library/{block-name}` or your project's library system)."
+
+If yes, guide content creation with documentation in mind. If no, proceed with test-focused content and note that author documentation will be needed later.
+
+### Phase 2: Implementation
+
+**CRITICAL: Do not begin Phase 2 until you have confirmed test content exists and is accessible.**
+
+Now that test content exists, proceed with implementation:
+
+#### For Block Development
+
+Invoke the **building-blocks** skill:
+- Provide the skill with the content model and test content URL(s)
+- Follow the building-blocks process for implementation
+- Return to this skill when implementation is complete
+- Proceed to Phase 3
+
+#### For Core Functionality Changes
+
+Follow standard development practices:
+- Make changes to scripts, styles, or configuration
+- Test against the identified content throughout development
+- Ensure changes don't break existing blocks or content models
+- Proceed to Phase 3
+
+### Phase 3: Validation
+
+The final phase ensures the implementation works correctly with real content.
+
+#### Step 3.1: Test with Real Content
+
+**Mandatory testing:**
+- ✅ View test content in local dev environment
+- ✅ Verify all variants render correctly
+- ✅ Check responsive behavior (mobile, tablet, desktop)
+- ✅ Test edge cases revealed by the actual content
+- ✅ Validate accessibility basics (keyboard navigation, screen reader friendly)
+
+#### Step 3.2: Run Quality Checks
+
+**Required before considering implementation complete:**
+
+```bash
+npm run lint
+```
+
+If linting fails, fix issues with:
+```bash
+npm run lint:fix
+```
+
+#### Step 3.3: Comprehensive Testing
+
+**The testing-blocks skill is automatically invoked by building-blocks** for block development.
+
+For other code changes, or for additional testing guidance, invoke the **testing-blocks** skill which provides:
+- Unit testing strategies for logic-heavy utilities
+- Browser testing with Playwright/Puppeteer
+- Linting and code quality checks
+- Performance validation with GitHub checks
+- Guidance on keeper vs throwaway tests
+
+#### Step 3.4: PR Preparation
+
+**Before raising a PR, ensure:**
+- ✅ Test content exists in the CMS (not just local HTML)
+- ✅ Test content URL is accessible for PSI checks
+- ✅ All linting passes
+- ✅ Author documentation is updated (if applicable)
+
+The test content URL will be used as the PR validation link.
+
+## Anti-Patterns to Avoid
+
+**Common mistakes:**
+- ❌ Starting with code before understanding the content model
+- ❌ Making assumptions about content structure without seeing real examples
+- ❌ Creating developer-friendly but author-hostile content models
+- ❌ Skipping content creation "to save time" (costs more time later)
+- ❌ Testing against imagined content instead of real content
+- ❌ Treating test content creation as separate from development workflow
+
+## Workflow Summary
+
+**Quick reference for the CDD process:**
+
+```
+1. CONTENT DISCOVERY
+   └─ Existing content? → Use it
+   └─ New block/structure? → Design content model → Create test content
+
+2. IMPLEMENTATION
+   └─ Build code against the real content model
+   └─ Test continuously with actual content
+
+3. VALIDATION
+   └─ Comprehensive testing with test content
+   └─ Quality checks (linting, accessibility)
+   └─ PR preparation with test URL
+
+KEY RULE: Never proceed to implementation without test content
+```
+
+## Scripts and Tools
+
+### Finding Existing Block Content
+
+Use the provided script to search for pages containing a specific block:
+
+```bash
+# Search on localhost (default)
+node .claude/skills/content-driven-development/scripts/find-block-content.js <block-name>
+
+# Search for specific variant
+node .claude/skills/content-driven-development/scripts/find-block-content.js <block-name> localhost:3000 <variant>
+
+# Search on live site
+node .claude/skills/content-driven-development/scripts/find-block-content.js <block-name> main--repo--owner.aem.live
+
+# Search on preview with variant
+node .claude/skills/content-driven-development/scripts/find-block-content.js <block-name> main--repo--owner.aem.page <variant>
+```
+
+**Examples:**
+```bash
+node .claude/skills/content-driven-development/scripts/find-block-content.js hero
+node .claude/skills/content-driven-development/scripts/find-block-content.js hero localhost:3000 dark
+node .claude/skills/content-driven-development/scripts/find-block-content.js cards main--site--owner.aem.live three-up
+```
+
+This script queries the site's query-index to find all pages containing the specified block (and optional variant) and returns their URLs. The script uses proper DOM parsing to accurately identify blocks.
+
+## Integration with Other Skills
+
+This skill acts as the orchestrator for AEM development workflows:
+
+**At Content Modeling stage:**
+→ Invoke **content-modeling** skill for author-friendly design
+
+**At Implementation stage:**
+→ Invoke **building-blocks** skill for block development
+→ Reference **block-collection-and-party** skill for patterns
+
+**At Validation stage:**
+→ Reference **testing-blocks** skill for comprehensive testing
+
+Following this orchestration ensures all development follows content-first principles.
diff --git a/.claude/.skills/content-driven-development/resources/html-structure.md b/.claude/.skills/content-driven-development/resources/html-structure.md
new file mode 100644
index 0000000..b41c03b
--- /dev/null
+++ b/.claude/.skills/content-driven-development/resources/html-structure.md
@@ -0,0 +1,542 @@
+# HTML File Structure for Test Content
+
+When creating local `.plain.html` files for testing blocks in the `drafts/` folder, follow this structure to match how AEM Edge Delivery Services processes authored content.
+
+## Important Change: Plain HTML Format
+
+**The AEM CLI now automatically wraps HTML content with the headful structure (head, header, footer).** When you create `.plain.html` files, you ONLY need to provide the section content.
+
+**What you create:**
+- ✅ Section divs with content: `<div>...</div>` (one per section)
+- ✅ Blocks as `<div class="block-name">` with nested divs
+- ✅ Default content (headings, paragraphs, links, images)
+- ✅ Section metadata blocks when needed
+
+**What the AEM CLI adds automatically:**
+- ❌ `<html>`, `<head>`, `<body>` tags
+- ❌ `<header>` and `<footer>` elements
+- ❌ `<main>` wrapper
+- ❌ Head content (comes from project's head.html)
+
+## Plain HTML Structure
+
+```html
+<div>
+  <!-- Section 1: Mixed content - default content and a block -->
+  <h1>Page Heading</h1>
+  <p>This is regular paragraph content.</p>
+
+  <div class="block-name">
+    <!-- Block content goes here -->
+    <div>
+      <div>Block content cell 1</div>
+      <div>Block content cell 2</div>
+    </div>
+  </div>
+
+  <p>More content after the block.</p>
+</div>
+
+<div>
+  <!-- Section 2: Block in its own section -->
+  <div class="block-name variant-name">
+    <!-- Block content -->
+  </div>
+</div>
+
+<div>
+  <!-- Section 3: Multiple blocks in one section -->
+  <div class="block-one">
+    <!-- First block content -->
+  </div>
+
+  <div class="block-two">
+    <!-- Second block content -->
+  </div>
+</div>
+```
+
+## File Naming Convention
+
+**IMPORTANT:** HTML files must use the `.plain.html` extension:
+- ✅ `drafts/hero-test.plain.html`
+- ✅ `drafts/blocks/cards.plain.html`
+- ❌ `drafts/hero-test.html` (old format, no longer used)
+
+## Running with Local HTML
+
+**Start dev server with:**
+```bash
+aem up --html-folder drafts
+```
+
+**Preview URLs:**
+- File: `drafts/hero-test.plain.html` → URL: `http://localhost:3000/drafts/hero-test`
+- File: `drafts/blocks/cards.plain.html` → URL: `http://localhost:3000/drafts/blocks/cards`
+- **Special case:** `drafts/index.plain.html` → URL: `http://localhost:3000/drafts/index` (NOT `/drafts/`)
+
+## Section Structure
+
+Content is organized into **sections** (top-level `<div>` elements).
+
+### Basic Sections
+
+```html
+<div>
+  <!-- Section 1 content -->
+</div>
+
+<div>
+  <!-- Section 2 content -->
+</div>
+```
+
+**Important notes about sections:**
+- Sections can contain blocks, default content, or a mix of both
+- A single section can contain multiple blocks
+- There are no strict rules about when to create a new section vs. adding to an existing one
+- This varies by project and authoring practices
+- Some blocks may require or assume they are in their own section (check block documentation)
+
+### Section Metadata
+
+Sections can include metadata to define styling and behavior using a special `section-metadata` div.
+
+**In HTML (using section-metadata div):**
+```html
+<div>
+  <div class="section-metadata">
+    <div>
+      <div>Style</div>
+      <div>dark</div>
+    </div>
+  </div>
+  <!-- Section content with dark background styling -->
+</div>
+```
+
+**In markdown (Section Metadata table):**
+```markdown
++------------------------------+
+| Section Metadata             |
++------------------+-----------+
+| style            | dark      |
++------------------+-----------+
+```
+
+**How it works:**
+- The `section-metadata` div is placed at the beginning of a section
+- It uses a nested div structure to represent key-value pairs (like a table)
+- The platform processes this metadata and applies it to the parent section
+- After processing, the `section-metadata` div is removed from the DOM
+- Metadata values become CSS classes or data attributes on the section
+
+**Common section styles:**
+- `light` - White or light background
+- `dark` - Dark background with light text
+- `grey` - Grey or off-white background
+- `accent` - Branded color background
+
+**Style naming best practices:**
+- Use consistent names across sections with same visual treatment
+- Don't create unique style names for every section
+- Example: If 3 sections have white backgrounds, use "light" for all 3
+
+**Example with multiple sections:**
+```html
+<!-- Section 1: Light background -->
+<div>
+  <div class="section-metadata">
+    <div>
+      <div>Style</div>
+      <div>light</div>
+    </div>
+  </div>
+  <div class="hero">
+    <div><div><h1>Welcome</h1></div></div>
+  </div>
+</div>
+
+<!-- Section 2: Dark background -->
+<div>
+  <div class="section-metadata">
+    <div>
+      <div>Style</div>
+      <div>dark</div>
+    </div>
+  </div>
+  <div class="cards">
+    <div>
+      <div>Card 1</div>
+      <div>Card 2</div>
+    </div>
+  </div>
+</div>
+
+<!-- Section 3: Light background (reuses "light") -->
+<div>
+  <div class="section-metadata">
+    <div>
+      <div>Style</div>
+      <div>light</div>
+    </div>
+  </div>
+  <h2>About Our Company</h2>
+  <p>This section has default content, not blocks.</p>
+</div>
+```
+
+**For guidance on identifying sections and assigning styles:**
+Use the **page-decomposition** skill when migrating pages.
+
+## Section Content Types
+
+Sections can contain any combination of:
+
+### 1. Default Content
+
+Regular HTML elements like headings, paragraphs, lists, etc.
+
+```html
+<div>
+  <h1>Main Heading</h1>
+  <h2>Subheading</h2>
+  <p>Paragraph with <strong>bold</strong> and <em>italic</em> text.</p>
+  <ul>
+    <li>Unordered list item</li>
+  </ul>
+  <ol>
+    <li>Ordered list item</li>
+  </ol>
+</div>
+```
+
+**Supported default elements:**
+- Headings: `<h1>`, `<h2>`, `<h3>`, `<h4>`, `<h5>`, `<h6>`
+- Paragraphs: `<p>`
+- Lists: `<ul>`, `<ol>`, `<li>`
+- Inline formatting: `<strong>`, `<em>`, `<a>`
+- Images: Use `<picture>` elements with `<source>` and `<img>` tags (see Images section below)
+- Code blocks: `<pre>`, `<code>`
+- Block quotes: `<blockquote>`
+
+### 2. Blocks
+
+Blocks are `<div>` elements with specific class names that trigger decoration logic.
+
+**Basic block structure:**
+```html
+<div>
+  <div class="block-name">
+    <!-- Block content structured based on content model -->
+  </div>
+</div>
+```
+
+**Block with variant:**
+```html
+<div>
+  <div class="block-name variant-name">
+    <!-- Block content -->
+  </div>
+</div>
+```
+
+**Multiple variants:**
+```html
+<div>
+  <div class="block-name variant-one variant-two">
+    <!-- Block content -->
+  </div>
+</div>
+```
+
+### 3. Icons
+
+Icons are authored using the `:iconName:` syntax and are processed into `<span>` elements with icon classes.
+
+**Author input:**
+```
+:profile:
+```
+
+**HTML output:**
+```html
+<span class="icon icon-profile"></span>
+```
+
+**Important notes about icons:**
+- Icons can be wrapped in links, strong, em, or other inline elements
+- The icon name corresponds to an SVG file in `/icons/` (e.g., `:profile:` → `/icons/profile.svg`)
+- Icon spans use two classes: `icon` (base class) and `icon-{name}` (specific icon)
+- Icons are inline elements and can be combined with text
+
+**Examples:**
+
+Icon in a link:
+```html
+<a href="/profile"><span class="icon icon-profile"></span> View Profile</a>
+```
+
+Icon with emphasis:
+```html
+<strong><span class="icon icon-star"></span> Featured</strong>
+```
+
+Icon by itself:
+```html
+<p><span class="icon icon-home"></span></p>
+```
+
+### 4. Images
+
+Images should always use the `<picture>` element with `<source>` elements for responsive images and format optimization.
+
+**Basic picture structure:**
+```html
+<picture>
+  <source type="image/webp" srcset="/media/image.jpg?width=2000&format=webply&optimize=medium" media="(min-width: 600px)">
+  <source type="image/webp" srcset="/media/image.jpg?width=750&format=webply&optimize=medium">
+  <source srcset="/media/image.jpg?width=2000&format=jpeg&optimize=medium" media="(min-width: 600px)">
+  <img loading="lazy" alt="Image description" src="/media/image.jpg?width=750&format=jpeg&optimize=medium">
+</picture>
+```
+
+**Key aspects of picture elements:**
+- Multiple `<source>` elements provide WebP format with fallbacks
+- Use `media` attributes for responsive breakpoints (typically `(min-width: 600px)` for desktop)
+- Include width query parameters (`?width=750` for mobile, `?width=2000` for desktop)
+- Add `format` and `optimize=medium` parameters for image optimization
+- The final `<img>` element is the fallback
+- Always include `alt` attribute for accessibility
+- Use `loading="lazy"` for images below the fold, `loading="eager"` for above-the-fold images
+
+**Standard responsive breakpoints:**
+```html
+<picture>
+  <!-- WebP desktop (600px+) -->
+  <source type="image/webp" srcset="/media/image.jpg?width=2000&format=webply&optimize=medium" media="(min-width: 600px)">
+
+  <!-- WebP mobile -->
+  <source type="image/webp" srcset="/media/image.jpg?width=750&format=webply&optimize=medium">
+
+  <!-- JPEG desktop (600px+) -->
+  <source srcset="/media/image.jpg?width=2000&format=jpeg&optimize=medium" media="(min-width: 600px)">
+
+  <!-- JPEG mobile (fallback) -->
+  <img loading="lazy" alt="Descriptive alt text" src="/media/image.jpg?width=750&format=jpeg&optimize=medium">
+</picture>
+```
+
+**Important notes:**
+- Place images in the `/media/` folder or appropriate project location
+- Always provide meaningful `alt` text for accessibility
+- Use `loading="eager"` only for hero/above-the-fold images
+- The platform's `createOptimizedPicture()` JavaScript helper generates this structure automatically in decoration code
+
+**Simplified picture format for examples:**
+
+For brevity, examples in this document may show simplified picture tags:
+```html
+<picture>
+  <img src="/media/image.jpg" alt="Description">
+</picture>
+```
+
+In actual test files, you can use either:
+1. The full responsive structure shown above (recommended for realistic testing)
+2. The simplified format (acceptable for quick prototyping, though less realistic)
+
+## Block Content Structure
+
+The internal structure of a block depends on its content model. Blocks typically use nested `<div>` elements to represent the table-like structure from authoring.
+
+### Simple Block Example
+
+A hero block with an image and text:
+
+```html
+<div class="hero">
+  <div>
+    <div>
+      <picture>
+        <img src="/media/hero-image.jpg" alt="Hero image description">
+      </picture>
+    </div>
+  </div>
+  <div>
+    <div>
+      <h1>Hero Heading</h1>
+      <p>Hero description text</p>
+    </div>
+  </div>
+</div>
+```
+
+### Block with Multiple Rows
+
+A cards block with multiple items:
+
+```html
+<div class="cards">
+  <div>
+    <div>
+      <picture>
+        <img src="/media/card1.jpg" alt="Card 1">
+      </picture>
+    </div>
+    <div>
+      <h3>Card 1 Title</h3>
+      <p>Card 1 description</p>
+    </div>
+  </div>
+  <div>
+    <div>
+      <picture>
+        <img src="/media/card2.jpg" alt="Card 2">
+      </picture>
+    </div>
+    <div>
+      <h3>Card 2 Title</h3>
+      <p>Card 2 description</p>
+    </div>
+  </div>
+  <div>
+    <div>
+      <picture>
+        <img src="/media/card3.jpg" alt="Card 3">
+      </picture>
+    </div>
+    <div>
+      <h3>Card 3 Title</h3>
+      <p>Card 3 description</p>
+    </div>
+  </div>
+</div>
+```
+
+### Block Structure Mapping
+
+The nested `<div>` structure in HTML corresponds to the table structure in authoring:
+
+**In document authoring (table):**
+```
+| Block Name        |
+|-------------------|
+| Cell 1   | Cell 2 |
+| Cell 3   | Cell 4 |
+```
+
+**In HTML:**
+```html
+<div class="block-name">
+  <div>                    <!-- Row 1 -->
+    <div>Cell 1</div>      <!-- Column 1 -->
+    <div>Cell 2</div>      <!-- Column 2 -->
+  </div>
+  <div>                    <!-- Row 2 -->
+    <div>Cell 3</div>      <!-- Column 1 -->
+    <div>Cell 4</div>      <!-- Column 2 -->
+  </div>
+</div>
+```
+
+## Complete Example
+
+Here's a complete example of a test `.plain.html` file for a hero block:
+
+**File:** `drafts/hero-test.plain.html`
+
+```html
+<!-- Hero block section -->
+<div>
+  <div class="hero">
+    <div>
+      <div>
+        <picture>
+          <img src="/media/hero-image.jpg" alt="Welcome to our site">
+        </picture>
+      </div>
+    </div>
+    <div>
+      <div>
+        <h1>Welcome to Our Site</h1>
+        <p>This is a compelling hero message that encourages visitors to take action.</p>
+        <p><a href="/contact">Get Started</a></p>
+      </div>
+    </div>
+  </div>
+</div>
+
+<!-- Regular content section -->
+<div>
+  <h2>About This Test</h2>
+  <p>This page demonstrates the hero block in action.</p>
+</div>
+
+<!-- Hero block with variant -->
+<div>
+  <div class="hero dark">
+    <div>
+      <div>
+        <picture>
+          <img src="/media/hero-dark.jpg" alt="Dark variant hero">
+        </picture>
+      </div>
+    </div>
+    <div>
+      <div>
+        <h2>Dark Variant Hero</h2>
+        <p>Testing the dark variant of the hero block.</p>
+      </div>
+    </div>
+  </div>
+</div>
+```
+
+**Preview at:** `http://localhost:3000/drafts/hero-test`
+
+## Important Notes
+
+**File location:**
+- Create test HTML files in the `drafts/` folder
+- Can be organized in subfolders: `drafts/blocks/hero/test.plain.html`
+- Always use `.plain.html` extension
+
+**Running with local HTML:**
+- Start dev server with: `aem up --html-folder drafts`
+- This tells the dev server to serve HTML files from the drafts folder
+- The CLI automatically wraps your plain HTML with head, header, and footer
+
+**Section organization:**
+- Sections can contain any mix of blocks and default content
+- No strict rules about section boundaries - depends on project and authoring needs
+- Some blocks may require being in their own section - check block documentation
+
+**Images:**
+- Use `<picture>` elements with proper responsive structure (see Images section)
+- Reference images from the `/media/` folder or appropriate location
+- Always include `alt` attributes for accessibility
+
+**Testing considerations:**
+- Test multiple variants in the same file by adding multiple sections
+- Include edge cases in your test content
+- Use realistic content, not placeholder text
+
+**Content model alignment:**
+- The HTML structure must match your block's expected content model
+- Consult your content model documentation when structuring blocks
+- The decoration JavaScript will process this structure at two levels:
+  - Page-level decoration (e.g., `decorateMain` in `scripts.js`) processes all content
+  - Block-specific decoration (`blocks/{block-name}/{block-name}.js`) processes individual blocks
+- Classes and enhanced markup are typically added during decoration, not in the authored HTML
+
+## When to Create CMS Content Instead
+
+Local HTML files are useful for quick iteration, but remember:
+
+- **For PRs:** You need actual CMS content for PSI validation links
+- **For documentation:** CMS content can serve as author documentation
+- **For collaboration:** CMS content is easier for non-developers to review
+
+Always plan to create CMS content before finalizing your PR, even if you start with local HTML for rapid development.
diff --git a/.claude/.skills/content-driven-development/scripts/find-block-content.js b/.claude/.skills/content-driven-development/scripts/find-block-content.js
new file mode 100755
index 0000000..e888279
--- /dev/null
+++ b/.claude/.skills/content-driven-development/scripts/find-block-content.js
@@ -0,0 +1,262 @@
+#!/usr/bin/env node
+
+/**
+ * Find pages containing a specific block in AEM Edge Delivery projects.
+ *
+ * This script queries the query-index to find instances of a block,
+ * helping developers identify existing content for testing during development.
+ *
+ * Usage:
+ *   node find-block-content.js <block-name> [host] [variant]
+ *
+ * Examples:
+ *   node find-block-content.js hero
+ *   node find-block-content.js hero localhost:3000
+ *   node find-block-content.js hero main--mysite--owner.aem.live
+ *   node find-block-content.js hero main--mysite--owner.aem.page
+ *   node find-block-content.js hero localhost:3000 dark
+ *   node find-block-content.js cards main--mysite--owner.aem.live three-up
+ *
+ * The script will:
+ * 1. Query the site's query-index for all pages
+ * 2. Check each page for the specified block (and variant if provided)
+ * 3. Report all pages containing the block with their URLs
+ *
+ * Defaults to localhost:3000 if no host specified
+ */
+
+import { JSDOM } from 'jsdom';
+import { fileURLToPath } from 'url';
+import { dirname } from 'path';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = dirname(__filename);
+
+/**
+ * Fetch all URLs from the query index with pagination
+ * @param {string} host - The host to query
+ * @returns {Promise<string[]>} Array of page paths
+ */
+async function fetchQueryIndex(host) {
+  const limit = 512;
+  let offset = 0;
+  const paths = [];
+  let more = true;
+
+  console.log(`Fetching query index from ${host}...\n`);
+
+  do {
+    try {
+      // Use http for localhost, https for everything else
+      const protocol = host.startsWith('localhost') ? 'http' : 'https';
+      const url = `${protocol}://${host}/query-index.json?offset=${offset}&limit=${limit}`;
+      const res = await fetch(url);
+
+      if (!res.ok) {
+        throw new Error(`HTTP ${res.status}: ${res.statusText}`);
+      }
+
+      const json = await res.json();
+      const data = json.data || [];
+
+      data.forEach((item) => {
+        if (item.path) {
+          paths.push(item.path);
+        }
+      });
+
+      more = data.length === limit;
+      offset += limit;
+
+      if (more) {
+        console.log(`Fetched ${paths.length} pages so far...`);
+      }
+    } catch (err) {
+      console.error(`Error fetching query index: ${err.message}`);
+      more = false;
+    }
+  } while (more);
+
+  console.log(`\nTotal pages found: ${paths.length}\n`);
+  return paths;
+}
+
+/**
+ * Check if a page contains the specified block (and optional variant)
+ * @param {string} host - The host to query
+ * @param {string} path - The page path
+ * @param {string} blockName - Name of block to find
+ * @param {string} variant - Optional variant name to match
+ * @returns {Promise<boolean>} True if block is found
+ */
+async function pageContainsBlock(host, path, blockName, variant = null) {
+  try {
+    // Use http for localhost, https for everything else
+    const protocol = host.startsWith('localhost') ? 'http' : 'https';
+    const url = `${protocol}://${host}${path}`;
+    const res = await fetch(url);
+
+    if (!res.ok) {
+      return false;
+    }
+
+    const html = await res.text();
+
+    // Parse HTML with jsdom
+    const dom = new JSDOM(html);
+    const { document } = dom.window;
+
+    // Look for block using proper DOM query
+    // Blocks appear as elements with the block name as a class
+    const selector = `.${blockName}`;
+    const blockElements = document.querySelectorAll(selector);
+
+    if (blockElements.length === 0) {
+      return false;
+    }
+
+    // If no variant specified, any instance of the block counts
+    if (!variant) {
+      return true;
+    }
+
+    // Check if any block instance has the specified variant
+    return Array.from(blockElements).some((element) =>
+      element.classList.contains(variant)
+    );
+  } catch (err) {
+    return false;
+  }
+}
+
+/**
+ * Process URLs in batches with concurrency control
+ * @param {string} host - The host to query
+ * @param {string[]} paths - Array of page paths
+ * @param {string} blockName - Name of block to find
+ * @param {string} variant - Optional variant name
+ * @param {number} concurrency - Number of concurrent requests
+ * @returns {Promise<string[]>} Array of paths containing the block
+ */
+async function findBlockInPages(host, paths, blockName, variant = null, concurrency = 10) {
+  const matches = [];
+  const inFlight = new Set();
+
+  const searchTerm = variant ? `"${blockName}" block with "${variant}" variant` : `"${blockName}" block`;
+  console.log(`Searching ${paths.length} pages for ${searchTerm}...\n`);
+
+  for (let i = 0; i < paths.length; i += 1) {
+    const path = paths[i];
+
+    const promise = pageContainsBlock(host, path, blockName, variant).then((found) => {
+      if (found) {
+        matches.push(path);
+        console.log(`✓ Found: ${path}`);
+      }
+      inFlight.delete(promise);
+    });
+
+    inFlight.add(promise);
+
+    // Wait if we've hit concurrency limit
+    if (inFlight.size >= concurrency) {
+      await Promise.race(inFlight);
+    }
+  }
+
+  // Wait for remaining requests
+  await Promise.all(inFlight);
+
+  return matches;
+}
+
+/**
+ * Get the host to query
+ * @param {string} host - Host string or undefined for default
+ * @returns {string} The host to query
+ */
+function getHost(host) {
+  if (!host) {
+    return 'localhost:3000';
+  }
+
+  // Strip https:// or http:// if provided
+  return host.replace(/^https?:\/\//, '').replace(/\/$/, '');
+}
+
+/**
+ * Main execution
+ */
+async function main() {
+  const blockName = process.argv[2];
+  const hostArg = process.argv[3];
+  const variantArg = process.argv[4];
+
+  if (!blockName) {
+    console.error('Error: Block name is required');
+    console.error('\nUsage: node find-block-content.js <block-name> [host] [variant]');
+    console.error('\nExamples:');
+    console.error('  node find-block-content.js hero');
+    console.error('  node find-block-content.js hero localhost:3000');
+    console.error('  node find-block-content.js hero main--mysite--owner.aem.live');
+    console.error('  node find-block-content.js hero localhost:3000 dark');
+    console.error('  node find-block-content.js cards main--mysite--owner.aem.live three-up');
+    process.exit(1);
+  }
+
+  const host = getHost(hostArg);
+  const searchTerm = variantArg ? `"${blockName}" block with "${variantArg}" variant` : `"${blockName}" block`;
+  console.log(`Searching for ${searchTerm} on ${host}\n`);
+  console.log('─'.repeat(60));
+  console.log();
+
+  // Fetch all pages from query index
+  const paths = await fetchQueryIndex(host);
+
+  if (paths.length === 0) {
+    console.log('No pages found in query index.');
+    console.log('\nMake sure:');
+    console.log('- Your dev server is running (aem up)');
+    console.log('- The site has been indexed');
+    return;
+  }
+
+  // Search for block in pages
+  const matches = await findBlockInPages(host, paths, blockName, variantArg);
+
+  console.log();
+  console.log('─'.repeat(60));
+  console.log();
+
+  // Report results
+  if (matches.length === 0) {
+    const notFoundMsg = variantArg
+      ? `No pages found containing the "${blockName}" block with "${variantArg}" variant.`
+      : `No pages found containing the "${blockName}" block.`;
+    console.log(notFoundMsg);
+    console.log('\nThis might mean:');
+    console.log('- The block is new and no content exists yet');
+    console.log('- The block name is spelled differently');
+    if (variantArg) {
+      console.log('- The variant name is spelled differently');
+      console.log(`- The block exists but not with the "${variantArg}" variant`);
+    }
+    console.log('- Content exists but hasn\'t been published');
+  } else {
+    const resultMsg = variantArg
+      ? `✓ Found ${matches.length} page(s) containing the "${blockName}" block with "${variantArg}" variant:\n`
+      : `✓ Found ${matches.length} page(s) containing the "${blockName}" block:\n`;
+    console.log(resultMsg);
+
+    matches.forEach((path, index) => {
+      console.log(`${index + 1}. https://${host}${path}`);
+    });
+
+    console.log('\nYou can use these pages for testing during development.');
+  }
+}
+
+main().catch((err) => {
+  console.error('Error:', err.message);
+  process.exit(1);
+});
diff --git a/.claude/.skills/content-driven-development/scripts/package.json b/.claude/.skills/content-driven-development/scripts/package.json
new file mode 100644
index 0000000..3dbc1ca
--- /dev/null
+++ b/.claude/.skills/content-driven-development/scripts/package.json
@@ -0,0 +1,3 @@
+{
+  "type": "module"
+}
diff --git a/.claude/.skills/content-modeling/SKILL.md b/.claude/.skills/content-modeling/SKILL.md
new file mode 100644
index 0000000..1aaf983
--- /dev/null
+++ b/.claude/.skills/content-modeling/SKILL.md
@@ -0,0 +1,234 @@
+---
+name: Modeling Content
+description: Create effective content models for your blocks that are easy for authors to work with. Use this skill anytime you are building new blocks, making changes to existing blocks that modify the initial structure authors work with.
+---
+
+# Content Modeling for AEM Edge Delivery Blocks
+
+This skill guides you through designing content models for AEM Edge Delivery Services blocks. A content model defines the HTML table structure that authors work with when creating content in their CMS (Google Docs, SharePoint, etc.).
+
+## Related Skills
+
+- **content-driven-development**: This skill is typically invoked FROM the CDD skill during Phase 1 (Content Model Design)
+- **building-blocks**: After content modeling is complete, this skill handles implementation
+- **block-collection-and-party**: Use to find similar blocks and their content models for reference
+
+## When to Use This Skill
+
+Use this skill when:
+- Creating new blocks and need to design the author-facing content structure
+- Modifying existing blocks in ways that change what authors work with
+- Reviewing content models for conformance to best practices
+- Migrating or refactoring content models
+
+**Note:** This skill is usually invoked automatically by the **content-driven-development** skill at Step 1.2. If you're not already in a CDD workflow and are creating a new block, consider invoking the CDD skill first.
+
+## Core Principles
+
+A good content model is:
+
+- **Semantic**: Structure carries meaning on its own without decoration
+- **Predictable**: Authors, developers, and agents all know what to expect
+- **Reusable**: Works across authoring surfaces and projects
+
+## Prerequisites
+
+Before designing a content model, ensure you understand:
+
+1. **Block Purpose**: What is this block meant to accomplish?
+2. **Content Requirements**: What content elements are needed (images, text, links, etc.)?
+3. **User Experience**: How should this block appear and function on the page?
+
+## The Content Modeling Process
+
+### Step 1: Identify the Canonical Model Type(s)
+
+AEM Edge Delivery has 4 canonical block models. While these cover the most common cases, sometimes the best approach is to support multiple models for the same block to accommodate different authoring workflows and content complexity.
+
+Review the descriptions in `resources/canonical-models.md` and identify which model(s) fit best:
+
+- **Standalone**: Best for distinct visual or narrative elements (Hero, Blockquote)
+- **Collection**: Ideal for repeating semi-structured content (Cards, Carousel)
+- **Configuration**: Use ONLY for API-driven or dynamic content where config controls display (Blog Listing, Search Results)
+- **Auto-Blocked**: Good for simplifying authoring of complex structures and block nesting (Tabs, YouTube Embed)
+
+**Consider these questions as a starting point** (note: content modeling is an art, not a science - use these as guidelines, not strict rules):
+- Is this a unique, one-off element? → Often Standalone
+- Is this a repeating list of similar items? → Often Collection
+- Does this pull data from an API or require behavior configuration? → Likely Configuration
+- Does this block require nesting other blocks, or use a complex structure that authors could more easily create as sections or default content that gets transformed into the block? → Consider Auto-Blocked
+
+**Important:** Consider if multiple models should be supported. For example:
+- Simple cases might work best as Collection
+- Complex cases (with nested blocks) might need Auto-Blocked
+- Both can be equally valid - let decoration code handle the variations
+
+See `resources/advanced-scenarios.md` for patterns on supporting multiple models for one block.
+
+### Step 2: Design the Table Structure
+
+Design your table structure following these key guidelines:
+
+**Key Guidelines:**
+- Limit to maximum 4 cells per row - group like elements into cells
+- Apply semantic formatting (headings, bold, italic) to define meaning
+- Prefer block variants over config cells
+- Infer from context and use smart defaults to limit what authors must input
+- Follow Postel's Law: "be conservative in what you do, be liberal in what you accept from others"
+  - Be flexible about the input structure authors provide. For example, in a hero block, all elements could be in one cell, split across 2 cells in one row, or in 2 separate rows - any of these can work with proper decoration code (it's just query selectors)
+  - Don't be overly prescriptive about structure when flexibility makes sense
+  - The goal is to make authoring easier, not to enforce rigid structures for developer convenience
+
+**For each canonical model:**
+
+**Standalone blocks:**
+- Use rows or columns as needed for the unique structure
+- Be flexible about how authors organize content - your decoration code can handle variations
+- Use semantic formatting to identify elements (bold for headings, etc.) rather than rigid cell positions
+- Example: Hero block where image and text could be in separate rows, separate columns, or even combined - decoration code uses query selectors to find what it needs
+
+**Collection blocks:**
+- Each row represents an item
+- Columns define the parts of each item
+- Keep columns consistent across all rows
+- Example: Cards with columns for image, heading, description
+
+**Configuration blocks:**
+- Two-column key/value pairs for settings or parameters
+- Keys in left column, values in right column
+- Keep configuration minimal - only true behavioral settings
+- Example: Blog Listing with keys like `limit | 10`, `sort | date-desc`, `tags | technology,news`
+
+**Auto-Blocked:**
+- Design for the simplest possible authoring experience
+- Often uses sections and section metadata to provide context
+- The pattern detection should feel "magical" to authors
+- Example: Tabs block that auto-blocks from a section containing multiple H2 headings with content, using section metadata for styling options
+
+### Step 3: Validate Against Best Practices
+
+Use this checklist to validate your content model:
+
+- [ ] Uses the appropriate canonical model type
+- [ ] Maximum 4 cells per row
+- [ ] Semantic formatting defines meaning (not just visual styling)
+- [ ] Model is predictable (clear what goes where)
+- [ ] Model is reusable (works across different authoring tools)
+- [ ] Smart defaults minimize required author input
+- [ ] Avoids configuration cells unless truly needed for dynamic content
+- [ ] Cell names/purposes are clear and meaningful
+- [ ] Consider edge cases (empty cells, optional content, etc.)
+
+**Common Anti-Patterns to Avoid:**
+- ❌ Too many columns (>4 per row)
+- ❌ Using Configuration model when Standalone or Collection would work
+- ❌ Non-semantic cell content (e.g., "column1", "column2")
+- ❌ Requiring authors to input data that could be inferred or defaulted
+- ❌ Complex nested structures that confuse authors
+- ❌ Models that only work in one specific authoring tool
+
+### Step 4: Document the Content Model
+
+Provide the content model back to the calling skill (or user) in this format:
+
+```markdown
+## Content Model: [Block Name]
+
+### Block Type
+[Standalone | Collection | Configuration | Auto-Blocked]
+
+### Table Structure
+
+| Block Name |
+|------------|
+| [Cell description] |
+| [Cell description] | [Cell description] |
+
+### How It Works
+[Explain what authors create and how the table structure works. Describe the purpose of each row/column and any semantic formatting used.]
+
+### Key Points
+- [Important authoring guidelines]
+- [Examples of semantic formatting (e.g., "bold text indicates the heading")]
+- [Any flexibility in structure (e.g., "content can be in one cell or split across two")]
+- [Common variants if applicable]
+```
+
+**Important:** This skill focuses on designing the content model. The calling skill (content-driven-development or building-blocks) will handle what to do with it next, such as creating test content or implementing the block.
+
+## Resources
+
+- `resources/canonical-models.md` - The 4 canonical model types with detailed examples and best practices
+- `resources/advanced-scenarios.md` - Supporting multiple models, progressive enhancement, and complex patterns
+
+## Example Workflow
+
+**Scenario:** User needs to create a hero block with an image, heading, and call-to-action
+
+**Process:**
+
+1. **Identify Model Type**:
+   - This is likely a Standalone block (distinct visual element, typically appears once)
+   - Could also work as a simple Collection if multiple heroes are needed, but Standalone is more common
+
+2. **Design Structure**:
+   - Start with a flexible approach that uses semantic formatting
+   - Authors could structure this multiple ways - decoration code will handle variations
+
+3. **Validate**:
+   - ✅ Standalone model (appropriate for hero)
+   - ✅ Semantic formatting will identify elements (H1 for heading, links for CTA)
+   - ✅ Flexible structure - can work with different layouts
+   - ✅ Reusable (works in any authoring tool)
+   - ✅ Under 4 cells per row
+
+4. **Document and Return to Calling Skill**:
+   ```markdown
+   ## Content Model: Hero
+
+   ### Block Type
+   Standalone
+
+   ### Table Structure
+   | Hero |
+   |------|
+   | [Image] |
+   | [Heading, description, and CTA] |
+
+   ### How It Works
+   Authors create a hero block using a simple table. The structure is flexible:
+   - Image can be in its own row or column
+   - Text content (heading, description, CTA) can be together or separated
+   - Decoration code uses semantic formatting to identify elements:
+     - H1 or bold text → heading
+     - Regular paragraphs → description
+     - Links → call-to-action
+
+   ### Key Points
+   - Use H1 or bold formatting for the main heading
+   - Structure is flexible - all content in one row, split across two rows, or in columns all work
+   - Image should be high-resolution (minimum 2000px wide for full-width heroes)
+   - Variants available: `Hero (Dark)`, `Hero (Centered)`, etc.
+   ```
+
+   *Skill returns this content model to CDD or building-blocks skill for next steps.*
+
+## Integration with Other Skills
+
+**Called from content-driven-development:**
+- CDD invokes this skill at Step 1.2 when new content models are needed
+- After completing this skill, return to CDD to continue with content creation
+
+**Calls to other skills:**
+- May reference **block-collection-and-party** to find similar blocks for pattern inspiration
+- Completed models are used by **building-blocks** during implementation
+
+## Key Takeaways
+
+1. **Choose the right canonical model first** - this drives everything else
+2. **Keep it simple** - authors should understand the model intuitively
+3. **Use semantic formatting** - let the structure carry meaning
+4. **Validate ruthlessly** - check against all best practices before finalizing
+5. **Document clearly** - both the structure and the reasoning behind it
+
+Content models are the foundation of author experience. Invest time here to create intuitive, maintainable structures that serve authors well.
diff --git a/.claude/.skills/content-modeling/resources/advanced-scenarios.md b/.claude/.skills/content-modeling/resources/advanced-scenarios.md
new file mode 100644
index 0000000..7889cef
--- /dev/null
+++ b/.claude/.skills/content-modeling/resources/advanced-scenarios.md
@@ -0,0 +1,278 @@
+# Advanced Content Modeling Scenarios
+
+This document covers common challenges in content modeling and their solutions. These scenarios go beyond the basic canonical models and address real-world complexity.
+
+---
+
+## Challenge 1: Nested Blocks
+
+**The Problem:**
+Sometimes a block needs to contain other blocks. Examples:
+- Tabs where each tab contains a cards or columns block
+- Accordions with complex content including multiple blocks
+
+**Solutions:**
+
+### Solution A: Auto-Blocking with Sections
+Authors create separate sections with section metadata. The auto-blocking code merges them into one block with nested content.
+
+**Example: Tabs with nested blocks**
+
+```markdown
+| Section Metadata |
+|------------------|
+| style | tabs |
+
+## Getting Started
+
+Welcome to our platform! Here's how to begin.
+
+| Hero |
+|------|
+| ![Welcome](welcome.jpg) | # Start Here<p>Your journey begins now.</p> |
+
+---
+
+| Section Metadata |
+|------------------|
+| style | tabs |
+
+## Features
+
+| Cards |
+|-------|
+| ![Feature 1](f1.jpg) | ## Real-time Collaboration<p>Work together seamlessly.</p> |
+| ![Feature 2](f2.jpg) | ## Advanced Analytics<p>Insights at your fingertips.</p> |
+```
+
+Multiple consecutive sections with `style | tabs` metadata get merged into one tabs block, with each section becoming one tab. Any blocks within the sections are preserved as nested blocks.
+
+### Solution B: Fragments
+Authors create the outer block and link to a fragment containing the inner blocks.
+
+**Example: Accordion with fragment**
+
+```markdown
+| Accordion |
+|-----------|
+| ## How do I get started? | [Getting started guide](../fragments/getting-started) |
+| ## What features are available? | [Feature overview](../fragments/features) |
+```
+
+The fragment documents contain the detailed content with multiple blocks, which get embedded into the accordion items.
+
+**When to use which:**
+- **Auto-blocking**: When authors naturally think in sections and the pattern is common/predictable
+- **Fragments**: When the nested content is complex, reused across pages, or managed separately
+
+---
+
+## Challenge 2: Item-Level Configurations in Collections
+
+**The Problem:**
+In a collection block, each item might need its own configuration - not content, but behavioral or styling settings. This is different from the item's actual content (text, images, links). Examples:
+- Each card in a grid could potentially be "featured" with different sizing
+- Each accordion item needs to specify whether it starts expanded or collapsed
+- Each carousel slide might have different transition effects or display durations
+
+The challenge is that this configuration isn't really content that authors should have to think about for every item, but you need a way to specify it when needed.
+
+**Solutions:**
+
+### Solution A: Variant Lists
+Use variants at the block level to specify which items get special configuration.
+
+**Example: Cards with featured items**
+
+```markdown
+| Cards (Featured-2, Featured-4) |
+|--------------------------------|
+| ![Product 1](p1.jpg) | ## Standard Product<p>Regular card styling.</p> |
+| ![Product 2](p2.jpg) | ## Featured Product<p>This one stands out with larger size.</p> |
+| ![Product 3](p3.jpg) | ## Another Product<p>Back to regular styling.</p> |
+| ![Product 4](p4.jpg) | ## Also Featured<p>This one is also larger and featured.</p> |
+| ![Product 5](p5.jpg) | ## Standard Product<p>Regular card styling.</p> |
+```
+
+The decoration code parses the variant list `Featured-2, Featured-4` and applies the "featured" styling to items 2 and 4 (using 1-based indexing).
+
+**Example: Accordion with default-open items**
+
+```markdown
+| Accordion |
+|-----------|
+| ## First Question (Open) | The answer to the first question appears here. |
+| ## Second Question | This one starts collapsed. |
+| ## Third Question | Also starts collapsed. |
+```
+
+### Solution B: Optional Configuration Cell
+Add an additional (optional) column for configuration when variants aren't sufficient.
+
+**Example: Collection with per-item config**
+
+```markdown
+| Gallery |
+|---------|
+| ![Image 1](img1.jpg) | Beautiful sunset over mountains | |
+| ![Image 2](img2.jpg) | City skyline at night | zoom-enabled |
+| ![Image 3](img3.jpg) | Forest path in autumn | |
+```
+
+The third column is optional. When present, it configures that specific item (in this case, enabling zoom for image 2).
+
+**When to use which:**
+- **Variants**: When the configuration is simple styling/behavior that maps to CSS classes (Featured, Large, Open, etc.)
+- **Optional config cell**: When the configuration is more complex or doesn't fit the variant pattern well
+- **Neither**: If every (or nearly every) item needs unique configuration, those settings might actually be content that varies per item, not behavioral config - consider whether Collection is the right model
+
+**Trade-offs:**
+- Variants are more author-friendly and semantic
+- Config cells are more flexible but less intuitive, and non-semantic
+- Both add complexity - use sparingly, only when truly needed
+
+---
+
+## Challenge 3: Lists
+
+**The Problem:**
+Blocks often contain things that feel "list-like" to developers - repeating items that would naturally be rendered as `<ul>` or `<ol>` elements. However, authors often struggle to create list elements in their authoring tools (Google Docs, SharePoint, etc.), especially when list items are complex (like a list of related articles with images and links).
+
+**The key principle:** Never require authors to create lists when they can be avoided. What looks like a list to a developer can often be better modeled as a Collection or other structure that's easier to author.
+
+**Reference:** See [Rule 5 from David's Model](https://www.aem.live/docs/davidsmodel)
+
+**Solutions:**
+
+The solution is almost always to use a Collection model, but the specific approach depends on the complexity of each item.
+
+### Solution A: Collection Block for Complex Items
+When each "list item" has multiple parts (image, heading, description, link), use a Collection block.
+
+**Example: Related articles**
+
+```markdown
+| Related Articles |
+|------------------|
+| ![Article 1](article1.jpg) | ## Understanding Edge Delivery<p>Learn the basics of AEM Edge Delivery Services.</p><p>[Read more](article1)</p> |
+| ![Article 2](article2.jpg) | ## Content Modeling Best Practices<p>Design content models that authors love.</p><p>[Read more](article2)</p> |
+| ![Article 3](article3.jpg) | ## Performance Optimization<p>Make your site lightning fast.</p><p>[Read more](article3)</p> |
+```
+
+Each row is one article. Columns separate the parts (image, content). Decoration code renders this as cards or a list, depending on styling needs.
+
+### Solution B: Flexible Input for Simple Items
+When each "list item" is simple (text only, or text with minimal formatting), support multiple authoring approaches.
+
+**Example: Recipe ingredients - support both approaches**
+
+**Option 1: One item per line in one cell**
+```markdown
+| Recipe |
+|--------|
+| ![Finished dish](dish.jpg) |
+| ## Chocolate Chip Cookies |
+| <p>2 cups flour</p><p>1 cup butter</p><p>1 cup sugar</p><p>2 eggs</p><p>2 cups chocolate chips</p> |
+```
+
+**Option 2: One item per row**
+```markdown
+| Recipe |
+|--------|
+| ![Finished dish](dish.jpg) |
+| ## Chocolate Chip Cookies |
+| 2 cups flour |
+| 1 cup butter |
+| 1 cup sugar |
+| 2 eggs |
+| 2 cups chocolate chips |
+```
+
+Both are valid. The decoration code handles both patterns - it checks if there's a `<ul>` or `<ol>` in one cell, or if there are multiple rows of simple text. This flexibility makes it easy for authors to copy/paste ingredients or type them however feels natural.
+
+**When to use which:**
+- **Collection for complex items (Solution A)**: When each item has multiple distinct parts (image + heading + description, or any combination that benefits from column structure)
+- **Flexible input for simple items (Solution B)**: When items are just text or links, and you want to make authoring as easy as possible by supporting multiple input methods
+
+**Key takeaway:** Don't make authors create formal list elements in their authoring tool. Use Collection models or flexible text input instead. Your decoration code can always render the final output as a `<ul>` or `<ol>` if that's the right semantic HTML.
+
+---
+
+## Challenge 4: Forms
+
+**The Problem:**
+Forms seem like Standalone blocks (distinct visual element, typically appears once) but have many input fields, which pushes them toward Configuration or Collection models. How do you balance author ease with the structural complexity of forms?
+
+**Solutions:**
+
+Forms are relatively uncommon in content-driven sites. When they do appear, consider these approaches in order of preference:
+
+### Solution A: External Form Services
+For complex forms or forms requiring advanced features (multi-step, conditional logic, integrations), use external services like Marketo, HubSpot, Google Forms, etc. Embed them via iframe or integration blocks.
+
+### Solution B: Spreadsheet-Based Forms
+Use a spreadsheet to define form fields, and create a Standalone form block that links to it.
+
+**Example: The form block**
+
+```markdown
+| Form |
+|------|
+| [Contact Form Fields](/forms/contact-form.json) |
+```
+
+**Example: The spreadsheet (contact-form.xlsx)**
+
+| Field Name | Type | Required | Label | Placeholder |
+|------------|------|----------|-------|-------------|
+| name | text | true | Full Name | Enter your name |
+| email | email | true | Email Address | you@example.com |
+| message | textarea | false | Message | How can we help? |
+
+In AEM, spreadsheets get published as JSON. The form block's decoration code fetches the JSON and builds the form dynamically. See the Block Collection for examples of this pattern.
+
+**Why this works:**
+- Separates form definition (spreadsheet) from form placement (block)
+- Authors can manage form fields in a familiar spreadsheet interface
+- Form definition is reusable across multiple pages
+- Easy to update fields without touching content pages
+
+### Solution C: Configuration Model (Anti-Pattern, but Sometimes Necessary)
+Use a Configuration block for one-off forms where a spreadsheet feels like overkill.
+
+**Example:**
+
+```markdown
+| Form |
+|------|
+| action | /submit-contact |
+| fields | name,email,message |
+| submit-label | Send Message |
+```
+
+**Warning:** This is non-semantic and requires authors to understand the configuration format. Only use for very simple, one-off forms that won't be reused or frequently modified.
+
+**When to use which:**
+- **External services (Solution A)**: For complex forms or when integrating with marketing/CRM systems
+- **Spreadsheet (Solution B)**: For most custom forms, especially if reused or frequently updated
+- **Configuration (Solution C)**: Only for very simple one-off forms
+
+---
+
+## Key Principles for Advanced Scenarios
+
+When facing complex content modeling challenges:
+
+1. **Start simple**: Can this be handled with a basic canonical model? Don't add complexity prematurely.
+
+2. **Prioritize author experience**: The best technical solution isn't always the one that's easiest to author. Can authors understand this intuitively?
+
+3. **Be consistent**: If you solve a problem one way for one block, use the same pattern for similar blocks.
+
+4. **Document edge cases**: When supporting optional cells, variants, or multiple models, document what authors can expect.
+
+5. **Test with real authors**: Complex models often reveal usability issues only when real people try to use them.
+
+6. **Consider alternatives**: Sometimes the answer isn't a better content model, but a different feature (fragments, section metadata, auto-blocking, external tools).
+
+The goal is always the same: make it easy for authors to create great content while giving developers the structure they need to build great experiences.
diff --git a/.claude/.skills/content-modeling/resources/canonical-models.md b/.claude/.skills/content-modeling/resources/canonical-models.md
new file mode 100644
index 0000000..14995b9
--- /dev/null
+++ b/.claude/.skills/content-modeling/resources/canonical-models.md
@@ -0,0 +1,476 @@
+# The 4 Canonical Block Models
+
+AEM Edge Delivery Services has 4 canonical patterns for structuring block content. Choosing the right model is the foundation of creating effective, author-friendly content structures.
+
+## Model Selection Guide
+
+| Model | When to Use | Examples |
+|-------|-------------|----------|
+| **Standalone** | Distinct visual or narrative elements | Hero, Blockquote |
+| **Collection** | Repeating semi-structured content | Cards, Carousel |
+| **Configuration** | API-driven or dynamic content where config controls display | Blog Listing, Search Results |
+| **Auto-Blocked** | Simplifying authoring of complex structures and block nesting | Tabs, YouTube Embed |
+
+---
+
+## 1. Standalone Model
+
+### Description
+
+Self-contained blocks using rows or columns as needed for their unique structure. Best for elements that appear once or a few times on a page with a distinct purpose.
+
+### Characteristics
+
+- Unique, one-off structure
+- Rows and columns organized for the specific content needs
+- Each instance is typically different from others
+- Structure carries the semantics of the content
+
+### When to Use
+
+- Hero sections
+- Blockquotes
+- Feature callouts
+- Unique page sections
+- Any element with a distinct visual or narrative purpose
+
+### Good Example: Hero Block
+
+```markdown
+| Hero |
+|------|
+| ![Hero image](hero.jpg) |
+| # Welcome to Our Site |
+| Discover amazing content and start your journey today. [Get Started](cta-link) |
+```
+
+**Why this works:**
+- ✅ Uses semantic formatting: H1 identifies the heading, paragraphs for body text
+- ✅ Flexible structure: could also work with image and text in columns, or all in one cell
+- ✅ Decoration code can find elements using query selectors regardless of exact layout
+- ✅ Author-friendly: natural content authoring
+
+**Note on flexibility:**
+These variations would also work with proper decoration code:
+- Image and text in separate columns: `| ![Image](hero.jpg) | # Heading<p>Description text [CTA](link)</p> |`
+- All content in one cell: `| ![Image](hero.jpg)<h1>Heading</h1><p>Description text [CTA](link)</p> |`
+- Image in one row, heading and text in another (as shown above)
+- The key is semantic formatting (H1 for heading, paragraph text, links for CTA), not rigid cell positions
+
+### Bad Example: Hero Block (Anti-Pattern)
+
+```markdown
+| Hero |
+|------|
+| ![Image](hero.jpg) | Welcome | Discover content | Get Started | /cta-link | dark |
+```
+
+**Why this fails:**
+- ❌ 6 cells in one row (exceeds maximum of 4)
+- ❌ Non-semantic: text split across multiple unlabeled cells
+- ❌ Split related text across cells unnecessarily
+- ❌ Configuration-style variant control in "dark" cell (should use block variant class)
+- ❌ Unpredictable: authors must remember which cell is which
+- ❌ Author-hostile: too many required cells, no semantic formatting
+
+**How to fix:**
+- Simplify to under 4 cells per row
+- Use semantic formatting (H1 for heading, paragraphs for text, links for CTA) instead of splitting into separate cells
+- Use block variant `| Hero (Dark) |` instead of config cell
+- Let decoration code find elements via query selectors, don't require specific cell positions
+
+---
+
+## 2. Collection Model
+
+### Description
+
+Each row represents an item, with columns defining the parts of that item. Ideal for repeating, semi-structured content where each instance follows the same pattern.
+
+### Characteristics
+
+- Rows represent individual items
+- Columns are consistent across all rows
+- Items have the same structure but different content
+- Easy to add/remove items by adding/removing rows
+
+### When to Use
+
+- Card grids
+- Carousels
+- Image galleries
+- Feature lists
+- Team member listings
+- Any repeating set of similar items
+
+### Good Example: Cards Block
+
+```markdown
+| Cards |
+|-------|
+| ![Product 1](product1.jpg) | ## Product Name<p>High-quality product description goes here.</p><p>[Learn More](link1)</p> |
+| ![Product 2](product2.jpg) | ## Another Product<p>Different product with its own description.</p><p>[Learn More](link2)</p> |
+| ![Product 3](product3.jpg) | ## Third Product<p>More details about this product offering.</p><p>[Learn More](link3)</p> |
+```
+
+**Why this works:**
+- ✅ Collection model: each row is one card
+- ✅ 2 columns: image and content
+- ✅ Consistent structure across all rows
+- ✅ Semantic formatting: H2 for card title, paragraph text for description, links for CTA
+- ✅ Easy to add/remove cards (add/remove rows)
+- ✅ Within 4-cell maximum
+
+**Resulting structure:**
+- Each row becomes one card
+- Column 1: Card image
+- Column 2: Card heading (H2), description (paragraph), and CTA link - decoration code uses query selectors to identify each element
+
+### Bad Example: Cards Block (Anti-Pattern)
+
+```markdown
+| Cards |
+|-------|
+| config | style | grid |
+| ![Product 1](product1.jpg) |
+| Product Name |
+| High-quality product description |
+| [Learn More](link1) |
+| ![Product 2](product2.jpg) |
+| Another Product |
+| Different product description |
+| [Learn More](link2) |
+```
+
+**Why this fails:**
+- ❌ Mixing configuration row with content rows
+- ❌ Non-semantic: first row should use block variant instead
+- ❌ Each card uses 4 separate rows instead of 1 row with columns
+- ❌ Unpredictable: hard to tell where one card ends and another begins
+- ❌ Author-unfriendly: difficult to add/remove cards
+- ❌ Requires counting rows to understand structure
+
+**How to fix:**
+- Remove config row, use variant: `| Cards (Grid) |`
+- Use columns instead of rows for each card's parts
+- One row = one complete card
+
+---
+
+## 3. Configuration Model
+
+### Description
+
+Two-column key/value pairs for settings or parameters. Use ONLY for API-driven or dynamic content where configuration actually controls behavior or data fetching.
+
+### Characteristics
+
+- Two columns: key (left) and value (right)
+- Controls behavior, not content structure
+- Often drives API calls or dynamic data
+- Minimal visual content
+
+### When to Use
+
+- Blog listings (sort order, filters)
+- Search results (query parameters)
+- Dynamic data displays
+- API-driven components
+- True behavioral configuration
+
+### ⚠️ Important Warning
+
+**Do NOT use Configuration model when:**
+- Standalone or Collection model would work
+- You're just displaying static content
+- Configuration could be handled by block variants
+- Authors are providing content, not controlling behavior
+
+Configuration models are often overused. Always ask: "Does this truly need dynamic configuration, or am I just making authoring harder?"
+
+### Good Example: Blog Listing Block
+
+```markdown
+| Blog Listing |
+|--------------|
+| limit | 10 |
+| sort | date-desc |
+| tags | technology,news |
+```
+
+**Why this works:**
+- ✅ Truly configuration-driven (controls API query)
+- ✅ Two-column key/value pairs
+- ✅ No visual content (pure config)
+- ✅ Controls dynamic behavior (fetch and display blog posts)
+- ✅ Appropriate use case for Configuration model
+
+**Resulting behavior:**
+- Fetches 10 most recent posts
+- Sorted by date descending
+- Filtered to posts tagged with "technology" or "news"
+
+### Bad Example: Blockquote (Anti-Pattern)
+
+```markdown
+| Blockquote |
+|------------|
+| text | The best way to predict the future is to invent it. |
+| author | Alan Kay |
+| style | bordered |
+| background | light-gray |
+```
+
+**Why this fails:**
+- ❌ This is static content, not dynamic configuration
+- ❌ Should be Standalone model, not Configuration
+- ❌ "style" and "background" should be block variants
+- ❌ Forces authors to label their own content
+- ❌ More complex than necessary
+
+**How to fix:**
+Use Standalone model with semantic formatting:
+
+```markdown
+| Blockquote (Bordered, Light) |
+|-------------------------------|
+| The best way to predict the future is to invent it. |
+| *Alan Kay* |
+```
+
+- Use block variants for styling
+- Use semantic formatting (italic) for attribution
+- Let structure speak for itself
+
+---
+
+## 4. Auto-Blocked Model
+
+### Description
+
+Content authored as default content that gets automatically converted into blocks based on pattern detection. Simplifies authoring of complex structures by hiding the "block-ness" from authors.
+
+### Characteristics
+
+- Authors write standard content
+- Pattern detection creates blocks automatically
+- "Magical" author experience
+- Good for common, predictable patterns
+- Reduces authoring complexity
+
+### When to Use
+
+- Tab interfaces (heading patterns)
+- YouTube embeds (URL detection)
+- Common content patterns
+- Nested block structures
+- Whenever you can hide complexity from authors
+
+### Good Example: Tabs (Auto-Blocked)
+
+**What authors write - three separate sections, each with section metadata:**
+
+```markdown
+| Section Metadata |
+|------------------|
+| style | tabs |
+
+## Getting Started
+
+Follow these steps to set up your account and configure your preferences.
+
+| Hero |
+|------|
+| ![Welcome](welcome.jpg) | # Welcome<p>Start your journey here.</p> |
+
+---
+
+| Section Metadata |
+|------------------|
+| style | tabs |
+
+## Advanced Features
+
+Learn about advanced capabilities once you're comfortable with the basics.
+
+- Feature 1: Real-time collaboration
+- Feature 2: Advanced analytics
+- Feature 3: Custom integrations
+
+---
+
+| Section Metadata |
+|------------------|
+| style | tabs |
+
+## Troubleshooting
+
+Common issues and how to resolve them quickly.
+
+| Cards |
+|-------|
+| ![Issue 1](issue1.jpg) | ## Login Problems<p>How to reset your password.</p> |
+| ![Issue 2](issue2.jpg) | ## Performance Issues<p>Tips for optimizing performance.</p> |
+
+---
+```
+
+**What gets created - auto-blocked into one tabs block:**
+
+```html
+<div class="tabs">
+  <div>
+    <div><h2>Getting Started</h2></div>
+    <div>
+      <p>Follow these steps to set up your account and configure your preferences.</p>
+      <div class="hero"><!-- Hero block content --></div>
+    </div>
+  </div>
+  <div>
+    <div><h2>Advanced Features</h2></div>
+    <div>
+      <p>Learn about advanced capabilities once you're comfortable with the basics.</p>
+      <ul>
+        <li>Feature 1: Real-time collaboration</li>
+        <li>Feature 2: Advanced analytics</li>
+        <li>Feature 3: Custom integrations</li>
+      </ul>
+    </div>
+  </div>
+  <div>
+    <div><h2>Troubleshooting</h2></div>
+    <div>
+      <p>Common issues and how to resolve them quickly.</p>
+      <div class="cards"><!-- Cards block content --></div>
+    </div>
+  </div>
+</div>
+```
+
+**Why this works:**
+- ✅ Authors create natural sections (separated by `---`) with H2 headings and content
+- ✅ Section metadata (`style | tabs`) signals intent to auto-block
+- ✅ Multiple consecutive sections with `style | tabs` metadata get merged into one tabs block
+- ✅ Each section becomes one tab: H2 = tab title, everything else = tab content
+- ✅ No need to understand block syntax
+- ✅ Can mix default content and blocks within tab content
+- ✅ Simplifies complex authoring
+- ✅ Feels "magical" when it works
+
+### Good Example: YouTube Embed (Auto-Blocked)
+
+**What authors write:**
+
+```markdown
+![Video preview image](video-preview.jpg)
+https://www.youtube.com/watch?v=dQw4w9WgXcQ
+```
+
+**What gets created:**
+
+```html
+<div class="embed embed-youtube">
+  <div>
+    <div>
+      <picture>
+        <img src="video-preview.jpg" alt="Video preview image">
+      </picture>
+    </div>
+    <div>
+      <a href="https://www.youtube.com/watch?v=dQw4w9WgXcQ">https://www.youtube.com/watch?v=dQw4w9WgXcQ</a>
+    </div>
+  </div>
+</div>
+```
+
+**Why this works:**
+- ✅ Authors just paste image and URL in sequence
+- ✅ Pattern detection creates the embed block
+- ✅ Image immediately preceding YouTube URL becomes the preview/poster image
+- ✅ If no image, block still works with just the URL
+- ✅ Minimal author effort
+- ✅ Consistent behavior
+
+### When NOT to Use Auto-Blocked
+
+Auto-blocking requires:
+- Predictable, detectable patterns
+- Implementation of auto-blocking logic in `scripts.js`
+- Patterns that are truly common and repeatable
+
+Don't create auto-blocking for:
+- One-off special cases
+- Complex patterns that are hard to detect reliably
+- Cases where explicit blocks would be clearer
+
+---
+
+## Choosing the Right Model
+
+Content modeling is an art, not a science. There are often multiple valid approaches, and the "right" model depends on context, authoring needs, and implementation constraints.
+
+**Review the detailed examples above** for each canonical model to understand their characteristics, strengths, and when they're most appropriate. Pay special attention to the "Why this works" and "Why this fails" explanations.
+
+**Key considerations:**
+- **Standalone** is the most flexible and often a safe default choice
+- **Collection** works well when you have clear repeating items
+- **Configuration** is frequently overused - only use for truly dynamic, API-driven content
+- **Auto-Blocked** requires careful pattern design but can be worth it to make authors' lives easier
+
+When in doubt, start with Standalone or Collection - they're simpler and more author-friendly than Configuration or Auto-Blocked.
+
+### Common Mistakes
+
+**Using Configuration when Standalone/Collection would work:**
+```markdown
+❌ BAD (unnecessary config)
+| Card |
+|------|
+| image | hero.jpg |
+| title | Welcome |
+
+✅ GOOD (Standalone)
+| Card |
+|------|
+| ![Welcome](hero.jpg) |
+| **Welcome** |
+```
+
+**Using Standalone when Collection would work:**
+```markdown
+❌ BAD (repeating standalone pattern)
+Multiple separate blocks for each card
+
+✅ GOOD (Collection)
+| Cards |
+|-------|
+| ![Card 1](img1.jpg) | **Title 1** |
+| ![Card 2](img2.jpg) | **Title 2** |
+```
+
+**Over-engineering Auto-Blocked:**
+```markdown
+❌ BAD (complex pattern for rare use case)
+Auto-detecting "testimonial quotes" by looking for:
+- Italic paragraphs
+- Followed by bold text
+- In specific section types
+Only appears 2-3 times on entire site, not worth the complexity
+
+✅ GOOD (explicit block for clarity)
+| Blockquote |
+|------------|
+| This product changed how we work. Absolutely essential. |
+| *Sarah Johnson, CEO* |
+
+Simple, clear, and easy for authors to create when needed
+```
+
+## Summary
+
+- **Standalone**: Unique elements, flexible structure
+- **Collection**: Repeating items, rows = items, columns = parts
+- **Configuration**: Dynamic behavior only, not static content
+- **Auto-Blocked**: Common patterns, "magical" authoring
+
+When in doubt, prefer simpler models (Standalone or Collection) over complex ones (Configuration or Auto-Blocked).
diff --git a/.claude/.skills/docs-search/SKILL.md b/.claude/.skills/docs-search/SKILL.md
new file mode 100644
index 0000000..488a86a
--- /dev/null
+++ b/.claude/.skills/docs-search/SKILL.md
@@ -0,0 +1,213 @@
+---
+name: Searching AEM Documentation
+description: Searches the aem.live documentation for information on AEM Edge Delivery Services features. Use this skill when you need more information about a feature, want guidance on how to implement a feature, and using existing tools you have to search the web isn't turning up relevant results.
+---
+
+# Searching AEM Documentation
+
+## Overview
+
+This skill helps you efficiently search the complete aem.live documentation (docs and blog posts) without wasting context on irrelevant pages. Use the provided search script to find relevant documentation pages, then use WebFetch to read the full content of the most relevant results.
+
+## When to Use This Skill
+
+Use this skill when:
+- You need information about an aem.live feature or concept
+- You've already looked at the project codebase for context
+- You've tried a basic web search but didn't find relevant aem.live documentation
+- You need technical guidance on implementing aem.live features
+- You're looking for best practices or examples from the official docs
+
+**Do NOT use this skill when:**
+- You need reusable code snippets or block examples (use `block-collection-and-party` instead)
+- You already know the specific documentation URL
+- You're looking for general web development information (not aem.live specific)
+
+## How to Use This Skill
+
+### Step 1: Identify Keywords
+
+Determine 1-3 specific keywords related to what you're searching for. Be specific rather than general.
+
+**Good keywords:**
+- "block decoration"
+- "metadata"
+- "universal editor"
+- "sidekick plugin"
+
+**Poor keywords:**
+- "aem" (too generic, filtered as stop word)
+- "how to build website" (too broad)
+- "the" (stop word)
+
+### Step 2: Run the Search Script
+
+Execute the search script from the project root:
+
+```bash
+node .claude/skills/docs-search/scripts/search.js [--all] <keyword1> [keyword2] [...]
+```
+
+**Options:**
+- `--all`: Return all matching results (default: limit to 10 most relevant)
+- Without `--all`: Returns top 10 results
+
+**Examples:**
+```bash
+# Search for block decoration info
+node .claude/skills/docs-search/scripts/search.js block decoration
+
+# Search for metadata with all results
+node .claude/skills/docs-search/scripts/search.js --all metadata
+
+# Multi-word search
+node .claude/skills/docs-search/scripts/search.js universal editor blocks
+```
+
+### Step 3: Review Search Results
+
+The script returns JSON with the following structure:
+
+```json
+[
+  {
+    "path": "/developer/markup-sections-blocks",
+    "title": "Markup, Sections, Blocks, and Auto Blocking",
+    "description": "To design websites and create functionality, developers use the markup and DOM...",
+    "snippet": "Markup, Sections, Blocks, and Auto Blocking\n\nTo design websites...",
+    "type": "doc",
+    "deprecation": null,
+    "relevanceScore": 141
+  }
+]
+```
+
+**Field Explanations:**
+- `path`: URL path to the documentation page
+- `title`: Page title
+- `description`: Brief summary (usually ~150 chars) - **use this for quick context**
+- `snippet`: Relevant excerpt from the page content showing keyword context
+- `type`: "doc" or "blog"
+- `deprecation`: Warning message if feature is deprecated (or null)
+- `relevanceScore`: Relevance score (higher = more relevant)
+
+**Important Notes:**
+- Results are sorted by relevance (highest first)
+- Deprecated pages have reduced relevance scores but still appear in results
+- The `description` field provides the best quick summary of the page
+- The `snippet` shows keyword context but may not be comprehensive
+
+### Step 4: Use WebFetch for Full Content
+
+The search results give you an overview. To get detailed information, use WebFetch to read the full page:
+
+```
+WebFetch: https://www.aem.live{path}
+```
+
+**Best Practice:** Start with the top 2-3 most relevant results, read them fully with WebFetch, then decide if you need more.
+
+### Step 5: Alert User to Deprecations
+
+If any results have a `deprecation` field with content, **inform the user** that the feature is deprecated and include the deprecation message. Suggest they look at higher-ranked (non-deprecated) alternatives.
+
+## Search Behavior Details
+
+### What Gets Searched
+
+1. **Primary**: Full documentation (docpages-index.json) - 150+ pages with complete content
+2. **Secondary**: Blog posts (query-index.json) - Only searched if < 5 doc results found
+
+### Stop Words (Automatically Filtered)
+
+These common words are ignored in searches:
+- Articles: the, a, an
+- Conjunctions: and, or, but
+- Prepositions: in, on, at, to, for, of, with, by
+- AEM-specific: aem, cms, edge, delivery, services
+
+### Relevance Scoring
+
+- **Title match**: 10 points per occurrence
+- **Description match**: 5 points per occurrence
+- **Content match**: 1 point per occurrence
+- **Multi-keyword bonus**: 1.5x multiplier if multiple keywords match
+- **Deprecation penalty**: 0.5x multiplier (score halved) for deprecated features
+
+### Caching
+
+Index files are cached locally for 24 hours in `.claude/skills/docs-search/.cache/`. This speeds up subsequent searches.
+
+## Examples
+
+### Example 1: Finding Block Documentation
+
+**User Request:** "How do I decorate blocks in aem.live?"
+
+**Good Approach:**
+1. Search: `node .claude/skills/docs-search/scripts/search.js block decoration`
+2. Review top 3 results
+3. WebFetch the most relevant: `https://www.aem.live/developer/markup-sections-blocks`
+4. Read full content and provide answer
+
+**Poor Approach:**
+- Using WebSearch instead (wastes time on irrelevant results)
+- Not using the search script (might miss the best documentation page)
+
+### Example 2: Learning About Metadata
+
+**User Request:** "I need to add metadata to my pages"
+
+**Good Approach:**
+1. Search: `node .claude/skills/docs-search/scripts/search.js metadata`
+2. Notice top result is "/docs/bulk-metadata" (score: 63)
+3. Also see "/docs/metadata" (score: 30)
+4. WebFetch both to understand page-level vs bulk metadata
+5. Provide comprehensive answer with both approaches
+
+**Poor Approach:**
+- Only reading the first result and missing bulk metadata option
+- Not using `--all` when you need comprehensive coverage
+
+### Example 3: Deprecated Feature Warning
+
+**User Request:** "How do I use folder mapping?"
+
+**Search Results:**
+```json
+[
+  {
+    "path": "/developer/authoring-path-mapping",
+    "title": "Path mapping for AEM authoring",
+    "relevanceScore": 51,
+    "deprecation": null
+  },
+  {
+    "path": "/developer/folder-mapping",
+    "title": "Folder Mapping",
+    "relevanceScore": 34.5,
+    "deprecation": "Please contact us if you have a use case for folder mapping..."
+  }
+]
+```
+
+**Good Response:**
+"I found information about folder mapping, but **this feature is deprecated**. The deprecation notice says: 'Please contact us if you have a use case for folder mapping...'. The current recommended approach is **Path mapping for AEM authoring** (the top result). Let me read that documentation for you instead."
+
+**Poor Response:**
+- Ignoring the deprecation warning and implementing the deprecated feature
+- Not mentioning the better alternative
+
+## Related Skills
+
+- **block-collection-and-party**: Use when you need reusable code examples or block implementations
+- **building-blocks**: Use when creating new blocks from scratch
+- **content-modeling**: Use when designing content models for blocks
+
+## Important Reminders
+
+1. **Always check for deprecation warnings** and alert the user
+2. **Use WebFetch to read full pages** - search results are just for finding the right pages
+3. **Start with top 2-3 results** before expanding search
+4. **The description field is your friend** - it's usually well-written and concise
+5. **Don't rely solely on snippets** - they're for context, not comprehensive information
diff --git a/.claude/.skills/docs-search/scripts/package.json b/.claude/.skills/docs-search/scripts/package.json
new file mode 100644
index 0000000..3dbc1ca
--- /dev/null
+++ b/.claude/.skills/docs-search/scripts/package.json
@@ -0,0 +1,3 @@
+{
+  "type": "module"
+}
diff --git a/.claude/.skills/docs-search/scripts/search.js b/.claude/.skills/docs-search/scripts/search.js
new file mode 100755
index 0000000..e0feb30
--- /dev/null
+++ b/.claude/.skills/docs-search/scripts/search.js
@@ -0,0 +1,370 @@
+#!/usr/bin/env node
+
+import fs from 'fs';
+import path from 'path';
+import { fileURLToPath } from 'url';
+import https from 'https';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+const CACHE_DIR = path.join(__dirname, '..', '.cache');
+const CACHE_DURATION_MS = 24 * 60 * 60 * 1000; // 24 hours
+
+// Stop words to ignore in searches
+const STOP_WORDS = new Set([
+  'the', 'a', 'an', 'and', 'or', 'but', 'in', 'on', 'at', 'to', 'for', 'of', 'with', 'by',
+  'aem', 'cms', 'edge', 'delivery', 'services'
+]);
+
+// Scoring weights
+const SCORE_WEIGHTS = {
+  TITLE: 10,
+  DESCRIPTION: 5,
+  CONTENT: 1,
+  MULTI_KEYWORD_MULTIPLIER: 1.5,
+  DEPRECATION_PENALTY: 0.5 // Multiply score by 0.5 if deprecated
+};
+
+/**
+ * Fetch JSON from URL with caching
+ */
+async function fetchWithCache(url, cacheFileName) {
+  const cacheFilePath = path.join(CACHE_DIR, cacheFileName);
+
+  // Check if cache exists and is fresh
+  if (fs.existsSync(cacheFilePath)) {
+    const stats = fs.statSync(cacheFilePath);
+    const age = Date.now() - stats.mtimeMs;
+
+    if (age < CACHE_DURATION_MS) {
+      const cached = fs.readFileSync(cacheFilePath, 'utf8');
+      return JSON.parse(cached);
+    }
+  }
+
+  // Fetch fresh data
+  return new Promise((resolve, reject) => {
+    https.get(url, (res) => {
+      let data = '';
+      res.on('data', (chunk) => data += chunk);
+      res.on('end', () => {
+        try {
+          const json = JSON.parse(data);
+          // Cache the result
+          fs.mkdirSync(CACHE_DIR, { recursive: true });
+          fs.writeFileSync(cacheFilePath, data, 'utf8');
+          resolve(json);
+        } catch (err) {
+          reject(err);
+        }
+      });
+    }).on('error', reject);
+  });
+}
+
+/**
+ * Filter keywords to remove stop words
+ */
+function filterKeywords(keywords) {
+  return keywords
+    .map(k => k.toLowerCase().trim())
+    .filter(k => k.length > 0 && !STOP_WORDS.has(k));
+}
+
+/**
+ * Count keyword occurrences in text (case-insensitive)
+ */
+function countMatches(text, keyword) {
+  if (!text) return 0;
+  const regex = new RegExp(keyword, 'gi');
+  const matches = text.match(regex);
+  return matches ? matches.length : 0;
+}
+
+/**
+ * Clean up content noise from the beginning of text
+ */
+function cleanContent(text) {
+  if (!text) return '';
+
+  // Remove common noise patterns at the start
+  let cleaned = text
+    .replace(/^style\s+content\s+/i, '')
+    .replace(/^\s*\n+/, '')
+    .trim();
+
+  return cleaned;
+}
+
+/**
+ * Extract full sentences around keyword match
+ */
+function extractSnippet(text, keyword) {
+  if (!text) return '';
+
+  // Clean the text first
+  text = cleanContent(text);
+
+  const regex = new RegExp(keyword, 'i');
+  const match = text.match(regex);
+
+  if (!match) {
+    // No match - return first sentence(s) up to ~200 chars
+    return extractFirstSentences(text, 200);
+  }
+
+  const matchIndex = match.index;
+
+  // Find sentence boundaries around the match
+  // Look backwards for sentence start (. ! ? or start of text)
+  let sentenceStart = 0;
+  for (let i = matchIndex - 1; i >= 0; i--) {
+    if (text[i] === '.' || text[i] === '!' || text[i] === '?') {
+      sentenceStart = i + 1;
+      break;
+    }
+  }
+
+  // Look forwards for sentence end (. ! ? or end of text)
+  let sentenceEnd = text.length;
+  for (let i = matchIndex; i < text.length; i++) {
+    if (text[i] === '.' || text[i] === '!' || text[i] === '?') {
+      sentenceEnd = i + 1;
+      break;
+    }
+  }
+
+  let snippet = text.substring(sentenceStart, sentenceEnd).trim();
+
+  // If snippet is too short, try to include next sentence
+  if (snippet.length < 100 && sentenceEnd < text.length) {
+    let nextSentenceEnd = sentenceEnd;
+    for (let i = sentenceEnd + 1; i < text.length; i++) {
+      if (text[i] === '.' || text[i] === '!' || text[i] === '?') {
+        nextSentenceEnd = i + 1;
+        break;
+      }
+    }
+    snippet = text.substring(sentenceStart, nextSentenceEnd).trim();
+  }
+
+  // If snippet is too long, truncate at ~300 chars on sentence boundary
+  if (snippet.length > 300) {
+    snippet = snippet.substring(0, 300);
+    const lastPeriod = snippet.lastIndexOf('.');
+    if (lastPeriod > 100) {
+      snippet = snippet.substring(0, lastPeriod + 1);
+    } else {
+      snippet += '...';
+    }
+  }
+
+  return snippet;
+}
+
+/**
+ * Extract first few sentences up to maxLength
+ */
+function extractFirstSentences(text, maxLength = 200) {
+  text = cleanContent(text);
+
+  let end = 0;
+  let lastSentenceEnd = 0;
+
+  for (let i = 0; i < text.length && i < maxLength + 100; i++) {
+    if (text[i] === '.' || text[i] === '!' || text[i] === '?') {
+      end = i + 1;
+      if (end <= maxLength) {
+        lastSentenceEnd = end;
+      } else {
+        break;
+      }
+    }
+  }
+
+  if (lastSentenceEnd === 0) {
+    // No sentence found, just truncate
+    return text.substring(0, maxLength) + (text.length > maxLength ? '...' : '');
+  }
+
+  return text.substring(0, lastSentenceEnd).trim();
+}
+
+/**
+ * Calculate relevance score for a document
+ */
+function calculateScore(doc, keywords) {
+  let score = 0;
+  let matchedKeywords = 0;
+
+  for (const keyword of keywords) {
+    let keywordMatched = false;
+
+    // Title matches
+    const titleMatches = countMatches(doc.title, keyword);
+    if (titleMatches > 0) {
+      score += titleMatches * SCORE_WEIGHTS.TITLE;
+      keywordMatched = true;
+    }
+
+    // Description matches
+    const descMatches = countMatches(doc.description, keyword);
+    if (descMatches > 0) {
+      score += descMatches * SCORE_WEIGHTS.DESCRIPTION;
+      keywordMatched = true;
+    }
+
+    // Content matches (if available)
+    if (doc.content) {
+      const contentMatches = countMatches(doc.content, keyword);
+      if (contentMatches > 0) {
+        score += contentMatches * SCORE_WEIGHTS.CONTENT;
+        keywordMatched = true;
+      }
+    }
+
+    if (keywordMatched) matchedKeywords++;
+  }
+
+  // Multi-keyword bonus
+  if (matchedKeywords > 1) {
+    score *= SCORE_WEIGHTS.MULTI_KEYWORD_MULTIPLIER;
+  }
+
+  // Deprecation penalty
+  if (doc.deprecation && doc.deprecation.length > 0) {
+    score *= SCORE_WEIGHTS.DEPRECATION_PENALTY;
+  }
+
+  return score;
+}
+
+/**
+ * Search documents
+ */
+function searchDocuments(docs, keywords, type = 'doc') {
+  const results = [];
+
+  for (const doc of docs) {
+    const score = calculateScore(doc, keywords);
+
+    // Only include if score >= 1 (at least one keyword match)
+    if (score >= 1) {
+      // Extract snippet from content with keyword context
+      let snippet = '';
+      if (doc.content) {
+        for (const keyword of keywords) {
+          if (countMatches(doc.content, keyword) > 0) {
+            snippet = extractSnippet(doc.content, keyword);
+            break;
+          }
+        }
+      }
+      // Fallback to first sentences if no keyword match in content
+      if (!snippet && doc.content) {
+        snippet = extractFirstSentences(doc.content, 200);
+      }
+
+      results.push({
+        path: doc.path,
+        title: doc.title,
+        description: doc.description || '',
+        snippet,
+        type,
+        deprecation: doc.deprecation || null,
+        relevanceScore: score
+      });
+    }
+  }
+
+  return results.sort((a, b) => b.relevanceScore - a.relevanceScore);
+}
+
+/**
+ * Main search function
+ */
+async function search(keywords, limit = 10) {
+  // Filter keywords
+  const filteredKeywords = filterKeywords(keywords);
+
+  if (filteredKeywords.length === 0) {
+    console.error('No valid keywords provided after filtering stop words');
+    process.exit(1);
+  }
+
+  // Fetch indexes
+  const [docpagesIndex, queryIndex] = await Promise.all([
+    fetchWithCache('https://www.aem.live/docpages-index.json', 'docpages-index.json'),
+    fetchWithCache('https://www.aem.live/query-index.json', 'query-index.json')
+  ]);
+
+  // Create a map of deprecation warnings from query-index
+  const deprecationMap = new Map();
+  for (const doc of queryIndex.data) {
+    if (doc.deprecation && doc.deprecation.length > 0) {
+      deprecationMap.set(doc.path, doc.deprecation);
+    }
+  }
+
+  // Search docpages first and merge deprecation data
+  let docpagesData = docpagesIndex.data.map(doc => ({
+    ...doc,
+    deprecation: deprecationMap.get(doc.path) || doc.deprecation || null
+  }));
+  let results = searchDocuments(docpagesData, filteredKeywords, 'doc');
+
+  // If less than 5 results, search blog posts too
+  if (results.length < 5) {
+    const blogPosts = queryIndex.data.filter(doc => doc.path.startsWith('/blog/'));
+    const blogResults = searchDocuments(blogPosts, filteredKeywords, 'blog');
+    results = [...results, ...blogResults].sort((a, b) => b.relevanceScore - a.relevanceScore);
+  }
+
+  // Limit results if specified
+  if (limit > 0) {
+    results = results.slice(0, limit);
+  }
+
+  return results;
+}
+
+/**
+ * CLI entry point
+ */
+async function main() {
+  const args = process.argv.slice(2);
+
+  if (args.length === 0) {
+    console.error('Usage: search.js [--all] <keyword1> [keyword2] [keyword3] ...');
+    console.error('Example: search.js block decoration');
+    console.error('         search.js --all metadata');
+    console.error('');
+    console.error('Options:');
+    console.error('  --all    Return all results (default: limit to 10)');
+    process.exit(1);
+  }
+
+  // Check for --all flag
+  let limit = 10;
+  let keywords = args;
+
+  if (args[0] === '--all') {
+    limit = 0; // 0 means no limit
+    keywords = args.slice(1);
+  }
+
+  if (keywords.length === 0) {
+    console.error('No keywords provided');
+    process.exit(1);
+  }
+
+  try {
+    const results = await search(keywords, limit);
+    console.log(JSON.stringify(results, null, 2));
+  } catch (error) {
+    console.error('Search error:', error.message);
+    process.exit(1);
+  }
+}
+
+main();
diff --git a/.claude/.skills/generate-import-html/SKILL.md b/.claude/.skills/generate-import-html/SKILL.md
new file mode 100644
index 0000000..afedd00
--- /dev/null
+++ b/.claude/.skills/generate-import-html/SKILL.md
@@ -0,0 +1,265 @@
+---
+name: generate-import-html
+description: Generate structured HTML from authoring analysis for AEM Edge Delivery Services. Creates section structure, applies block tables, handles metadata, and manages images folder.
+---
+
+# Generate Import HTML
+
+Create plain HTML file with block structure from authoring analysis.
+
+## When to Use This Skill
+
+Use this skill when:
+- You have complete authoring analysis (all sequences have decisions)
+- You have section styling validation (from authoring-analysis)
+- Ready to generate the HTML file for preview
+
+**Invoked by:** page-import skill (Step 4)
+
+## Prerequisites
+
+From previous skills, you need:
+- ✅ Authoring analysis with block selections (from authoring-analysis)
+- ✅ Section styling decisions (from authoring-analysis Step 3e)
+- ✅ metadata.json with paths and metadata (from scrape-webpage)
+- ✅ cleaned.html with content (from scrape-webpage)
+- ✅ Block structures fetched (from authoring-analysis Step 3d)
+
+## Related Skills
+
+- **page-import** - Orchestrator that invokes this skill
+- **authoring-analysis** - Provides authoring decisions and styling validation
+- **scrape-webpage** - Provides metadata, paths, cleaned HTML, images
+- **preview-import** - Uses this skill's HTML output
+
+## ⚠️ CRITICAL REQUIREMENT: Complete Content Import
+
+**YOU MUST IMPORT ALL CONTENT FROM THE PAGE. PARTIAL IMPORT IS UNACCEPTABLE.**
+
+- ❌ NEVER truncate or skip sections due to length concerns
+- ❌ NEVER summarize or abbreviate content
+- ❌ NEVER use placeholders like "<!-- rest of content -->"
+- ❌ NEVER omit content because the page is "too long"
+- ✅ ALWAYS import every section from authoring analysis
+- ✅ ALWAYS include all text, images, and structure from cleaned.html
+- ✅ If you encounter length issues, generate the FULL HTML anyway
+
+**Validation requirement:** You MUST verify that the number of sections in your HTML matches the number of sections from identify-page-structure. If they don't match, you have made an error.
+
+---
+
+## HTML Generation Workflow
+
+### Structure Requirements
+
+**IMPORTANT CHANGE:** The AEM CLI now automatically wraps HTML content with headful structure (head, header, footer). You MUST generate ONLY the section content.
+
+**What to generate:**
+- ✅ Section divs with content: `<div>...</div>` (one per section)
+- ✅ Blocks as `<div class="block-name">` with nested divs
+- ✅ Default content (headings, paragraphs, links, images)
+- ✅ Section metadata blocks where validated in authoring-analysis
+
+**What NOT to generate:**
+- ❌ NO `<html>`, `<head>`, or `<body>` tags
+- ❌ NO `<header>` or `<footer>` elements
+- ❌ NO `<main>` wrapper element
+- ❌ NO head content (meta tags, title, etc. - this comes from project's head.html)
+
+**Structure format:**
+```html
+<div>
+  <!-- Section 1 content -->
+</div>
+<div>
+  <!-- Section 2 content with section-metadata if needed -->
+  <div class="section-metadata">
+    <div>
+      <div>Style</div>
+      <div>grey</div>
+    </div>
+  </div>
+  <!-- Section 2 blocks/content -->
+</div>
+<div>
+  <!-- Section 3 content -->
+</div>
+```
+
+**For detailed block structure patterns:** See `../page-import/resources/html-structure.md`
+
+---
+
+### Section Metadata Application
+
+**Apply validated decisions from authoring-analysis Step 3e:**
+
+**WITH section-metadata** (section provides container styling):
+```html
+<div>
+  <div class="section-metadata">
+    <div>
+      <div>Style</div>
+      <div>dark</div>
+    </div>
+  </div>
+  <div class="tabs">
+    <!-- Tabs block content -->
+  </div>
+</div>
+```
+
+**WITHOUT section-metadata** (background is block-specific):
+```html
+<div>
+  <div class="hero">
+    <!-- Hero block content with its own dark background -->
+  </div>
+</div>
+```
+
+**Important:**
+- Only migrate visible body content sections (skip header, navigation, footer - auto-generated)
+- Use consistent style names from identify-page-structure
+- **Apply validated decisions from authoring-analysis Step 3e** - Skip section-metadata for single-block sections where background is block-specific
+- Place `section-metadata` div at the start of each section that needs styling
+- The metadata div will be processed and removed by the platform
+- Each section is a separate top-level `<div>` element
+
+---
+
+### Page Metadata Block
+
+**Unless user explicitly requested to skip metadata**, use the metadata extracted from scrape-webpage to generate a metadata block.
+
+**Process:**
+
+**1. Review extracted metadata from metadata.json**
+
+**2. Map each property to standard format:**
+
+**Title:**
+- Compare source `title` (or `og:title`) with first H1 on page
+- If matches first H1 → Omit (platform defaults to H1)
+- If differs → Include as `title` property
+
+**Description:**
+- Compare source `description` (or `og:description`) with first paragraph
+- If matches first paragraph → Consider omitting (platform defaults to first paragraph)
+- If differs OR more descriptive → Include as `description` property
+- Check: 150-160 characters ideal
+
+**Image:**
+- Check source `og:image`
+- If matches first content image → Consider omitting (platform defaults to first image)
+- If custom social image → Include as `image` property
+- Ensure absolute URL or correct relative path
+- Check: 1200x630 pixels recommended
+
+**Canonical:**
+- If points to same page URL → Omit (platform auto-generates)
+- If points to different page → Include as `canonical` property
+
+**Tags:**
+- Map `article:tag` or `keywords` → comma-separated `tags` property
+
+**Properties to SKIP** (platform auto-populates):
+- `og:url`, `og:title`, `og:description`, `twitter:title`, `twitter:description`, `twitter:image`
+- `viewport`, `charset`, `X-UA-Compatible` (belong in head.html)
+
+**3. Generate metadata block HTML:**
+
+```html
+<div>
+  <div class="metadata">
+    <div>
+      <div>title</div>
+      <div>[Your mapped title]</div>
+    </div>
+    <div>
+      <div>description</div>
+      <div>[Your mapped description]</div>
+    </div>
+    <!-- Only include image if custom -->
+    <!-- Only include canonical if differs from page URL -->
+    <!-- Only include tags if present -->
+  </div>
+</div>
+```
+
+**Append metadata block as the last section div at the end of the HTML file.**
+
+**Detailed guidance:** See `resources/metadata-extraction.md` and `resources/metadata-mapping.md`
+
+---
+
+### Images Folder Management (CRITICAL)
+
+The images are currently in `./import-work/images/` and the HTML references them as `./images/...`. You MUST handle the images folder correctly:
+
+**Step 1: Determine the correct images folder location**
+
+Based on `paths.htmlFilePath` from metadata.json:
+- HTML file: `us/en/about.plain.html` → Images should be at: `us/en/images/`
+- HTML file: `products/widget.plain.html` → Images should be at: `products/images/`
+- HTML file: `index.plain.html` → Images should be at: `images/`
+
+**Rule:** Images folder goes in the same directory as the HTML file.
+
+**Step 2: Copy the images folder**
+
+```bash
+# Example: If HTML is at us/en/about.plain.html
+mkdir -p us/en/images
+cp -r ./import-work/images/* us/en/images/
+```
+
+**Step 3: Verify image paths in HTML are correct**
+
+The HTML should already reference images as `./images/...` which is correct for files in the same directory. No path changes needed in the HTML.
+
+**Example:**
+```
+HTML location: us/en/about.plain.html
+Images location: us/en/images/
+Image reference in HTML: <img src="./images/abc123.jpg">
+Result: ✅ Correct - browser resolves to us/en/images/abc123.jpg
+```
+
+---
+
+### Save HTML File
+
+**Save to:** Use `paths.htmlFilePath` from metadata.json (e.g., `us/en/about.plain.html`)
+
+Read the metadata.json file from scrape-webpage to get the correct file path.
+
+---
+
+## Validation Checklist (MANDATORY)
+
+Before proceeding to preview-import skill, verify:
+- ✅ Section count: HTML has the same number of top-level `<div>` sections as identified in identify-page-structure
+- ✅ All sequences: Every content sequence from authoring-analysis appears in the HTML
+- ✅ No truncation: No "..." or "<!-- more content -->" or similar placeholders
+- ✅ Complete text: All headings, paragraphs, and text from cleaned.html are present
+- ✅ All images: Every image reference from the scraped page is included
+- ✅ HTML file saved: HTML file written to disk at the correct path
+- ✅ Images folder copied: Images folder exists in the same directory as the HTML file
+- ✅ Images accessible: Verify that at least one image file exists in the copied images folder
+
+**If any validation check fails, STOP and fix before proceeding.**
+
+---
+
+## Output
+
+This skill provides:
+- ✅ HTML file at correct path (e.g., `us/en/about.plain.html`)
+- ✅ Images folder in same directory (e.g., `us/en/images/`)
+- ✅ Complete content import (all sections)
+- ✅ Proper block structure
+- ✅ Section metadata applied per validation
+- ✅ Page metadata block included
+
+**Next step:** Pass HTML file path to preview-import skill
diff --git a/.claude/.skills/generate-import-html/resources/metadata-extraction.md b/.claude/.skills/generate-import-html/resources/metadata-extraction.md
new file mode 100644
index 0000000..6fa4a96
--- /dev/null
+++ b/.claude/.skills/generate-import-html/resources/metadata-extraction.md
@@ -0,0 +1,320 @@
+# Metadata Extraction
+
+Extract and map metadata from source webpages to standard metadata structure.
+
+## Purpose
+
+Metadata extraction preserves SEO and social sharing properties when migrating pages. This resource explains how to map source page metadata to standard properties.
+
+## Key Principles
+
+### Leverage Platform Defaults
+
+The platform automatically generates metadata from page content when not explicitly provided:
+
+- **Title** → Defaults to first H1
+- **Description** → Defaults to first paragraph (10+ words)
+- **Image** → Defaults to first image or `/default-meta-image.png`
+- **Canonical** → Auto-generated from production domain
+
+**Only include metadata when it differs from defaults.**
+
+### Special Properties
+
+The platform provides convenience properties that auto-populate multiple metadata tags:
+
+- `title` → Auto-populates `og:title`, `twitter:title`, `<title>`
+- `description` → Auto-populates `og:description`, `twitter:description`
+- `image` → Auto-populates `og:image`, `og:image:secure_url`, `twitter:image`
+
+**Use these instead of separate og:* and twitter:* properties.**
+
+## Metadata Extraction Process
+
+Metadata is extracted automatically by the `analyze-webpage.js` script during Step 1 of page import. The script collects:
+
+- `<title>` tag content
+- All `<meta>` tags (both `name` and `property` attributes)
+- `<link rel="canonical">` href
+- JSON-LD structured data (`<script type="application/ld+json">`)
+
+## Mapping to Standard Properties
+
+Use the `metadata-mapping.md` resource for detailed mapping rules. Key decision points:
+
+### Title Mapping
+
+**Decision tree:**
+```
+Source has <title> tag?
+├─ Matches first H1 on page?
+│  └─ Omit (use platform default)
+└─ Differs from first H1?
+   └─ Include as "title" property
+```
+
+**Example:**
+- Source title: "Buy Widgets Online | WidgetCo"
+- First H1: "Buy Widgets Online"
+- Decision: Include title (adds brand name, differs from H1)
+
+### Description Mapping
+
+**Decision tree:**
+```
+Source has meta description?
+├─ Matches first paragraph?
+│  └─ Consider omitting (use platform default)
+├─ More descriptive than first paragraph?
+│  └─ Include as "description" property
+└─ Differs significantly?
+   └─ Include as "description" property
+```
+
+**Quality requirements:**
+- 150-160 characters ideal
+- Unique per page
+- Actionable and compelling
+
+### Image Mapping
+
+**Decision tree:**
+```
+Source has og:image?
+├─ Matches first content image?
+│  └─ Consider omitting (use platform default)
+├─ Custom social image?
+│  └─ Include as "image" property
+└─ No og:image?
+   └─ Check first image, omit if suitable
+```
+
+**Quality requirements:**
+- Absolute URL (or correct relative path)
+- 1200x630 pixels recommended for social sharing
+- Appropriate for social preview
+
+### Canonical Mapping
+
+**Decision tree:**
+```
+Source has canonical link?
+├─ Points to same page?
+│  └─ Omit (platform auto-generates)
+├─ Points to different page?
+│  └─ Include as "canonical" property (syndicated content)
+└─ Uses .html extension?
+   └─ Include, or use bulk metadata for extension pattern
+```
+
+### Tags Mapping
+
+**Sources:**
+- `<meta name="keywords">` content
+- `<meta property="article:tag">` (multiple tags)
+- `<meta name="news_keywords">`
+
+**Mapping:**
+```
+Multiple sources?
+└─ Combine into comma-separated "tags" property
+   Example: "e-commerce, widgets, online shopping"
+```
+
+### Properties to Skip
+
+**Technical metadata (belongs in head.html):**
+- `viewport`
+- `charset`
+- `X-UA-Compatible`
+- `theme-color`
+
+**Auto-populated by platform (redundant):**
+- `og:url` (use canonical instead)
+- `og:title` (use title instead)
+- `og:description` (use description instead)
+- `twitter:title` (use title instead)
+- `twitter:description` (use description instead)
+- `twitter:image` (use image instead)
+
+## Handling JSON-LD Structured Data
+
+JSON-LD can contain valuable structured data. Decision tree:
+
+```
+Has JSON-LD?
+│
+├─ Page-specific schema (Article, Product, Event)?
+│  │
+│  ├─ Small payload (<500 chars)?
+│  │  └─ Include in metadata block
+│  │
+│  └─ Large payload?
+│     └─ Implement in client-side JS decoration
+│
+└─ Site-wide schema (Organization, WebSite)?
+   └─ Move to head.html (applies to all pages)
+```
+
+**Example - Include in metadata:**
+```html
+<div>
+  <div class="metadata">
+    <div>
+      <div>schema.org</div>
+      <div>{"@context":"https://schema.org","@type":"Article",...}</div>
+    </div>
+  </div>
+</div>
+```
+
+**Example - Move to head.html:**
+```html
+<!-- head.html -->
+<script type="application/ld+json">
+{
+  "@context": "https://schema.org",
+  "@type": "Organization",
+  "name": "WidgetCo",
+  "url": "https://widgetco.com"
+}
+</script>
+```
+
+## Generating the Metadata Block
+
+### HTML Format
+
+Place at the end of `<main>` content, before closing `</main>` tag:
+
+```html
+<div>
+  <div class="metadata">
+    <div>
+      <div>title</div>
+      <div>Buy Widgets Online | WidgetCo</div>
+    </div>
+    <div>
+      <div>description</div>
+      <div>Shop our extensive collection of high-quality widgets with fast shipping and expert support.</div>
+    </div>
+    <div>
+      <div>image</div>
+      <div><img src="./media_social-image.jpg" alt="WidgetCo social preview"></div>
+    </div>
+    <div>
+      <div>tags</div>
+      <div>e-commerce, widgets, online shopping</div>
+    </div>
+  </div>
+</div>
+```
+
+### Markdown Format
+
+Place at the end of the document:
+
+```markdown
+---
+
+## Metadata
+
+| Property    | Value                                                                           |
+|-------------|---------------------------------------------------------------------------------|
+| title       | Buy Widgets Online \| WidgetCo                                                  |
+| description | Shop our extensive collection of high-quality widgets with fast shipping.       |
+| image       | ![WidgetCo social preview](./media_social-image.jpg)                            |
+| tags        | e-commerce, widgets, online shopping                                            |
+```
+
+## Documenting Decisions
+
+When generating metadata blocks, document why properties were included or omitted:
+
+```markdown
+## Metadata Decisions
+
+### Included Properties
+- **title**: "Buy Widgets Online | WidgetCo" - Differs from H1, includes brand
+- **description**: Custom SEO description - More compelling than first paragraph
+- **image**: ./media_social-image.jpg - Custom social image, not first content image
+- **tags**: "e-commerce, widgets, online shopping" - Mapped from article:tag properties
+
+### Omitted Properties
+- **canonical**: Points to same page URL - platform will auto-generate
+- **og:title, twitter:title**: Redundant - platform auto-populates from title
+- **og:description**: Redundant - platform auto-populates from description
+- **viewport**: Technical metadata - Belongs in head.html
+
+### Recommendations
+- Consider bulk metadata sheet if many pages use canonical with .html extension
+- Monitor social preview rendering (Twitter Card Validator, Facebook Debugger)
+```
+
+## Quality Checks
+
+Before finalizing the metadata block:
+
+- ✅ **Title**: Under 60 characters (55-60 ideal)
+- ✅ **Description**: 150-160 characters
+- ✅ **Image**: Absolute URL or correct relative path
+- ✅ **Image**: 1200x630 pixels for optimal social sharing
+- ✅ **No redundancy**: Removed og:*/twitter:* properties that platform auto-populates
+- ✅ **Defaults leveraged**: Omitted properties that match platform defaults
+
+## Troubleshooting
+
+### No metadata found
+
+**Cause:** Page has minimal or no metadata tags
+
+**Solution:** Extract defaults from page content:
+- Title → First H1
+- Description → First paragraph (if 10+ words)
+- Image → First image with suitable dimensions
+
+### Inconsistent metadata
+
+**Cause:** `<title>`, `og:title`, `twitter:title` all differ
+
+**Solution:**
+1. Identify most appropriate version (usually og:title or <title>)
+2. Document the inconsistency in decision notes
+3. Recommend to user if clarification needed
+
+### Large JSON-LD payload
+
+**Cause:** Complex structured data (>500 characters)
+
+**Solution:**
+- Don't include in metadata block (bloats page)
+- Recommend client-side JS decoration (load async)
+- Or move to head.html if site-wide
+
+### Relative image URLs
+
+**Cause:** `og:image` is relative path, not absolute
+
+**Solution:**
+```javascript
+// Convert relative to absolute
+const baseUrl = new URL(sourceUrl).origin;
+const absoluteImageUrl = new URL(relativeImagePath, baseUrl).href;
+```
+
+## Related Resources
+
+- **metadata-mapping.md** - Comprehensive mapping rules and examples
+- https://www.aem.live/docs/metadata - Platform metadata documentation
+- https://www.aem.live/developer/block-collection/metadata - Metadata block reference
+
+## Integration Notes
+
+The metadata extraction process is integrated into the page-import workflow:
+
+1. **Step 1**: `analyze-webpage.js` extracts raw metadata from source page
+2. **Step 2-3**: Analyze content structure (identify H1, first paragraph, first image)
+3. **Step 4**: Map metadata to standard properties, generate metadata block
+4. **Step 5**: Append metadata block to end of generated HTML (unless user explicitly skips)
+
+The metadata block is included by default. To skip: user must explicitly request "no metadata" or "skip metadata".
diff --git a/.claude/.skills/generate-import-html/resources/metadata-mapping.md b/.claude/.skills/generate-import-html/resources/metadata-mapping.md
new file mode 100644
index 0000000..b296890
--- /dev/null
+++ b/.claude/.skills/generate-import-html/resources/metadata-mapping.md
@@ -0,0 +1,419 @@
+# Metadata Mapping Reference
+
+Detailed mapping rules for converting source webpage metadata to standard metadata properties.
+
+## Special Properties Reference
+
+### canonical
+- **Used in:** `<link rel="canonical">`, `<meta property="og:url">`, `<meta name="twitter:url">`
+- **Default:** Auto-generated using production domain
+- **When to include:** Only if pointing to different page (e.g., syndicated content)
+
+### canonical:extension
+- **Purpose:** Defines file extension for canonical URLs (e.g., `.html`)
+- **Best practice:** Use in bulk metadata sheet for site-wide consistency
+- **Example:** `canonical:extension: .html`
+
+### description
+- **Used in:** `<meta name="description">`, `<meta property="og:description">`, `<meta name="twitter:description">`
+- **Default:** First paragraph with 10+ words
+- **When to include:** Only if custom description needed for SEO/social
+
+### image
+- **Used in:** `<meta property="og:image">`, `<meta property="og:image:secure_url">`, `<meta name="twitter:image">`
+- **Default:** First image on page, or `/default-meta-image.png`
+- **When to include:** Custom social sharing image
+- **Requirements:** Absolute URL, 1200x630 recommended
+
+### title
+- **Used in:** `<title>`, `<meta property="og:title">`, `<meta name="twitter:title">`
+- **Default:** First H1 on page
+- **When to include:** Only if differs from first H1
+
+### title:suffix
+- **Purpose:** Automatically appends suffix to title (e.g., `| Adobe`)
+- **Best practice:** Use in bulk metadata sheet
+- **Example:** `title:suffix: | Adobe`
+
+### tags
+- **Rendered as:** `<meta property="article:tag">` (one per tag)
+- **Format:** Comma-separated or bullet list
+- **Example:** `web development, edge delivery, performance`
+
+### json-ld
+- **Rendered as:** `<script type="application/ld+json">`
+- **Note:** Consider client-side JS or head.html as alternatives
+- **Use case:** Page-specific structured data
+
+---
+
+## Detailed Mapping Rules
+
+### Title Mapping
+
+```
+Source                    → Property
+──────────────────────────────────────────
+<title>                   → title (only if differs from first H1)
+og:title                  → title (if different from <title>)
+twitter:title             → title (if different from <title>)
+
+Note: Platform auto-populates og:title and twitter:title from title
+```
+
+**Decision Logic:**
+1. Extract `<title>`, `og:title`, `twitter:title` from source
+2. If all consistent → Use single `title` property
+3. If inconsistent → Document conflict, choose best one (typically `<title>`)
+4. If title will match first H1 in content → Omit (rely on platform default)
+
+**Examples:**
+
+```markdown
+# Scenario 1: Consistent title, differs from H1
+Source:
+  <title>About Us | Acme Corp</title>
+  <meta property="og:title" content="About Us | Acme Corp">
+  <meta name="twitter:title" content="About Us | Acme Corp">
+  Page has H1: "About Our Company"
+
+Metadata:
+  title: About Us | Acme Corp
+
+Reason: Title is consistent across sources but differs from H1
+```
+
+```markdown
+# Scenario 2: Title matches H1
+Source:
+  <title>About Our Company</title>
+  Page has H1: "About Our Company"
+
+Metadata:
+  (omit title property)
+
+Reason: Platform will use H1 as default
+```
+
+```markdown
+# Scenario 3: Inconsistent titles
+Source:
+  <title>About Us | Acme Corp</title>
+  <meta property="og:title" content="Learn About Acme Corporation">
+
+Metadata:
+  title: About Us | Acme Corp
+
+Note: Document the conflict. Chose <title> as primary.
+Alternative: Use og:title value if it's better for social sharing.
+```
+
+---
+
+### Description Mapping
+
+```
+Source                    → Property
+──────────────────────────────────────────
+<meta name="description"> → description
+og:description            → description (if different from meta description)
+twitter:description       → description (if different from meta description)
+
+Note: Platform auto-populates og:description and twitter:description from description
+```
+
+**Decision Logic:**
+1. Extract all description sources
+2. If consistent → Use single `description` property
+3. If inconsistent → Choose best one (typically meta description)
+4. If matches first paragraph (10+ words) → Consider omitting
+
+**Examples:**
+
+```markdown
+# Scenario 1: Consistent description
+Source:
+  <meta name="description" content="Learn about our company history and values">
+  <meta property="og:description" content="Learn about our company history and values">
+
+Metadata:
+  description: Learn about our company history and values
+```
+
+```markdown
+# Scenario 2: Matches first paragraph
+Source:
+  <meta name="description" content="Welcome to our website">
+  First paragraph: "Welcome to our website. We are glad you're here."
+
+Metadata:
+  (consider omitting description)
+
+Note: Platform will use first paragraph. Consider if meta description is sufficient.
+```
+
+---
+
+### Image Mapping
+
+```
+Source                    → Property
+──────────────────────────────────────────
+og:image                  → image
+twitter:image             → image (if different from og:image)
+
+Note: Platform auto-populates og:image and twitter:image from image
+```
+
+**Decision Logic:**
+1. Prefer `og:image` as primary source
+2. If `twitter:image` differs → Choose best or document
+3. If image is first image on page → Consider omitting
+4. Ensure absolute URL or correct relative path
+
+**Examples:**
+
+```markdown
+# Scenario 1: Custom social image
+Source:
+  <meta property="og:image" content="https://example.com/social-share.jpg">
+  First image on page: hero-background.jpg
+
+Metadata:
+  image: https://example.com/social-share.jpg
+
+Reason: Custom social sharing image differs from first page image
+```
+
+```markdown
+# Scenario 2: Matches first image
+Source:
+  <meta property="og:image" content="https://example.com/hero.jpg">
+  First image on page: https://example.com/hero.jpg
+
+Metadata:
+  (consider omitting image)
+
+Reason: Platform will use first image as default
+```
+
+---
+
+### Canonical Mapping
+
+```
+Source                         → Property
+─────────────────────────────────────────────
+<link rel="canonical">         → canonical (only if custom URL needed)
+og:url                         → canonical (if consistent with link rel)
+twitter:url                    → canonical (if consistent with link rel)
+
+Note: Platform auto-generates canonical if omitted
+```
+
+**Decision Logic:**
+1. If canonical points to same page → Omit (Platform auto-generates)
+2. If canonical points to different page → Include (syndicated content)
+3. If URL needs extension → Consider `canonical:extension` in bulk metadata
+
+**Examples:**
+
+```markdown
+# Scenario 1: Same page canonical
+Source:
+  <link rel="canonical" href="https://example.com/about">
+  Current page: https://example.com/about
+
+Metadata:
+  (omit canonical)
+
+Reason: Platform will auto-generate canonical for same page
+```
+
+```markdown
+# Scenario 2: Syndicated content
+Source:
+  <link rel="canonical" href="https://originalsource.com/article">
+  Current page: https://example.com/republished-article
+
+Metadata:
+  canonical: https://originalsource.com/article
+
+Reason: Points to original source for syndicated content
+```
+
+---
+
+### Tags Mapping
+
+```
+Source                    → Property
+──────────────────────────────────────────
+article:tag (multiple)    → tags (comma-separated or bullet list)
+keywords                  → tags (if article:tag not present)
+```
+
+**Format Options:**
+- **Comma-separated:** `tag1, tag2, tag3`
+- **Bullet list:** Each tag on new line with bullet
+
+**Examples:**
+
+```markdown
+# Scenario 1: Multiple article:tag
+Source:
+  <meta property="article:tag" content="web development">
+  <meta property="article:tag" content="performance">
+  <meta property="article:tag" content="edge delivery">
+
+Metadata:
+  tags: web development, performance, edge delivery
+```
+
+```markdown
+# Scenario 2: Keywords fallback
+Source:
+  <meta name="keywords" content="web, development, seo">
+  (no article:tag present)
+
+Metadata:
+  tags: web, development, seo
+```
+
+---
+
+### Other Standard Properties
+
+```
+Source                    → Property
+──────────────────────────────────────────
+author / article:author   → author
+robots                    → robots
+article:published_time    → article:published_time
+article:modified_time     → article:modified_time
+```
+
+**Include these as-is when present and relevant.**
+
+---
+
+## Properties to Skip
+
+### Handled Elsewhere (Not Metadata)
+
+Skip these - they belong in `head.html`:
+- `viewport`
+- `charset`
+- `X-UA-Compatible`
+- `theme-color`
+
+### Auto-populated by Platform
+
+Skip these - platform generates from canonical/title/description:
+- `og:url` (if same as canonical)
+- `twitter:url` (if same as canonical)
+- `og:title` (if same as title)
+- `twitter:title` (if same as title)
+- `og:description` (if same as description)
+- `twitter:description` (if same as description)
+
+---
+
+## Metadata Categories
+
+### Essential SEO (always include if present and differs from defaults)
+- `title`
+- `description`
+- `keywords` / `tags`
+- `robots`
+- `canonical` (if points elsewhere)
+
+### Social Sharing (map to special properties)
+- `og:title` → `title`
+- `og:description` → `description`
+- `og:image` → `image`
+- `twitter:title` → `title`
+- `twitter:description` → `description`
+- `twitter:image` → `image`
+
+### Article/Content (include if content is article-type)
+- `article:published_time` → `article:published_time` (keep as-is)
+- `article:modified_time` → `article:modified_time` (keep as-is)
+- `article:author` → `author`
+- `article:tag` → `tags`
+
+### Site-level (consider bulk metadata instead)
+- `og:site_name`
+- `og:locale`
+- `twitter:site`
+- `canonical:extension`
+- `title:suffix`
+
+---
+
+## JSON-LD Decision Guidelines
+
+### Use Metadata Block (json-ld property)
+
+**When:**
+- ✅ Schema is unique to this page
+- ✅ Schema uses page-specific data (title, date, author from this page)
+- ✅ Quick migration is priority
+
+**Example:**
+```json
+{
+  "@type": "Article",
+  "headline": "This Page's Title",
+  "datePublished": "2024-01-15",
+  "author": "John Doe"
+}
+```
+
+### Use Client-side JS (scripts.js decoration)
+
+**When:**
+- ✅ Schema needs dynamic generation
+- ✅ Schema pulls from page content at runtime
+- ✅ Want consistency across multiple page types
+
+### Use head.html
+
+**When:**
+- ✅ Schema is site-wide (Organization, WebSite)
+- ✅ Schema is identical across all pages
+- ✅ No page-specific data needed
+
+**Example:**
+```json
+{
+  "@type": "Organization",
+  "name": "Acme Corp",
+  "url": "https://example.com"
+}
+```
+
+---
+
+## Quality Guidelines
+
+**Title:**
+- Under 60 characters for good SERP display
+- Include primary keyword
+- Avoid keyword stuffing
+
+**Description:**
+- 150-160 characters optimal for SERP display
+- Compelling call-to-action
+- Include relevant keywords naturally
+
+**Image:**
+- Absolute URL or correct relative path
+- 1200x630 pixels recommended for social sharing
+- Under 1MB file size
+- Relevant to page content
+
+**Tags:**
+- 3-7 tags per page
+- Relevant to content
+- Consistent with site taxonomy
diff --git a/.claude/.skills/identify-page-structure/SKILL.md b/.claude/.skills/identify-page-structure/SKILL.md
new file mode 100644
index 0000000..bbda55f
--- /dev/null
+++ b/.claude/.skills/identify-page-structure/SKILL.md
@@ -0,0 +1,213 @@
+---
+name: identify-page-structure
+description: Identify section boundaries and content sequences within a scraped webpage for AEM Edge Delivery Services import. Performs two-level analysis (sections, then sequences per section) and surveys available blocks.
+---
+
+# Identify Page Structure
+
+Analyze webpage structure using two-level hierarchy: sections, then content sequences within each section.
+
+## When to Use This Skill
+
+Use this skill when:
+- You have scraped webpage output (screenshot, HTML, metadata)
+- Need to identify section boundaries and content sequences
+- Ready to understand page structure before making authoring decisions
+
+**Invoked by:** page-import skill (Step 2)
+
+## Prerequisites
+
+From scrape-webpage skill, you need:
+- ✅ screenshot.png showing full page
+- ✅ cleaned.html with page content
+- ✅ metadata.json with paths
+
+## Related Skills
+
+- **page-import** - Orchestrator that invokes this skill
+- **scrape-webpage** - Provides input (screenshot, HTML)
+- **page-decomposition** - This skill invokes it for EACH section
+- **block-inventory** - This skill invokes it to survey available blocks
+- **authoring-analysis** - Uses this skill's output to make authoring decisions
+
+## Key Concepts
+
+**CRITICAL:** Content follows a strict two-level hierarchy:
+
+```
+DOCUMENT
+├── SECTION (top-level container with optional metadata)
+│   ├── Content Sequence 1 (default content OR block)
+│   ├── Content Sequence 2 (default content OR block)
+│   └── ...
+├── SECTION
+│   └── Content Sequence 1
+└── ...
+```
+
+**This skill analyzes BOTH levels:**
+- Level 1: Section boundaries (Step 2a)
+- Level 2: Content sequences within EACH section (Step 2b per section)
+
+## Structure Identification Workflow
+
+### Step 2a: Identify Section Boundaries (Level 1)
+
+Examine the **screenshot** to find visual/thematic breaks that indicate new sections.
+
+**Visual cues for section boundaries:**
+- Background color changes (white → grey → dark → white)
+- Spacing/padding changes (tight → wide → normal)
+- Clear horizontal breaks or dividers
+- Thematic content shifts
+
+**What to exclude:**
+- Header/navigation (auto-populated)
+- Footer (auto-populated)
+- Cookie banners, popups
+
+**For each section, note:**
+- Section number (sequential: 1, 2, 3...)
+- Visual style (light, dark, grey, accent)
+- Brief overview of what's in it
+
+**Example output:**
+```
+Section 1: light background, hero content
+Section 2: light background, grid of features
+Section 3: grey background, article cards
+Section 4: dark background, tabs
+```
+
+---
+
+### Step 2b: Analyze Content Sequences Within Each Section (Level 2)
+
+For EACH section identified in Step 2a, analyze its internal content sequences.
+
+**What is a "content sequence"?**
+A vertical flow of related content that will become EITHER:
+- Default content (headings, paragraphs, lists, inline images)
+- A block (structured, repeating, or interactive component)
+
+**Breaking points between sequences:**
+- Change from default content → block
+- Change from block → different block
+- Change from block → default content
+
+**INVOKE page-decomposition skill FOR EACH SECTION** to get neutral descriptions.
+
+**For each section, get:**
+- Sequence 1: [Neutral description - NO block names yet]
+- Sequence 2: [Neutral description]
+- ...
+
+**Example output:**
+```
+Section 1 (light):
+  - Sequence 1: Large centered heading, paragraph, two buttons
+  - Sequence 2: Two images displayed side-by-side
+
+Section 2 (light):
+  - Sequence 1: Centered heading
+  - Sequence 2: Grid of 8 items, each with icon and short text
+  - Sequence 3: Two centered buttons
+
+Section 3 (grey):
+  - Sequence 1: Eyebrow text, heading, paragraph, button
+  - Sequence 2: Four items in grid, each with image, category tag, heading, description
+
+Section 4 (dark):
+  - Sequence 1: Tab navigation with three switchable content panels
+```
+
+---
+
+### Step 2.5: Survey Available Blocks
+
+**STOP: Before making any authoring decisions, understand what blocks are available.**
+
+**INVOKE block-inventory skill** to catalog available blocks.
+
+**Why this matters:**
+Real authors see a block library and choose from available options. You need the same context to make authentic authoring decisions following David's Model.
+
+**What this provides:**
+- Local blocks already in project
+- Common Block Collection blocks that can be added
+- Purpose/description for each block
+- Live example URLs
+
+**Example output:**
+```
+Available Blocks:
+
+LOCAL BLOCKS:
+- custom-banner: Special promotional banner
+- testimonial-slider: Customer testimonials carousel
+
+BLOCK COLLECTION AVAILABLE:
+- hero: Large heading, text, buttons for page intro
+- cards: Grid of items with images/text
+- columns: Side-by-side content layout
+- accordion: Expandable Q&A sections
+- tabs: Switchable content panels
+- carousel: Rotating image/content displays
+- quote: Highlighted testimonials
+- fragment: Reusable content sections
+```
+
+---
+
+## Output Format
+
+This skill provides complete page structure:
+
+**1. Section boundaries with styling:**
+```
+Section 1: light background
+Section 2: light background
+Section 3: grey background (#f5f5f5)
+Section 4: dark background (#1a1a1a)
+```
+
+**2. Content sequences per section (neutral descriptions):**
+```
+Section 1 (light):
+  - Sequence 1: Large centered heading, paragraph, two call-to-action buttons
+  - Sequence 2: Two images displayed side-by-side
+
+Section 2 (light):
+  - Sequence 1: Single centered heading
+  - Sequence 2: Grid of 8 items, each with icon and short text
+  - Sequence 3: Two centered buttons
+
+[Continue for all sections...]
+```
+
+**3. Block palette:**
+```
+LOCAL BLOCKS: [list]
+BLOCK COLLECTION AVAILABLE: [list with purposes]
+```
+
+**Next step:** Pass these outputs to authoring-analysis skill
+
+---
+
+## Key Principles
+
+**Two-level analysis is mandatory:**
+- You MUST identify sections first (2a)
+- Then analyze each section's content sequences (2b)
+- Don't skip levels or combine them
+
+**Stay neutral at this stage:**
+- Describe WHAT you see, not WHAT it should be
+- "Grid of items with images" not "Cards block"
+- Authoring decisions come in next skill
+
+**Block inventory before decisions:**
+- Survey blocks BEFORE making any authoring choices
+- Authors see a library and choose - you need same context
diff --git a/.claude/.skills/page-decomposition/SKILL.md b/.claude/.skills/page-decomposition/SKILL.md
new file mode 100644
index 0000000..09816b2
--- /dev/null
+++ b/.claude/.skills/page-decomposition/SKILL.md
@@ -0,0 +1,324 @@
+---
+name: page-decomposition
+description: Analyze content sequences within a section and provide neutral descriptions for AEM Edge Delivery Services. Invoked per section during page import to identify breaking points between default content and blocks.
+---
+
+# Page Decomposition
+
+Analyze content sequences within a section and provide neutral descriptions without assigning block names.
+
+## When to Use This Skill
+
+This skill is called by **identify-page-structure** for EACH section to:
+- Identify content sequences within that section
+- Provide neutral descriptions (NO block names yet)
+- Identify breaking points between sequences
+- Enable authoring-focused decisions later
+
+**IMPORTANT:** This skill analyzes ONE section at a time, not the whole page.
+
+## Input Required
+
+From the calling skill (identify-page-structure), you need:
+- Section visual description and boundaries
+- Screenshot showing the section
+- Cleaned HTML content for the section
+
+## Related Skills
+
+- **page-import** - Top-level orchestrator
+- **identify-page-structure** - Invokes this skill for each section (Step 2b)
+- **block-inventory** - Provides available blocks AFTER decomposition
+- **content-modeling** - Makes authoring decisions AFTER decomposition
+- **content-driven-development** - References section structure in html-structure.md
+
+## Key Concepts
+
+**Content Hierarchy:**
+```
+DOCUMENT
+├── SECTION (top-level, analyzed by identify-page-structure Step 2a)
+│   ├── Content Sequence 1 ← THIS SKILL IDENTIFIES THESE
+│   ├── Content Sequence 2 ← THIS SKILL IDENTIFIES THESE
+│   └── ...
+└── SECTION
+    └── Content Sequence 1
+```
+
+**What is a "content sequence"?**
+A vertical flow of related content that will eventually become:
+- Default content (headings, paragraphs, lists, inline images), OR
+- A block (structured, repeating, or interactive component)
+
+**Breaking points between sequences:**
+- Visual/semantic shift in content type
+- Change from prose → structured pattern
+- Change from one pattern → different pattern
+
+**Philosophy:**
+- Describe WHAT you see, not WHAT it should be
+- "Two images side-by-side" not "Columns block"
+- "Grid of 8 items with icons" not "Cards block"
+- Stay neutral - authoring decisions come later
+
+## Decomposition Workflow
+
+**Context:** identify-page-structure has already identified section boundaries (Step 2a). This skill is invoked FOR ONE SECTION to analyze its internal content sequences.
+
+---
+
+### Step 1: Examine the Section
+
+Look at the screenshot and HTML for THIS section only.
+
+**What to observe:**
+- Vertical flow of content from top to bottom
+- Where content changes type or pattern
+- Visual groupings or breaks
+
+**Ignore:**
+- Other sections (out of scope)
+- Section styling (already identified by page-import)
+- Block names (stay neutral)
+
+**Output:** Mental model of content flow within this section
+
+---
+
+### Step 2: Identify Breaking Points
+
+Find where content shifts from one type/pattern to another.
+
+**Breaking point indicators:**
+- Prose text → Structured grid
+- Heading/paragraph → Side-by-side images
+- One repeating pattern → Different repeating pattern
+- Structured content → Prose text
+
+**Example within a section:**
+```
+Content flows top to bottom:
+- Large heading
+- Paragraph
+- Two buttons
+[BREAK] ← Visual/semantic shift
+- Two images displayed side-by-side
+```
+
+**Output:** List of breaking points
+
+---
+
+### Step 3: Define Content Sequences
+
+Between each breaking point is a content sequence.
+
+**For each sequence, describe:**
+- What elements it contains (heading, paragraph, images, etc.)
+- How they're arranged (stacked, side-by-side, in a grid)
+- Quantity (one heading, two images, grid of 8 items)
+
+**Use neutral language:**
+- ✅ "Two images displayed side-by-side"
+- ❌ "Columns block with two images"
+- ✅ "Grid of 8 items, each with icon and short text"
+- ❌ "Cards block"
+- ✅ "Large centered heading, paragraph, two buttons stacked vertically"
+- ❌ "Hero block"
+
+**Output:** Neutral descriptions for each sequence
+
+---
+
+### Step 4: Return Structured Output
+
+Provide content sequences for this section in structured format.
+
+**Output format:**
+```javascript
+{
+  sectionNumber: 1,  // From identify-page-structure
+  sequences: [
+    {
+      sequenceNumber: 1,
+      description: "Large centered heading, paragraph, two buttons stacked vertically"
+    },
+    {
+      sequenceNumber: 2,
+      description: "Two images displayed side-by-side"
+    }
+  ]
+}
+```
+
+**This enables:**
+- Clear understanding of section's internal structure
+- Neutral foundation for authoring decisions
+- Separation of description from implementation
+
+---
+
+## Section Metadata Format
+
+**Table format:**
+```markdown
++------------------------------+
+| Section Metadata             |
++------------------+-----------+
+| style            | light     |
++------------------+-----------+
+```
+
+**Placement:** At the start of each section, before content
+
+**Usage:** Applied by generate-import-html skill when generating final HTML
+
+---
+
+## Examples
+
+### Example 1: Hero Section
+
+**Input:** "Section 1 (light background): Large prominent content at top of page"
+
+**Visual observation:**
+- Large centered heading
+- Paragraph text below it
+- Two call-to-action buttons
+[BREAK - visual shift]
+- Two large images displayed next to each other
+
+**Output:**
+```javascript
+{
+  sectionNumber: 1,
+  sequences: [
+    {
+      sequenceNumber: 1,
+      description: "Large centered heading, paragraph, two call-to-action buttons stacked vertically"
+    },
+    {
+      sequenceNumber: 2,
+      description: "Two large images displayed side-by-side"
+    }
+  ]
+}
+```
+
+---
+
+### Example 2: Features Section
+
+**Input:** "Section 2 (light background): Grid of feature items"
+
+**Visual observation:**
+- Centered heading
+[BREAK - shift to structured pattern]
+- Grid of 8 items
+- Each item has: small icon, short text description
+[BREAK - shift back to simple elements]
+- Two centered buttons
+
+**Output:**
+```javascript
+{
+  sectionNumber: 2,
+  sequences: [
+    {
+      sequenceNumber: 1,
+      description: "Single centered heading"
+    },
+    {
+      sequenceNumber: 2,
+      description: "Grid of 8 items, each with small icon and short text description"
+    },
+    {
+      sequenceNumber: 3,
+      description: "Two centered buttons"
+    }
+  ]
+}
+```
+
+---
+
+### Example 3: Article Cards Section
+
+**Input:** "Section 3 (grey background): Blog articles"
+
+**Visual observation:**
+- Eyebrow text "Latest Articles"
+- Large heading
+- Paragraph description
+- Browse button
+[BREAK - shift to repeating pattern]
+- 4 items in grid
+- Each item: image, category tag, heading, short description, read link
+
+**Output:**
+```javascript
+{
+  sectionNumber: 3,
+  sequences: [
+    {
+      sequenceNumber: 1,
+      description: "Eyebrow text, large heading, paragraph description, browse button - all stacked vertically"
+    },
+    {
+      sequenceNumber: 2,
+      description: "Grid of 4 items, each with image, category tag, heading, description, and read link"
+    }
+  ]
+}
+```
+
+---
+
+### Example 4: Simple Content Section
+
+**Input:** "Section 4 (light background): Body content"
+
+**Visual observation:**
+- Multiple paragraphs of text
+- Some inline images within the text
+- Headings interspersed (H2, H3)
+- No clear breaking points - content flows naturally
+
+**Output:**
+```javascript
+{
+  sectionNumber: 4,
+  sequences: [
+    {
+      sequenceNumber: 1,
+      description: "Flowing prose content: multiple paragraphs with inline images and headings (H2, H3)"
+    }
+  ]
+}
+```
+
+**Note:** This entire section is one sequence because content flows naturally without structural breaks.
+
+---
+
+## Common Mistakes to Avoid
+
+**Using block names in descriptions:**
+❌ "Hero block with heading and buttons"
+✓ "Large centered heading, paragraph, two buttons stacked vertically"
+
+**Not identifying breaking points:**
+❌ Describing entire section as one sequence when there are clear shifts
+✓ Identifying where content type changes and breaking into sequences
+
+**Being too granular:**
+❌ Each element as separate sequence: "Heading", "Paragraph", "Button"
+✓ Related elements together: "Heading, paragraph, two buttons stacked vertically"
+
+**Mixing analysis levels:**
+❌ Analyzing multiple sections at once
+✓ Focus on ONE section at a time (per invocation)
+
+**Making authoring decisions:**
+❌ "This should be a cards block because..."
+✓ "Grid of 4 items with images and text" (neutral description)
diff --git a/.claude/.skills/page-import/SKILL.md b/.claude/.skills/page-import/SKILL.md
new file mode 100644
index 0000000..40b8c45
--- /dev/null
+++ b/.claude/.skills/page-import/SKILL.md
@@ -0,0 +1,203 @@
+---
+name: page-import
+description: Import a single webpage from any URL to structured HTML content for authoring in AEM Edge Delivery Services. Scrapes the page, analyzes structure, maps to existing blocks, and generates HTML for immediate local preview. Also triggered by terms like "migrate", "migration", or "migrating".
+---
+
+# Page Import Orchestrator
+
+You are an orchestrator of a website page import/migration. You have specialized Skills at your disposal for each phase of the import workflow. Below is a high-level overview of what you're going to do.
+
+## When to Use This Skill
+
+Use this skill when:
+- Importing or migrating individual pages from existing websites
+- Converting competitor pages for reference or analysis
+- Creating content files from design prototypes or staging sites
+
+**Do NOT use this skill for:**
+- Building new blocks from scratch (use **content-driven-development** skill)
+- Modifying existing block code (use **building-blocks** skill)
+- Designing content models (use **content-modeling** skill)
+
+## Scope
+
+**This skill imports/migrates main content only:**
+- ✅ Import: Hero sections, features, testimonials, CTAs, body content
+- ❌ Skip: Header, navigation, footer (handled by dedicated skills)
+
+## Philosophy
+
+Follow **David's Model** (https://www.aem.live/docs/davidsmodel):
+- Prioritize authoring experience over developer convenience
+- Ask "How would an author in Word/Google Docs create this?"
+- Minimize blocks - prefer default content where possible
+- Use Block Collection content models
+
+## Available Sub-Skills
+
+This orchestrator delegates work to:
+- **scrape-webpage** - Extract content, metadata, and images from source URL
+- **identify-page-structure** - Identify section boundaries and content sequences
+- **authoring-analysis** - Make authoring decisions (default content vs blocks)
+- **generate-import-html** - Create structured HTML file
+- **preview-import** - Verify in local dev server
+
+These skills invoke additional skills as needed:
+- **page-decomposition** - (via identify-page-structure) Analyze content sequences per section
+- **block-inventory** - (via identify-page-structure) Survey available blocks
+- **content-modeling** - (via authoring-analysis) Validate unclear block selections
+- **block-collection-and-party** - (via authoring-analysis) Validate block existence
+
+## Import Workflow
+
+### Step 0: Create TodoList
+
+Use the TodoWrite tool to create a todo list with the following tasks:
+
+1. **Scrape the webpage** (scrape-webpage skill)
+   - Success: metadata.json, screenshot.png, cleaned.html, images/ folder exist
+
+2. **Identify page structure** (identify-page-structure skill)
+   - Success: Section boundaries identified, content sequences documented, block inventory complete
+
+3. **Analyze authoring approach** (authoring-analysis skill)
+   - Success: Every content sequence has decision (default content OR block name), section styling validated
+
+4. **Generate HTML file** (generate-import-html skill)
+   - Success: HTML file exists, images folder copied, validation checklist passed
+
+5. **Preview and verify** (preview-import skill)
+   - Success: Page renders correctly in browser, matches original structure
+
+---
+
+### Step 1: Scrape Webpage
+
+**Invoke:** scrape-webpage skill
+
+**Provide:**
+- Target URL
+- Output directory: `./import-work`
+
+**Success criteria:**
+- ✅ metadata.json exists with paths, metadata, image mapping
+- ✅ screenshot.png saved for visual reference
+- ✅ cleaned.html with local image paths
+- ✅ images/ folder with all downloaded images
+
+**Mark todo complete when:** All files verified to exist
+
+---
+
+### Step 2: Identify Page Structure
+
+**Invoke:** identify-page-structure skill
+
+**Provide:**
+- screenshot.png from Step 1
+- cleaned.html from Step 1
+- metadata.json from Step 1
+
+**Success criteria:**
+- ✅ Section boundaries identified with styling notes
+- ✅ Content sequences documented for each section (neutral descriptions)
+- ✅ Block inventory completed (local + Block Collection)
+
+**Mark todo complete when:** All outputs documented
+
+---
+
+### Step 3: Analyze Authoring Approach
+
+**Invoke:** authoring-analysis skill
+
+**Provide:**
+- Section list with content sequences from Step 2
+- Block inventory from Step 2
+- screenshot.png from Step 1
+
+**Success criteria:**
+- ✅ Every content sequence has decision: default content OR block name
+- ✅ Block structures fetched for all blocks to be used
+- ✅ Single-block sections validated for styling (Step 3e if applicable)
+
+**Mark todo complete when:** All sequences have authoring decisions
+
+---
+
+### Step 4: Generate HTML File
+
+**Invoke:** generate-import-html skill
+
+**Provide:**
+- Authoring analysis from Step 3
+- Section styling decisions from Step 3
+- metadata.json from Step 1
+- cleaned.html from Step 1
+
+**Success criteria:**
+- ✅ HTML file saved at correct path (from metadata.json)
+- ✅ All sections imported (no truncation)
+- ✅ Images folder copied to correct location
+- ✅ Metadata block included (unless skipped)
+- ✅ Validation checklist passed
+
+**Mark todo complete when:** HTML file written, images copied, validation passed
+
+---
+
+### Step 5: Preview and Verify
+
+**Invoke:** preview-import skill
+
+**Provide:**
+- HTML file path from Step 4
+- screenshot.png from Step 1 (for comparison)
+- documentPath from metadata.json
+
+**Success criteria:**
+- ✅ Page loads in browser
+- ✅ Blocks render correctly
+- ✅ Layout matches original (compare with screenshot)
+- ✅ No console errors
+- ✅ Images load or show placeholders
+
+**Mark todo complete when:** Visual verification passed
+
+---
+
+## High-Level Dos and Don'ts
+
+**DO:**
+- ✅ Follow the workflow steps in order
+- ✅ Mark each todo complete after verification
+- ✅ Use TodoWrite to track progress
+- ✅ Import ALL content (partial import is failure)
+- ✅ Compare final preview with original screenshot
+
+**DON'T:**
+- ❌ Skip steps or combine steps
+- ❌ Make authoring decisions without block inventory
+- ❌ Generate HTML before completing authoring analysis
+- ❌ Truncate or summarize content
+- ❌ Consider import complete without visual verification
+
+## Success Criteria
+
+Import is complete when:
+- ✅ All 5 todos marked complete
+- ✅ HTML file renders in browser
+- ✅ Visual structure matches original page
+- ✅ All content imported (no truncation)
+- ✅ Images accessible
+
+## Limitations
+
+This orchestrator manages single-page import with existing blocks. It does NOT:
+- Custom variant creation (blocks are used as-is)
+- Multi-page batch processing (import one page at a time)
+- Block code development (assumes blocks exist)
+- Advanced reuse detection across imports
+- Automatic block matching algorithms
+
+For those features, consider more comprehensive import workflows in specialized tools.
diff --git a/.claude/.skills/preview-import/SKILL.md b/.claude/.skills/preview-import/SKILL.md
new file mode 100644
index 0000000..cfb8ed1
--- /dev/null
+++ b/.claude/.skills/preview-import/SKILL.md
@@ -0,0 +1,140 @@
+---
+name: preview-import
+description: Preview and verify imported content in local AEM Edge Delivery Services dev server. Validates rendering, compares with original page, and troubleshoots common issues.
+---
+
+# Preview Import
+
+Open and verify imported content in local development server.
+
+## When to Use This Skill
+
+Use this skill when:
+- You have generated HTML file (from generate-import-html)
+- Ready to preview in browser and verify rendering
+- Need to compare with original page structure
+
+**Invoked by:** page-import skill (Step 5)
+
+## Prerequisites
+
+From previous skills, you need:
+- ✅ HTML file at correct path (from generate-import-html)
+- ✅ Images folder in same directory
+- ✅ screenshot.png from scrape-webpage (for comparison)
+- ✅ documentPath from metadata.json (for URL construction)
+
+## Related Skills
+
+- **page-import** - Orchestrator that invokes this skill
+- **generate-import-html** - Provides HTML file to preview
+- **scrape-webpage** - Provides screenshot for comparison
+
+## Preview Workflow
+
+### Step 1: Start Development Server
+
+**Command:**
+```bash
+aem up
+```
+
+This starts the local AEM proxy server at `http://localhost:3000`
+
+---
+
+### Step 2: Navigate in Browser
+
+**For most files, use the document path directly:**
+```
+http://localhost:3000${documentPath}
+```
+
+Example:
+- HTML file: `us/en/about.plain.html`
+- URL: `http://localhost:3000/us/en/about`
+
+**IMPORTANT: For index files, use `/index` instead of `/`:**
+```
+If file is: index.plain.html
+Preview at: http://localhost:3000/index
+NOT: http://localhost:3000/
+```
+
+**Note:** If you used `--html-folder` flag (e.g., `aem up --html-folder drafts`), prepend that folder to the URL:
+```
+File: drafts/test.plain.html
+URL: http://localhost:3000/drafts/test
+```
+
+Use `paths.documentPath` from metadata.json, but for index files ensure the path is `/index` not `/`
+
+---
+
+### Step 3: Verify Rendering
+
+**Check the following:**
+- ✅ Blocks render with correct styling
+- ✅ Layout matches original page structure (compare to screenshot.png)
+- ✅ Images load (or show appropriate placeholders)
+- ✅ No raw HTML visible
+- ✅ Metadata appears in page source (view source, check `<meta>` tags)
+- ✅ Section styling applied correctly
+
+---
+
+### Step 4: Compare with Original
+
+**Side-by-side comparison:**
+1. Open `./import-work/screenshot.png` alongside browser preview
+2. Check that content structure matches
+3. Verify blocks decorated correctly
+4. Confirm section boundaries align
+5. Validate styling consistency
+
+---
+
+## Troubleshooting
+
+**Blocks don't render correctly:**
+- Check HTML structure matches expected format
+- Verify block names match exactly (case-sensitive)
+- Review `../page-import/resources/html-structure.md` for format guidance
+
+**Images not loading:**
+- Verify images folder is in same directory as HTML file
+- Check image paths are `./images/...` format
+- Ensure images were copied correctly from `./import-work/images/`
+
+**Raw HTML visible:**
+- Block name might not match existing block in project
+- Check browser console for JavaScript errors
+- Verify block exists in `blocks/` directory
+
+**Metadata not in page source:**
+- Check metadata block is at end of HTML file
+- View page source and search for `<meta>` tags in `<head>`
+- Verify metadata properties match expected format
+
+**Dev server not running:**
+- Start server with `aem up`
+- Check for port conflicts (default 3000)
+- Verify you're in correct project directory
+
+**Page not found (404):**
+- Verify HTML file exists at expected path
+- Check documentPath from metadata.json matches URL
+- For index files, use `/index` not `/`
+- If using `--html-folder`, include folder in URL
+
+---
+
+## Output
+
+This skill provides:
+- ✅ Verified preview that matches original page structure
+- ✅ Visual confirmation of correct rendering
+- ✅ Validated block decoration
+- ✅ Confirmed metadata presence
+
+**Import complete when all verification points pass.**
diff --git a/.claude/.skills/scrape-webpage/SKILL.md b/.claude/.skills/scrape-webpage/SKILL.md
new file mode 100644
index 0000000..51223a5
--- /dev/null
+++ b/.claude/.skills/scrape-webpage/SKILL.md
@@ -0,0 +1,155 @@
+---
+name: scrape-webpage
+description: Scrape webpage content, extract metadata, download images, and prepare for import/migration to AEM Edge Delivery Services. Returns analysis JSON with paths, metadata, cleaned HTML, and local images.
+---
+
+# Scrape Webpage
+
+Extract content, metadata, and images from a webpage for import/migration.
+
+## When to Use This Skill
+
+Use this skill when:
+- Starting a page import and need to extract content from source URL
+- Need webpage analysis with local image downloads
+- Want metadata extraction (Open Graph, JSON-LD, etc.)
+
+**Invoked by:** page-import skill (Step 1)
+
+## Prerequisites
+
+Before using this skill, ensure:
+- ✅ Node.js is available
+- ✅ npm playwright is installed (`npm install playwright`)
+- ✅ Chromium browser is installed (`npx playwright install chromium`)
+- ✅ Sharp image library is installed (`cd .claude/skills/scrape-webpage/scripts && npm install`)
+
+## Related Skills
+
+- **page-import** - Orchestrator that invokes this skill
+- **identify-page-structure** - Uses this skill's output (screenshot, HTML, metadata)
+- **generate-import-html** - Uses image mapping and paths from this skill
+
+## Scraping Workflow
+
+### Step 1: Run Analysis Script
+
+**Command:**
+```bash
+node .claude/skills/scrape-webpage/scripts/analyze-webpage.js "https://example.com/page" --output ./import-work
+```
+
+**What the script does:**
+1. Sets up network interception to capture all images
+2. Loads page in headless Chromium
+3. Scrolls through entire page to trigger lazy-loaded images
+4. Downloads all images locally (converts WebP/AVIF/SVG to PNG)
+5. Captures full-page screenshot for visual reference
+6. Extracts metadata (title, description, Open Graph, JSON-LD, canonical)
+7. **Fixes images in DOM** (background-image→img, picture elements, srcset→src, relative→absolute, inline SVG→img)
+8. Extracts cleaned HTML (removes scripts/styles)
+9. Replaces image URLs in HTML with local paths (./images/...)
+10. Generates document paths (sanitized, lowercase, no .html extension)
+11. Saves complete analysis with image mapping to metadata.json
+
+**For detailed explanation:** See `resources/web-page-analysis.md`
+
+---
+
+### Step 2: Verify Output
+
+**Output files:**
+- `./import-work/metadata.json` - Complete analysis with paths and image mapping
+- `./import-work/screenshot.png` - Visual reference for layout comparison
+- `./import-work/cleaned.html` - Main content HTML with local image paths
+- `./import-work/images/` - All downloaded images (WebP/AVIF/SVG converted to PNG)
+
+**Verify files exist:**
+```bash
+ls -lh ./import-work/metadata.json ./import-work/screenshot.png ./import-work/cleaned.html
+ls -lh ./import-work/images/ | head -5
+```
+
+---
+
+### Step 3: Review Metadata JSON
+
+**Output JSON structure:**
+```json
+{
+  "url": "https://example.com/page",
+  "timestamp": "2025-01-12T10:30:00.000Z",
+  "paths": {
+    "documentPath": "/us/en/about",
+    "htmlFilePath": "us/en/about.plain.html",
+    "mdFilePath": "us/en/about.md",
+    "dirPath": "us/en",
+    "filename": "about"
+  },
+  "screenshot": "./import-work/screenshot.png",
+  "html": {
+    "filePath": "./import-work/cleaned.html",
+    "size": 45230
+  },
+  "metadata": {
+    "title": "Page Title",
+    "description": "Page description",
+    "og:image": "https://example.com/image.jpg",
+    "canonical": "https://example.com/page"
+  },
+  "images": {
+    "count": 15,
+    "mapping": {
+      "https://example.com/hero.jpg": "./images/a1b2c3d4e5f6.jpg",
+      "https://example.com/logo.webp": "./images/f6e5d4c3b2a1.png"
+    },
+    "stats": {
+      "total": 15,
+      "converted": 3,
+      "skipped": 12,
+      "failed": 0
+    }
+  }
+}
+```
+
+**Key fields:**
+- `paths.documentPath` - Used for browser preview URL
+- `paths.htmlFilePath` - Where to save final HTML file
+- `images.mapping` - Original URLs → local paths
+- `metadata` - Extracted page metadata
+
+---
+
+## Output
+
+This skill provides:
+- ✅ metadata.json with paths, metadata, image mapping
+- ✅ screenshot.png for visual reference
+- ✅ cleaned.html with local image references
+- ✅ images/ folder with all downloaded images
+
+**Next step:** Pass these outputs to identify-page-structure skill
+
+---
+
+## Troubleshooting
+
+**Browser not installed:**
+```bash
+npx playwright install chromium
+```
+
+**Sharp not installed:**
+```bash
+cd .claude/skills/scrape-webpage/scripts && npm install
+```
+
+**Image download failures:**
+- Check images.stats.failed count in metadata.json
+- Some images may require authentication or be blocked by CORS
+- Failed images will be noted but won't stop the scraping process
+
+**Lazy-loaded images not captured:**
+- Script scrolls through page to trigger lazy loading
+- Some advanced lazy-loading may need customization in scripts/analyze-webpage.js
diff --git a/.claude/.skills/scrape-webpage/resources/web-page-analysis.md b/.claude/.skills/scrape-webpage/resources/web-page-analysis.md
new file mode 100644
index 0000000..726f128
--- /dev/null
+++ b/.claude/.skills/scrape-webpage/resources/web-page-analysis.md
@@ -0,0 +1,357 @@
+# Web Page Analysis
+
+Automated webpage analysis and preparation for content migration using npm playwright.
+
+## Purpose
+
+The web page analysis workflow prepares a source webpage for content migration by:
+- Loading the page and triggering lazy-loaded content
+- Capturing visual references (screenshots)
+- Extracting cleaned HTML with preserved attributes
+- Extracting metadata for SEO preservation
+- Enhancing section boundary visibility for analysis
+
+## Prerequisites
+
+- Node.js installed
+- npm playwright package: `npm install playwright`
+- Browser binaries: `npx playwright install chromium`
+
+## Usage
+
+### Command Line
+
+```bash
+node .claude/skills/scrape-webpage/scripts/analyze-webpage.js "https://example.com/page" --output ./analysis
+```
+
+### Parameters
+
+- **URL** (required): The webpage URL to analyze
+- **--output** (optional): Output directory for artifacts. Defaults to `./page-analysis`
+
+### Output
+
+The script produces both structured data (JSON) and file artifacts:
+
+**JSON Output (stdout + saved to metadata.json):**
+```json
+{
+  "url": "https://example.com/page",
+  "timestamp": "2025-01-12T10:30:00.000Z",
+  "paths": {
+    "documentPath": "/us/en/about",
+    "htmlFilePath": "us/en/about.html",
+    "mdFilePath": "us/en/about.md",
+    "dirPath": "us/en",
+    "filename": "about"
+  },
+  "screenshots": {
+    "original": "./analysis/original.png",
+    "enhancedContrast": "./analysis/enhanced-contrast.png"
+  },
+  "html": {
+    "filePath": "./analysis/cleaned.html",
+    "size": 45230
+  },
+  "metadata": {
+    "title": "Page Title",
+    "description": "Page description",
+    "og:image": "https://example.com/image.jpg",
+    "canonical": "https://example.com/page",
+    ...
+  }
+}
+```
+
+**File Artifacts:**
+- `metadata.json` - Complete analysis results including paths (saved automatically)
+- `original.png` - Screenshot of the page as rendered
+- `enhanced-contrast.png` - Screenshot with exaggerated section background colors
+- `cleaned.html` - Extracted main content HTML with preserved src/href attributes
+
+## Analysis Workflow
+
+### 1. Image Capture Setup
+
+**Network interception:**
+- Sets up Playwright response listener BEFORE page navigation
+- Intercepts all image requests during page load
+- Downloads images to local `./images/` directory
+- Generates MD5 hash filenames for deduplication
+- Converts WebP, AVIF, SVG formats to PNG using Sharp
+- Keeps JPEG and PNG in original format
+- Creates mapping: original URL → local path
+
+### 2. Page Loading and Lazy Content
+
+**Navigate to URL:**
+- Opens page in headless browser
+- Waits for network idle
+- Image capture active during load
+
+**Scroll to trigger lazy loading:**
+- Scrolls through entire page incrementally
+- Waits for images to load at each step
+- Ensures all lazy-loaded content populates
+- Waits for all pending image downloads to complete
+
+### 3. Visual Reference Capture
+
+**Original screenshot:**
+- Full-page screenshot for visual reference
+- Used to compare final migrated result
+
+**Enhanced contrast screenshot:**
+- Algorithmically enhances background color differences
+- Makes subtle section boundaries (white vs light grey) visually obvious
+- Helps identify section breaks for content structure analysis
+
+**How contrast enhancement works:**
+1. Collects all background colors from the page
+2. Groups similar colors (within 20 RGB units distance)
+3. Spreads each group apart by 60 units in RGB space
+4. Makes subtle differences dramatically visible
+
+### 4. Image Fixing in DOM
+
+**Before extracting HTML**, fix common image issues to ensure nothing is missed:
+
+**Background images → Real images:**
+- Finds elements with `background-image: url(...)`
+- Creates `<img>` elements and prepends to parent
+- Removes background-image style
+- Ensures background images get captured
+
+**Picture elements:**
+- Ensures every `<picture>` has an `<img>` with `src`
+- Extracts from `<source srcset>` (largest viewport)
+- Fixes missing img elements
+
+**Srcset fallback:**
+- Images with only `srcset` (no `src`) get first srcset URL copied to src
+- Ensures all images have src attribute
+
+**Relative URL conversion:**
+- Converts relative URLs to absolute URLs
+- Handles `./path`, `/path`, `../path` formats
+- Ensures images can be downloaded
+
+**Inline SVG conversion:**
+- Converts `<svg>` elements to `<img>` with data URLs
+- Base64 encodes SVG content
+- Ensures SVGs get captured
+
+### 5. HTML Extraction and Image URL Replacement
+
+Extracts cleaned HTML with:
+- Non-content elements removed (scripts, styles, nav, footer, ads, iframes)
+- Essential attributes preserved: `src`, `href`, `alt`, `title`, `class`, `id`
+- All other attributes stripped
+- **Formatted with proper indentation** (for Claude readability)
+- **Image URLs replaced with local paths** (using mapping from step 1)
+
+**Why not full HTML:**
+- Focuses on main content only
+- Reduces noise from navigation, marketing pixels, etc.
+- Local images ready for migration (no external dependencies)
+
+### 6. Metadata Extraction
+
+Extracts SEO and social metadata:
+- `<title>` tag
+- Meta tags (name and property attributes)
+- Canonical link
+- JSON-LD structured data
+- Open Graph properties
+- Twitter Card properties
+
+### 7. Document Path Generation
+
+Generates document paths from the source URL:
+
+**Algorithm:**
+1. Extracts pathname from URL
+2. Appends 'index' if path ends with '/'
+3. Removes `.html` extension
+4. Converts to lowercase
+5. Sanitizes special characters and diacritics (converts to hyphens)
+6. Returns clean path
+
+**Example transformations:**
+- `https://example.com/us/en/About.html` → `/us/en/about`
+- `https://example.com/Products/` → `/products/index`
+- `https://example.com/café/été` → `/cafe/ete`
+
+**Generates:**
+- `documentPath` - For preview URL (`/us/en/about`)
+- `htmlFilePath` - Where to save HTML file (`us/en/about.html`)
+- `mdFilePath` - Alternative markdown path (`us/en/about.md`)
+- `dirPath` - Parent directory (`us/en`)
+- `filename` - Just the filename (`about`)
+
+### 8. Save Complete Results
+
+All analysis results are automatically saved to `metadata.json` in the output directory, providing a complete record of:
+- Source URL and timestamp
+- Generated paths for file saving
+- Screenshot locations
+- Extracted HTML and metadata
+- **Image mapping** (original URLs → local paths)
+- **Image statistics** (total, converted, failed)
+- Contrast enhancement statistics
+
+## Image Capture Details
+
+### Supported Formats
+
+**Keep original (no conversion):**
+- JPEG (.jpg)
+- PNG (.png)
+
+**Convert to PNG:**
+- WebP → PNG (better compatibility)
+- AVIF → PNG (better compatibility)
+- SVG → PNG (rasterized for content images)
+- GIF → PNG
+- BMP → PNG
+- TIFF → PNG
+- HEIC/HEIF → PNG
+
+### File Naming
+
+Images are saved with MD5 hash of their original URL:
+- Avoids filename conflicts
+- Deduplicates identical URLs
+- Consistent naming across migrations
+
+Example:
+- `https://example.com/images/hero-banner.webp` → `./images/a1b2c3d4e5f6.png`
+- `https://cdn.example.com/logo.jpg` → `./images/f6e5d4c3b2a1.jpg`
+
+### Limits and Safety
+
+- **Max image size:** 10MB per image (larger images skipped)
+- **Max images:** 100 images per page (prevents runaway captures)
+- **Timeout:** 5 seconds waiting for pending downloads
+
+### What Happens to HTML
+
+After image capture, all `src` attributes in the HTML are automatically replaced:
+
+**Before:**
+```html
+<img src="https://example.com/hero.jpg" alt="Hero">
+```
+
+**After:**
+```html
+<img src="./images/a1b2c3d4e5f6.jpg" alt="Hero">
+```
+
+This means the migrated HTML file already references local images - no manual URL replacement needed!
+
+## When to Use
+
+### Automatic (within page-import skill)
+
+The analyze-webpage.js script is invoked automatically as Step 1 of page-import. You don't need to run it manually.
+
+### Standalone Use Cases
+
+Run the script manually when:
+- **Analyzing competitors** - Extract content structure and metadata without full migration
+- **Quick inspection** - Need screenshots and HTML of a page for reference
+- **Debugging** - Test the extraction logic on specific pages
+- **Batch analysis** - Script multiple pages to compare patterns
+
+## Troubleshooting
+
+### Browser not installed
+
+**Error:** `browserType.launch: Executable doesn't exist`
+
+**Solution:**
+```bash
+npx playwright install chromium
+```
+
+### Lazy loading not working
+
+Some pages use advanced lazy loading that doesn't trigger on scroll. The script includes reasonable delays, but complex cases may need manual intervention.
+
+### Enhanced contrast looks wrong
+
+The contrast enhancement algorithm works on most pages but may produce unusual results with:
+- Gradient backgrounds
+- Background images
+- Complex layered designs
+
+Use original.png for visual reference in these cases.
+
+### Page requires interaction
+
+Some pages hide content behind:
+- Cookie consent popups
+- Age verification
+- Login requirements
+
+The script attempts basic popup dismissal, but complex cases may need customization.
+
+## Integration with Page Import
+
+```
+page-import Step 1: Scrape Webpage
+└─ Runs: node analyze-webpage.js [URL] --output ./work
+   ├─ Returns: JSON with all extracted data
+   ├─ Saves: Screenshots for visual analysis
+   ├─ Saves: Cleaned HTML for content mapping
+   └─ Saves: Metadata for SEO preservation
+
+page-import Step 2-5: Use the extracted data
+├─ Enhanced screenshot → Identify section boundaries
+├─ Original screenshot → Visual reference
+├─ Cleaned HTML → Map to blocks
+└─ Metadata → Generate metadata block
+```
+
+## Output Quality Checks
+
+Before proceeding with migration:
+- ✅ Original screenshot shows complete page (all content loaded)
+- ✅ Enhanced screenshot clearly shows section boundaries
+- ✅ Cleaned HTML contains all main content
+- ✅ Image `src` attributes are absolute URLs (or correct relative paths)
+- ✅ Link `href` attributes are preserved
+- ✅ Metadata includes at least title and description
+
+## Script Architecture
+
+The `analyze-webpage.js` script is organized as:
+
+```javascript
+// Main orchestration
+async function analyzeWebpage(url, outputDir) { }
+
+// Helper functions (inline, no external dependencies)
+async function scrollToTriggerLazyLoad(page) { }
+async function enhanceContrast(page) { }
+async function extractCleanedHTML(page) { }
+async function extractMetadata(page) { }
+
+// CLI entry point
+if (import.meta.url === `file://${process.argv[1]}`) {
+  main();
+}
+```
+
+All browser manipulation logic is self-contained - no external script files needed.
+
+## Next Steps
+
+After running web page analysis:
+1. Review screenshots to understand page structure
+2. Examine enhanced-contrast.png to identify section boundaries
+3. Use cleaned HTML to map content to blocks
+4. Use metadata to generate metadata block
+5. Proceed with page-import Steps 2-5
diff --git a/.claude/.skills/scrape-webpage/scripts/analyze-webpage.js b/.claude/.skills/scrape-webpage/scripts/analyze-webpage.js
new file mode 100755
index 0000000..e8f4a16
--- /dev/null
+++ b/.claude/.skills/scrape-webpage/scripts/analyze-webpage.js
@@ -0,0 +1,495 @@
+#!/usr/bin/env node
+
+/*
+ * Copyright 2025 Adobe. All rights reserved.
+ * This file is licensed to you under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License. You may obtain a copy
+ * of the License at http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software distributed under
+ * the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS
+ * OF ANY KIND, either express or implied. See the License for the specific language
+ * governing permissions and limitations under the License.
+ */
+
+/**
+ * Analyze Webpage for Migration
+ *
+ * Uses npm playwright to analyze a webpage and prepare it for content migration.
+ *
+ * Features:
+ * - Scrolls to trigger lazy-loaded content
+ * - Captures images and converts to web-friendly formats
+ * - Takes full-page screenshot
+ * - Extracts cleaned HTML with preserved attributes
+ * - Extracts metadata (SEO, Open Graph, etc.)
+ *
+ * Usage:
+ *   node analyze-webpage.js "https://example.com/page" --output ./analysis
+ *
+ * Requirements:
+ *   npm install playwright
+ *   npx playwright install chromium
+ */
+
+import { chromium } from 'playwright';
+import fs from 'fs';
+import path from 'path';
+import { fileURLToPath } from 'url';
+import { generateDocumentPathInfo } from './generate-path.js';
+import { setupImageCapture, waitForPendingImages, replaceImageUrls } from './image-capture.js';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+/**
+ * Scroll through the entire page to trigger lazy-loaded images
+ */
+async function scrollToTriggerLazyLoad(page) {
+  await page.evaluate(async () => {
+    await new Promise((resolve) => {
+      let totalHeight = 0;
+      const distance = 100;
+      const timer = setInterval(() => {
+        const scrollHeight = document.body.scrollHeight;
+        window.scrollBy(0, distance);
+        totalHeight += distance;
+        if (totalHeight >= scrollHeight) {
+          clearInterval(timer);
+          resolve();
+        }
+      }, 100);
+    });
+  });
+}
+
+
+/**
+ * Fix images in the DOM to ensure none are missed during extraction
+ * Adapted from site-transfer-agent-importscript/resources/transformers/images.js
+ */
+async function fixImagesInDom(page, url) {
+  await page.evaluate((sourceUrl) => {
+    // Helper: Extract URL from background-image CSS property
+    function extractUrlFromBackgroundImage(backgroundImage) {
+      if (!backgroundImage || backgroundImage.toLowerCase() === 'none') {
+        return null;
+      }
+      const urlMatch = backgroundImage.match(/url\(['"]?([^'")\s]+)['"]?\)/);
+      return urlMatch ? urlMatch[1] : null;
+    }
+
+    // Helper: Get background image from inline style or data attribute
+    function getBackgroundImageFromElement(element) {
+      const inlineStyle = element.getAttribute('style');
+      if (inlineStyle) {
+        const styleParts = inlineStyle.split(';');
+        for (const style of styleParts) {
+          const [prop, ...valueParts] = style.split(':');
+          if (prop?.trim() === 'background-image') {
+            return valueParts.join(':').trim();
+          }
+        }
+      }
+      const bgImage = window.getComputedStyle(element)?.getPropertyValue('background-image');
+      if (bgImage && bgImage !== 'none' && bgImage.includes('url(')) {
+        return bgImage;
+      }
+
+      return null;
+    }
+
+    // Helper: Extract picture source URL (largest viewport)
+    function extractPictureSource(pictureElement) {
+      const sources = pictureElement.querySelectorAll('source');
+      if (sources.length === 0) return null;
+
+      let largestSource = null;
+      let largestMaxWidth = -1;
+
+      for (const source of sources) {
+        const mediaQuery = source.getAttribute('media');
+        if (!mediaQuery) {
+          largestSource = source;
+          break;
+        }
+
+        const match = mediaQuery.match(/max-width:\s*(\d+)px/);
+        if (match) {
+          const maxWidth = parseInt(match[1], 10);
+          if (maxWidth > largestMaxWidth) {
+            largestMaxWidth = maxWidth;
+            largestSource = source;
+          }
+        }
+      }
+
+      if (!largestSource) {
+        largestSource = sources[sources.length - 1];
+      }
+
+      if (largestSource) {
+        const srcset = largestSource.getAttribute('srcset');
+        if (srcset) {
+          return srcset.split(',')[0].trim().split(/\s+/)[0];
+        }
+      }
+      return null;
+    }
+
+    // 1. Transform background images to actual img elements
+    // Check common elements that often have background images from CSS
+    const elementsToCheck = document.body.querySelectorAll('div, section, article, header, footer, aside, main, figure');
+    elementsToCheck.forEach((element) => {
+      const backgroundImage = getBackgroundImageFromElement(element);
+      const src = extractUrlFromBackgroundImage(backgroundImage);
+      if (src) {
+        const img = document.createElement('img');
+        img.src = src;
+        element.prepend(img);
+        element.style.backgroundImage = 'none';
+      }
+    });
+
+    // 2. Ensure picture elements have img with src
+    const pictures = document.body.querySelectorAll('picture');
+    pictures.forEach((picture) => {
+      const img = picture.querySelector('img');
+      if (!img || !img.src) {
+        const newImg = document.createElement('img');
+        const src = extractPictureSource(picture);
+        if (src) {
+          newImg.src = src;
+          if (img) {
+            img.replaceWith(newImg);
+          } else {
+            picture.appendChild(newImg);
+          }
+        }
+      }
+    });
+
+    // 3. Fix images with srcset but no src
+    document.body.querySelectorAll('img').forEach((img) => {
+      let src = img.getAttribute('src');
+      const srcset = img.getAttribute('srcset')?.split(' ')[0];
+      if (!src && srcset) {
+        img.setAttribute('src', srcset);
+      }
+      src = img.getAttribute('src');
+
+      // 4. Convert relative URLs to absolute
+      if (src) {
+        try {
+          new URL(src);
+          // Already absolute, leave it
+        } catch (e) {
+          // Relative URL - convert to absolute
+          if (!src.startsWith('/')) {
+            src = `./${src}`;
+          }
+          try {
+            const absoluteUrl = new URL(src, sourceUrl);
+            img.src = absoluteUrl.toString();
+          } catch (err) {
+            console.warn(`Unable to adjust image URL ${src}`);
+          }
+        }
+      }
+    });
+
+    // 5. Transform inline SVG elements to img with data URLs
+    const svgs = document.body.querySelectorAll('svg');
+    svgs.forEach((svg) => {
+      let svgString = '<svg';
+      for (const attr of svg.attributes) {
+        svgString += ` ${attr.name}="${attr.value}"`;
+      }
+      svgString += '>';
+      svgString += svg.innerHTML;
+      svgString += '</svg>';
+
+      const svgDataUrl = `data:image/svg+xml;base64,${btoa(unescape(encodeURIComponent(svgString)))}`;
+      const img = document.createElement('img');
+      img.src = svgDataUrl;
+      svg.replaceWith(img);
+    });
+  }, url);
+}
+
+/**
+ * Format HTML with proper indentation for readability
+ */
+function formatHtml(html) {
+  let formatted = '';
+  let indent = 0;
+  const indentSize = 2;
+
+  // Add newlines after tags
+  html = html.replace(/></g, '>\n<');
+
+  const lines = html.split('\n');
+
+  lines.forEach(line => {
+    const trimmed = line.trim();
+    if (!trimmed) return;
+
+    // Decrease indent for closing tags
+    if (trimmed.startsWith('</')) {
+      indent = Math.max(0, indent - 1);
+    }
+
+    // Add indentation
+    formatted += ' '.repeat(indent * indentSize) + trimmed + '\n';
+
+    // Increase indent for opening tags (but not self-closing or immediately closed)
+    if (trimmed.startsWith('<') && !trimmed.startsWith('</') && !trimmed.endsWith('/>') && !trimmed.match(/<[^>]+>.*<\/[^>]+>$/)) {
+      indent++;
+    }
+  });
+
+  return formatted.trim();
+}
+
+/**
+ * Extract cleaned HTML with preserved attributes
+ */
+async function extractCleanedHTML(page) {
+  const html = await page.evaluate(() => {
+    // 1. Remove non-content elements
+    const selectorsToRemove = [
+      'script', 'style', 'noscript'
+    ];
+
+    selectorsToRemove.forEach(selector => {
+      document.querySelectorAll(selector).forEach(el => el.remove());
+    });
+
+    // 2. CRITICAL: Preserve essential attributes, strip all others
+    const keepAttributes = ['src', 'href', 'alt', 'title', 'class', 'id'];
+    document.body.querySelectorAll('*').forEach(el => {
+      const attrs = Array.from(el.attributes);
+      attrs.forEach(attr => {
+        if (!keepAttributes.includes(attr.name)) {
+          el.removeAttribute(attr.name);
+        }
+      });
+    });
+
+    // 3. Return full body HTML (will be formatted on Node.js side)
+    return document.body.outerHTML;
+  });
+
+  // Format HTML for readability
+  return formatHtml(html);
+}
+
+/**
+ * Extract metadata from page
+ */
+async function extractMetadata(page) {
+  const metadata = await page.evaluate(() => {
+    const meta = {};
+
+    // Extract title
+    const titleTag = document.querySelector('title');
+    if (titleTag) meta.title = titleTag.textContent.trim();
+
+    // Extract all meta tags
+    document.querySelectorAll('meta').forEach(tag => {
+      const name = tag.getAttribute('name') || tag.getAttribute('property');
+      const content = tag.getAttribute('content');
+      if (name && content) meta[name] = content;
+    });
+
+    // Extract canonical link
+    const canonical = document.querySelector('link[rel="canonical"]');
+    if (canonical) meta.canonical = canonical.getAttribute('href');
+
+    // Extract JSON-LD
+    const jsonLd = document.querySelector('script[type="application/ld+json"]');
+    if (jsonLd) {
+      try {
+        meta.jsonLd = JSON.parse(jsonLd.textContent);
+      } catch (e) {
+        meta.jsonLd = jsonLd.textContent;
+      }
+    }
+
+    return meta;
+  });
+
+  return metadata;
+}
+
+/**
+ * Main analysis function
+ */
+async function analyzeWebpage(url, outputDir) {
+  // Ensure output directory exists
+  if (!fs.existsSync(outputDir)) {
+    fs.mkdirSync(outputDir, { recursive: true });
+  }
+
+  console.error(`Analyzing: ${url}`);
+  console.error(`Output directory: ${outputDir}`);
+
+  // Launch browser
+  const browser = await chromium.launch();
+  const page = await browser.newPage();
+
+  try {
+    // Set up image capture BEFORE navigation
+    console.error('Setting up image capture...');
+    const captureState = setupImageCapture(page, outputDir);
+
+    // Navigate to page
+    console.error('Navigating to page...');
+    try {
+      // Try networkidle first (most reliable when it works)
+      await page.goto(url);
+    } catch (error) {
+      // Fall back to domcontentloaded if networkidle times out
+      console.error('⚠️  networkidle timeout, falling back to domcontentloaded...');
+      await page.goto(url, { waitUntil: 'domcontentloaded', timeout: 30000 });
+      await page.waitForTimeout(3000); // Give page extra time to settle
+    }
+
+    // Scroll to trigger lazy loading
+    console.error('Scrolling to trigger lazy-loaded content...');
+    await scrollToTriggerLazyLoad(page);
+    await page.waitForTimeout(1000); // Give lazy-loaded images time to populate
+
+    // Wait for all pending images to complete
+    console.error(`Waiting for ${captureState.pendingImages.size} pending images...`);
+    await waitForPendingImages(captureState, 5000);
+    console.error(`✅ Image capture complete: ${captureState.stats.total} total, ${captureState.stats.converted} converted, ${captureState.stats.failed} failed`);
+
+    // Take screenshot
+    console.error('Capturing screenshot...');
+    const screenshot = path.join(outputDir, 'screenshot.png');
+    await page.screenshot({ path: screenshot, fullPage: true });
+
+    // Extract metadata
+    console.error('Extracting metadata...');
+    const metadata = await extractMetadata(page);
+
+    // Disable image capture (images already captured)
+    captureState.disable();
+
+    // Fix images in DOM (background images, picture elements, relative URLs, inline SVGs)
+    console.error('Fixing images in DOM...');
+    await fixImagesInDom(page, url);
+
+    // Extract cleaned HTML
+    console.error('Extracting cleaned HTML...');
+    let html = await extractCleanedHTML(page);
+
+    // Replace image URLs with local paths
+    console.error('Replacing image URLs with local paths...');
+    html = replaceImageUrls(html, captureState.imageMap);
+
+    const htmlPath = path.join(outputDir, 'cleaned.html');
+    fs.writeFileSync(htmlPath, html, 'utf-8');
+
+    // Generate document paths
+    console.error('Generating document paths...');
+    const paths = generateDocumentPathInfo(url);
+
+    // Build result object
+    const result = {
+      url,
+      timestamp: new Date().toISOString(),
+      paths: {
+        documentPath: paths.documentPath,
+        htmlFilePath: paths.htmlFilePath,
+        mdFilePath: paths.mdFilePath,
+        dirPath: paths.dirPath,
+        filename: paths.filename
+      },
+      screenshot,
+      html: {
+        filePath: htmlPath,
+        size: html.length
+      },
+      metadata,
+      images: {
+        count: captureState.imageMap.size,
+        mapping: Object.fromEntries(captureState.imageMap),
+        stats: captureState.stats
+      }
+    };
+
+    // Save metadata.json file
+    const metadataPath = path.join(outputDir, 'metadata.json');
+    fs.writeFileSync(metadataPath, JSON.stringify(result, null, 2), 'utf-8');
+    console.error(`Saved metadata to: ${metadataPath}`);
+
+    console.error('Analysis complete!');
+
+    return result;
+  } finally {
+    await browser.close();
+  }
+}
+
+/**
+ * CLI entry point
+ */
+async function main() {
+  const args = process.argv.slice(2);
+
+  if (args.length === 0 || args[0] === '--help' || args[0] === '-h') {
+    console.error(`
+Usage: node analyze-webpage.js <url> [--output <dir>]
+
+Analyze a webpage and prepare it for content migration.
+
+Arguments:
+  <url>              URL of the webpage to analyze (required)
+  --output <dir>     Output directory for artifacts (default: ./page-analysis)
+
+Examples:
+  node analyze-webpage.js "https://example.com/page"
+  node analyze-webpage.js "https://example.com/page" --output ./my-analysis
+
+Output:
+  - screenshot.png            Screenshot of the page
+  - cleaned.html              Extracted HTML with preserved attributes
+  - metadata.json             Complete analysis results
+  - images/                   Downloaded images
+
+Requirements:
+  npm install playwright
+  npx playwright install chromium
+`);
+    process.exit(args.length === 0 ? 1 : 0);
+  }
+
+  const url = args[0];
+  let outputDir = './page-analysis';
+
+  // Parse --output flag
+  const outputIndex = args.indexOf('--output');
+  if (outputIndex !== -1 && args[outputIndex + 1]) {
+    outputDir = args[outputIndex + 1];
+  }
+
+  try {
+    const result = await analyzeWebpage(url, outputDir);
+
+    // Output JSON to stdout (stderr used for progress messages above)
+    console.log(JSON.stringify(result, null, 2));
+  } catch (error) {
+    console.error(`Error analyzing webpage: ${error.message}`);
+    console.error(error.stack);
+    process.exit(1);
+  }
+}
+
+// Run if executed directly
+if (import.meta.url === `file://${process.argv[1]}`) {
+  main();
+}
+
+export { analyzeWebpage, scrollToTriggerLazyLoad, extractCleanedHTML, extractMetadata };
diff --git a/.claude/.skills/scrape-webpage/scripts/generate-path.js b/.claude/.skills/scrape-webpage/scripts/generate-path.js
new file mode 100644
index 0000000..3d0da06
--- /dev/null
+++ b/.claude/.skills/scrape-webpage/scripts/generate-path.js
@@ -0,0 +1,201 @@
+#!/usr/bin/env node
+
+/*
+ * Copyright 2025 Adobe. All rights reserved.
+ * This file is licensed to you under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License. You may obtain a copy
+ * of the License at http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software distributed under
+ * the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS
+ * OF ANY KIND, either express or implied. See the License for the specific language
+ * governing permissions and limitations under the License.
+ */
+
+/**
+ * Path generation script for page migration
+ * Generates document paths from source URLs
+ *
+ * This uses the exact same algorithm as the EXCAT MCP tool's generate_document_path
+ * to ensure consistent path generation across all migration workflows.
+ *
+ * Usage:
+ *   node generate-path.js "https://example.com/us/en/about.html"
+ *
+ * Output (JSON):
+ *   {
+ *     "success": true,
+ *     "url": "https://example.com/us/en/about.html",
+ *     "documentPath": "/us/en/about",
+ *     "mdFilePath": "us/en/about.md",
+ *     "htmlFilePath": "us/en/about.plain.html",
+ *     "dirPath": "us/en",
+ *     "filename": "about",
+ *     "directoryCreated": true,
+ *     "timestamp": "2025-11-02T10:30:45.123Z"
+ *   }
+ */
+
+import fs from 'fs';
+import path from 'path';
+import { fileURLToPath } from 'url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+/**
+ * Sanitize a filename according to standard naming conventions
+ * @param {string} name - The filename to sanitize
+ * @returns {string} - Sanitized filename
+ */
+function sanitizeFilename(name) {
+  if (!name) return '';
+  return decodeURIComponent(name)
+    .toLowerCase()
+    .normalize('NFD')
+    .replace(/[\u0300-\u036f]/g, '')
+    .replace(/[^a-z0-9]+/g, '-')
+    .replace(/^-|-$/g, '');
+}
+
+/**
+ * Sanitize a path according to standard naming conventions
+ * @param {string} pathStr - The path to sanitize
+ * @returns {string} - Sanitized path
+ */
+function sanitizePath(pathStr) {
+  if (!pathStr) return '';
+  const extension = pathStr.split('.').pop();
+  const pathname = extension !== pathStr ? pathStr.substring(0, pathStr.lastIndexOf('.')) : pathStr;
+  let sanitizedPath = '';
+  pathname.split('/').forEach((p) => {
+    if (p !== '') {
+      sanitizedPath += `/${sanitizeFilename(p)}`;
+    }
+  });
+  if (extension !== pathStr) {
+    sanitizedPath += `.${extension}`;
+  }
+  return sanitizedPath;
+}
+
+/**
+ * Generate document path from URL according to standard conventions
+ * @param {string} url - Source URL
+ * @returns {string} - Document path (without extension)
+ */
+function generateDocumentPath({ url }) {
+  let p = new URL(url).pathname;
+  if (p.endsWith('/')) {
+    p = `${p}index`;
+  }
+  p = decodeURIComponent(p)
+    .toLowerCase()
+    .replace(/\.html$/, '')
+    .replace(/[^a-z0-9/]/gm, '-');
+  return sanitizePath(p);
+}
+
+/**
+ * Generate document path with full file information
+ * @param {string} url - Source URL to process
+ * @returns {Object} - Complete path information
+ */
+function generateDocumentPathInfo(url) {
+  try {
+    // Generate the document path (no extension)
+    const documentPath = generateDocumentPath({ url });
+
+    // Build file paths
+    const mdFilePath = `${documentPath}.md`;
+    const htmlFilePath = `${documentPath}.plain.html`;
+
+    // Extract directory path (parent directory)
+    const dirPath = `${documentPath.substring(0, documentPath.lastIndexOf('/'))}`;
+
+    // Extract just the filename (without extension)
+    const filename = documentPath.substring(documentPath.lastIndexOf('/') + 1);
+
+    // Automatically create directory structure if needed
+    let directoryCreated = false;
+    if (dirPath && dirPath !== 'content') {
+      // Resolve to absolute path relative to workspace
+      const workspaceRoot = process.env.WORKSPACE_ROOT || process.cwd();
+      const absoluteDirPath = path.join(workspaceRoot, dirPath);
+
+      try {
+        fs.mkdirSync(absoluteDirPath, { recursive: true });
+        directoryCreated = true;
+      } catch (error) {
+        // Don't fail - directory might already exist
+        directoryCreated = false;
+      }
+    }
+
+    return {
+      success: true,
+      url,
+      documentPath,
+      mdFilePath,
+      htmlFilePath,
+      dirPath,
+      filename,
+      directoryCreated,
+      timestamp: new Date().toISOString(),
+    };
+  } catch (error) {
+    throw new Error(`Failed to generate document path: ${error.message}`);
+  }
+}
+
+// CLI wrapper
+async function main() {
+  try {
+    // Get URL from command line arguments
+    const urlArg = process.argv[2];
+
+    if (!urlArg) {
+      console.error(JSON.stringify({
+        success: false,
+        error: 'Missing URL argument. Usage: node generate-path.js "https://example.com/page"',
+        timestamp: new Date().toISOString(),
+      }, null, 2));
+      process.exit(1);
+    }
+
+    // Validate URL
+    try {
+      new URL(urlArg);
+    } catch (e) {
+      console.error(JSON.stringify({
+        success: false,
+        error: `Invalid URL: ${urlArg}`,
+        timestamp: new Date().toISOString(),
+      }, null, 2));
+      process.exit(1);
+    }
+
+    // Generate path info
+    const result = generateDocumentPathInfo(urlArg);
+
+    // Output as JSON
+    console.log(JSON.stringify(result, null, 2));
+
+  } catch (error) {
+    console.error(JSON.stringify({
+      success: false,
+      error: error.message,
+      url: process.argv[2],
+      timestamp: new Date().toISOString(),
+    }, null, 2));
+    process.exit(1);
+  }
+}
+
+// Run if called directly
+if (import.meta.url === `file://${process.argv[1]}`) {
+  main();
+}
+
+// Export functions for use by other scripts
+export { sanitizeFilename, sanitizePath, generateDocumentPath, generateDocumentPathInfo };
diff --git a/.claude/.skills/scrape-webpage/scripts/image-capture.js b/.claude/.skills/scrape-webpage/scripts/image-capture.js
new file mode 100644
index 0000000..5926bd9
--- /dev/null
+++ b/.claude/.skills/scrape-webpage/scripts/image-capture.js
@@ -0,0 +1,286 @@
+#!/usr/bin/env node
+
+/*
+ * Copyright 2025 Adobe. All rights reserved.
+ * This file is licensed to you under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License. You may obtain a copy
+ * of the License at http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software distributed under
+ * the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR REPRESENTATIONS
+ * OF ANY KIND, either express or implied. See the License for the specific language
+ * governing permissions and limitations under the License.
+ */
+
+/**
+ * Image Capture Utilities for Page Migration
+ *
+ * Adapted from excat-ops MCP network-image-capture.js
+ * Intercepts images during page load and saves them locally
+ */
+
+import { mkdir, writeFile } from 'fs/promises';
+import { join } from 'path';
+import { createHash } from 'crypto';
+import sharp from 'sharp';
+
+// Image format mapping (Content-Type → format string)
+const IMAGE_FORMAT_MAP = {
+  'image/webp': 'webp',
+  'image/avif': 'avif',
+  'image/svg+xml': 'svg',
+  'image/jpeg': 'jpeg',
+  'image/jpg': 'jpeg',
+  'image/png': 'png',
+  'image/gif': 'gif',
+  'image/bmp': 'bmp',
+  'image/tiff': 'tiff',
+  'image/heic': 'heic',
+  'image/heif': 'heif',
+};
+
+// Supported formats (no conversion needed)
+const SUPPORTED_FORMATS = ['jpeg', 'png'];
+
+/**
+ * Convert image buffer to PNG using Sharp
+ */
+async function convertToPng(buffer, originalFormat) {
+  try {
+    return await sharp(buffer)
+      .png({
+        compressionLevel: 9,
+        palette: true,
+      })
+      .toBuffer();
+  } catch (error) {
+    throw new Error(`Failed to convert ${originalFormat} to PNG: ${error.message}`);
+  }
+}
+
+/**
+ * Check if format needs conversion
+ */
+function needsConversion(format) {
+  return format !== 'unknown' && !SUPPORTED_FORMATS.includes(format);
+}
+
+/**
+ * Set up network event listeners to capture images during page load
+ * Must be called BEFORE page.goto()
+ *
+ * Uses proper request lifecycle:
+ * 1. 'request' event - Track image requests as they are issued
+ * 2. 'requestfinished' event - Process once body is fully downloaded
+ *
+ * @param {import('playwright').Page} page - Playwright page object
+ * @param {string} outputDir - Directory to save images
+ * @param {Object} options - Optional configuration
+ * @param {number} options.maxImageSize - Max image size in bytes (default: 10MB)
+ * @param {number} options.maxImages - Max number of images to capture (default: 100)
+ * @returns {Promise<Object>} Capture state object
+ */
+export function setupImageCapture(page, outputDir, options = {}) {
+  const {
+    maxImageSize = 10 * 1024 * 1024, // 10MB
+    maxImages = 1000,
+  } = options;
+
+  const imageMap = new Map();
+  const pendingImages = new Set();
+  const trackedRequests = new Set(); // Track image requests
+  const stats = {
+    total: 0,
+    converted: 0,
+    skipped: 0,
+    failed: 0,
+    tooLarge: 0,
+    limitReached: 0
+  };
+
+  // Handler for request event - track image requests as they start
+  const requestHandler = (request) => {
+    // Check if this is an image request
+    if (request.resourceType() !== 'image') {
+      return;
+    }
+
+    const url = request.url();
+
+    // Check if already tracked (avoid duplicates)
+    if (trackedRequests.has(url)) {
+      return;
+    }
+
+    // Check if max images limit reached
+    if (stats.total >= maxImages) {
+      if (stats.limitReached === 0) {
+        console.error(`⚠️  Max images limit (${maxImages}) reached, skipping remaining images`);
+      }
+      stats.limitReached++;
+      return;
+    }
+
+    // Track this request
+    trackedRequests.add(url);
+    pendingImages.add(url);
+    stats.total++;
+  };
+
+  // Handler for requestfinished event - process images once fully downloaded
+  const requestFinishedHandler = async (request) => {
+    // Only process tracked image requests
+    if (request.resourceType() !== 'image') {
+      return;
+    }
+
+    const url = request.url();
+
+    // Only process if we tracked this request
+    if (!trackedRequests.has(url)) {
+      return;
+    }
+
+    // Check if already captured (should not happen, but safeguard)
+    if (imageMap.has(url)) {
+      pendingImages.delete(url);
+      return;
+    }
+
+    try {
+      // Get the response object
+      const response = await request.response();
+
+      if (!response) {
+        console.error(`⚠️  No response for image request: ${url.slice(0, 60)}...`);
+        stats.failed++;
+        pendingImages.delete(url);
+        return;
+      }
+
+      // Get binary data from response body (now fully downloaded)
+      const buffer = await response.body();
+
+      // Check image size
+      if (buffer.length > maxImageSize) {
+        console.error(`⚠️  Image too large (${Math.round(buffer.length / 1024 / 1024)}MB): ${url.slice(0, 60)}...`);
+        stats.tooLarge++;
+        stats.failed++;
+        pendingImages.delete(url);
+        return;
+      }
+
+      // Get content type and determine format
+      const contentType = response.headers()['content-type'] || '';
+      const format = IMAGE_FORMAT_MAP[contentType.split(';')[0]];
+
+      if (!format) {
+        console.error(`⚠️  Unknown image format (${contentType}): ${url.slice(0, 60)}...`);
+        stats.failed++;
+        pendingImages.delete(url);
+        return;
+      }
+
+      // Generate filename using MD5 hash
+      const hash = createHash('md5').update(url).digest('hex');
+      const imagesDir = join(outputDir, 'images');
+      await mkdir(imagesDir, { recursive: true });
+
+      // Convert if needed, save as PNG
+      if (needsConversion(format)) {
+        const pngBuffer = await convertToPng(buffer, format);
+        const filename = `${hash}.png`;
+        const filePath = join(imagesDir, filename);
+        await writeFile(filePath, pngBuffer);
+
+        imageMap.set(url, `./images/${filename}`);
+        stats.converted++;
+        console.error(`✓ Captured & converted (${format}→PNG): ${url.slice(0, 50)}... → ./images/${filename}`);
+      } else {
+        // Save original format (JPEG, PNG)
+        const ext = format === 'jpeg' ? 'jpg' : format;
+        const filename = `${hash}.${ext}`;
+        const filePath = join(imagesDir, filename);
+        await writeFile(filePath, buffer);
+
+        imageMap.set(url, `./images/${filename}`);
+        stats.skipped++;
+        console.error(`✓ Captured (${format}): ${url.slice(0, 50)}... → ./images/${filename}`);
+      }
+
+    } catch (error) {
+      console.error(`✗ Failed to capture ${url.slice(0, 50)}...: ${error.message}`);
+      stats.failed++;
+    } finally {
+      pendingImages.delete(url);
+    }
+  };
+
+  // Set up both event listeners
+  page.on('request', requestHandler);
+  page.on('requestfinished', requestFinishedHandler);
+
+  return {
+    imageMap,
+    pendingImages,
+    stats,
+    disable: () => {
+      page.off('request', requestHandler);
+      page.off('requestfinished', requestFinishedHandler);
+      console.error('🛑 Image capture disabled');
+    },
+  };
+}
+
+/**
+ * Wait for all pending images to complete processing
+ *
+ * @param {Object} captureState - State object returned from setupImageCapture
+ * @param {number} timeout - Max time to wait in milliseconds (default: 5000)
+ * @returns {Promise<void>}
+ */
+export async function waitForPendingImages(captureState, timeout = 5000) {
+  const startTime = Date.now();
+  const { pendingImages } = captureState;
+
+  while (pendingImages.size > 0) {
+    if (Date.now() - startTime > timeout) {
+      console.error(`⚠️  Timeout waiting for ${pendingImages.size} pending images after ${timeout}ms`);
+      break;
+    }
+    await new Promise(resolve => setTimeout(resolve, 100));
+  }
+}
+
+/**
+ * Replace image URLs in HTML with local paths
+ *
+ * @param {string} html - HTML content
+ * @param {Map} imageMap - Map of original URL to local path
+ * @returns {string} - HTML with replaced image URLs
+ */
+export function replaceImageUrls(html, imageMap) {
+  let modifiedHtml = html;
+  let replacements = 0;
+
+  for (const [originalUrl, localPath] of imageMap.entries()) {
+    // Replace in src attributes
+    const srcRegex = new RegExp(`src="${originalUrl.replace(/[.*+?^${}()|[\]\\]/g, '\\$&')}"`, 'g');
+    const srcMatch = modifiedHtml.match(srcRegex);
+    if (srcMatch) {
+      modifiedHtml = modifiedHtml.replace(srcRegex, `src="${localPath}"`);
+      replacements += srcMatch.length;
+    }
+
+    // Also try without quotes (less common but possible)
+    const srcRegex2 = new RegExp(`src=${originalUrl.replace(/[.*+?^${}()|[\]\\]/g, '\\$&')}`, 'g');
+    const srcMatch2 = modifiedHtml.match(srcRegex2);
+    if (srcMatch2) {
+      modifiedHtml = modifiedHtml.replace(srcRegex2, `src="${localPath}"`);
+      replacements += srcMatch2.length;
+    }
+  }
+
+  console.error(`🔄 Replaced ${replacements} image URL references in HTML`);
+  return modifiedHtml;
+}
diff --git a/.claude/.skills/scrape-webpage/scripts/package.json b/.claude/.skills/scrape-webpage/scripts/package.json
new file mode 100644
index 0000000..c23c703
--- /dev/null
+++ b/.claude/.skills/scrape-webpage/scripts/package.json
@@ -0,0 +1,6 @@
+{
+  "type": "module",
+  "dependencies": {
+    "sharp": "^0.34.0"
+  }
+}
diff --git a/.claude/.skills/testing-blocks/SKILL.md b/.claude/.skills/testing-blocks/SKILL.md
new file mode 100644
index 0000000..cd3ac33
--- /dev/null
+++ b/.claude/.skills/testing-blocks/SKILL.md
@@ -0,0 +1,295 @@
+---
+name: Testing Blocks
+description: Guide for testing code changes in AEM Edge Delivery projects including blocks, scripts, and styles. Use this skill after making code changes and before opening a pull request to validate functionality. Covers unit testing for utilities and logic, browser testing with Playwright/Puppeteer, linting, performance validation, and guidance on which tests to maintain vs use as throwaway validation.
+---
+
+# Testing Blocks
+
+This skill guides you through testing code changes in AEM Edge Delivery Services projects. Testing follows a value-versus-cost philosophy: create and maintain tests when the value they bring exceeds the cost of creation and maintenance.
+
+## Related Skills
+
+- **content-driven-development**: Test content created during CDD serves as the basis for testing
+- **building-blocks**: This skill is automatically invoked after block implementation
+- **block-collection-and-party**: May provide reference test patterns from similar blocks
+
+## When to Use This Skill
+
+Use this skill:
+- ✅ After implementing or modifying blocks
+- ✅ After changes to core scripts (scripts.js, delayed.js, aem.js)
+- ✅ After style changes (styles.css, lazy-styles.css)
+- ✅ After configuration changes that affect functionality
+- ✅ Before opening any pull request with code changes
+
+This skill should be automatically invoked by the **building-blocks** skill after implementation is complete.
+
+## Testing Philosophy: Value vs Cost
+
+**The Principle:** Create and maintain tests when the value they bring exceeds the cost of creation and maintenance.
+
+### Keeper Tests (High Value, Worth Maintaining)
+
+✅ **Write unit tests for:**
+- Logic-heavy utility functions used across multiple blocks
+- Data processing and transformation logic
+- API integrations and external service interactions
+- Complex algorithms or business logic
+- Shared libraries and helper functions
+
+These tests provide lasting value because they catch regressions in reused code, serve as living documentation, and are fast and easy to maintain.
+
+### Throwaway Tests (Lower Value, Use Once)
+
+⚠️ **Use browser tests for:**
+- Block decoration logic (DOM transformations)
+- Specific DOM structures or UI layouts
+- Visual appearance validation
+- Block-specific rendering behavior
+
+These tests are better done in a browser because DOM structures change frequently, visual validation requires human judgment, and maintaining UI tests is expensive relative to their value.
+
+**Important:** Even throwaway tests have value! Use them to:
+1. Validate your implementation works correctly
+2. Take screenshots to evaluate visual correctness
+3. Show screenshots to humans for feedback
+4. Include screenshots in PRs to aid review
+
+**Organization:** Keep throwaway tests in `test/tmp/` and test content in `drafts/tmp/`. Both directories should be gitignored so temporary test artifacts aren't committed.
+
+## Testing Checklist
+
+Before opening a pull request, complete ALL of the following:
+
+- [ ] **Existing tests pass** - All keeper tests still pass with your changes
+- [ ] **Unit tests written** - New keeper tests for any logic-heavy utilities or data processing
+- [ ] **Browser validation** - Feature tested in local dev server, screenshots captured
+- [ ] **All variants tested** - Each variant/configuration of blocks validated
+- [ ] **Responsive behavior** - Tested on mobile, tablet, desktop viewports
+- [ ] **Linting passes** - `npm run lint` completes without errors
+- [ ] **Branch pushed** - Code committed and pushed to feature branch
+- [ ] **GitHub checks verified** - Use `gh checks` to confirm all CI checks pass
+
+## Testing Methods Overview
+
+### 1. Unit Tests (KEEPER TESTS)
+
+**When to use:** Logic-heavy functions, utilities, data processing, API integrations
+
+**Quick start:**
+```bash
+# Verify test setup (see resources/vitest-setup.md if not configured)
+npm test
+
+# Write test for utility function
+# test/utils/my-utility.test.js
+import { describe, it, expect } from 'vitest';
+import { myUtility } from '../../scripts/utils/my-utility.js';
+
+describe('myUtility', () => {
+  it('should transform input correctly', () => {
+    expect(myUtility('input')).toBe('OUTPUT');
+  });
+});
+
+# Run tests during development
+npm run test:watch
+```
+
+**Detailed guide:** See `resources/unit-testing.md`
+
+### 2. Browser Testing (THROWAWAY TESTS)
+
+**When to use:** Block decoration, visual validation, DOM structure, responsive design
+
+**Organization:**
+- Test scripts: `test/tmp/test-{block}-browser.js`
+- Test content: `drafts/tmp/{block}.html`
+- Screenshots: `test/tmp/screenshots/`
+- Both `test/tmp/` and `drafts/tmp/` should be gitignored
+
+**Quick start:**
+```bash
+# Install Playwright
+npm install --save-dev playwright
+npx playwright install chromium
+
+# Create test content
+# drafts/tmp/my-block.html (copy head.html content, add test markup)
+
+# Start dev server with drafts folder
+aem up --html-folder drafts
+
+# Create throwaway test script in test/tmp/
+# test/tmp/test-my-block.js
+import { chromium } from 'playwright';
+import { mkdir } from 'fs/promises';
+
+async function test() {
+  await mkdir('./test/tmp/screenshots', { recursive: true });
+  const browser = await chromium.launch({ headless: false });
+  const page = await browser.newPage();
+
+  await page.goto('http://localhost:3000/drafts/tmp/my-block');
+  await page.waitForSelector('.my-block');
+  await page.screenshot({ 
+    path: './test/tmp/screenshots/my-block.png',
+    fullPage: true 
+  });
+
+  await browser.close();
+}
+
+test().catch(console.error);
+
+# Run the test
+node test/tmp/test-my-block.js
+
+# Clean up when done (optional - gitignored either way)
+rm -rf test/tmp/*
+```
+
+**Detailed guide:** See `resources/browser-testing.md`
+
+### 3. Linting (ALWAYS)
+
+**When to use:** Before every commit
+
+**Quick start:**
+```bash
+# Run linting
+npm run lint
+
+# Auto-fix issues
+npm run lint:fix
+```
+
+**Linting MUST pass before opening a PR.** Non-negotiable.
+
+### 4. Performance Testing (AUTOMATED)
+
+**When to use:** After pushing branch, automatically via GitHub checks
+
+**Quick start:**
+```bash
+# Push branch
+git push -u origin your-branch
+
+# Create PR with test link
+# PR description MUST include:
+# Preview: https://branch--repo--owner.aem.page/path/to/test
+
+# Monitor checks
+gh pr checks --watch
+```
+
+Performance tests run automatically when you include a test link in your PR description.
+
+## Complete Workflow
+
+For detailed step-by-step workflow, see `resources/testing-workflow.md`.
+
+**Quick summary:**
+
+### During Development
+1. Write unit tests for new utilities
+2. Run `npm run test:watch`
+3. Manually test in browser
+
+### Before Committing
+4. Run `npm test` - all tests pass
+5. Run `npm run lint` - linting passes
+6. Write throwaway browser test in `test/tmp/`
+7. Create test content in `drafts/tmp/`
+8. Review screenshots from `test/tmp/screenshots/`
+9. Manual validation in browser
+
+### Before Opening PR
+10. Commit and push to feature branch (test/tmp/ won't be included)
+11. Verify branch preview loads
+12. Run `gh checks`
+13. Create PR with test link
+14. Monitor `gh pr checks`
+
+### After PR Review
+15. Address feedback
+16. Re-test
+17. Verify checks pass
+
+## Troubleshooting
+
+For detailed troubleshooting guide, see `resources/troubleshooting.md`.
+
+**Common issues:**
+
+### Tests fail
+- Read error message carefully
+- Run single test: `npm test -- path/to/test.js`
+- Fix code or update test
+
+### Linting fails
+- Run `npm run lint:fix`
+- Manually fix remaining issues
+
+### GitHub checks fail
+- Ensure PR has test link
+- Check `gh pr checks` for details
+- Fix performance issues if PSI fails
+
+### Browser tests fail
+- Verify dev server running: `aem up --html-folder drafts`
+- Check test content exists in `drafts/tmp/`
+- Verify URL uses `/tmp/` path: `http://localhost:3000/drafts/tmp/my-block`
+- Add waits: `await page.waitForSelector('.block')`
+
+## Resources
+
+- **Unit Testing:** `resources/unit-testing.md` - Complete guide to writing and maintaining unit tests
+- **Browser Testing:** `resources/browser-testing.md` - Playwright/Puppeteer workflows and best practices
+- **Testing Workflow:** `resources/testing-workflow.md` - Step-by-step workflow from dev to PR
+- **Troubleshooting:** `resources/troubleshooting.md` - Solutions to common testing issues
+- **Vitest Setup:** `resources/vitest-setup.md` - One-time configuration guide
+
+## Integration with Building Blocks Skill
+
+The **building-blocks** skill automatically invokes this skill after implementation.
+
+**Expected flow:**
+1. Building blocks completes implementation
+2. Invokes **testing-blocks** skill
+3. This skill guides testing process
+4. Returns control when testing complete
+
+**Building blocks provides:**
+- Block name being tested
+- Test content URL from CDD process
+- Any variants that need testing
+
+**This skill returns:**
+- Confirmation all tests pass
+- Screenshots from browser testing (if requested)
+- Any issues discovered during testing
+
+## Summary
+
+Testing in AEM Edge Delivery follows a pragmatic value-versus-cost approach:
+
+**Create keeper tests for:**
+- Logic-heavy utilities
+- Data processing and transformations
+- API integrations
+- Shared libraries
+
+**Use throwaway browser tests for:**
+- Block decoration validation
+- Visual appearance
+- DOM structure
+- Interactive behavior
+
+**Always do:**
+- Run linting before commits
+- Test manually in browser
+- Verify GitHub checks pass
+- Include test links in PRs
+
+**Remember:** The goal is confidence that your code works correctly, not achieving 100% test coverage. Write tests that provide value, and validate everything else in a browser.
diff --git a/.claude/.skills/testing-blocks/resources/browser-testing.md b/.claude/.skills/testing-blocks/resources/browser-testing.md
new file mode 100644
index 0000000..45422b1
--- /dev/null
+++ b/.claude/.skills/testing-blocks/resources/browser-testing.md
@@ -0,0 +1,333 @@
+# Browser Testing Guide
+
+Browser testing validates that blocks, DOM transformations, and visual elements work correctly in a real browser environment. These are throwaway tests - use them once to validate, capture screenshots, then discard them.
+
+## When to Use Browser Testing
+
+Use browser testing for:
+- **Block decoration validation** - Does the block transform HTML correctly?
+- **Visual appearance** - Does it look right at different screen sizes?
+- **Interactive behavior** - Do click handlers, forms, and interactions work?
+- **DOM structure** - Is the final rendered HTML correct?
+- **Responsive design** - Does it work on mobile, tablet, desktop?
+
+## Browser Testing Tools
+
+### Option 1: Playwright (Recommended)
+
+Playwright provides a full browser automation API with excellent developer experience.
+
+**Setup:**
+
+```bash
+npm install --save-dev playwright
+npx playwright install chromium
+```
+
+**Example throwaway test script:**
+
+```javascript
+// test-hero-block.js (DO NOT COMMIT)
+import { chromium } from 'playwright';
+
+async function testHeroBlock() {
+  const browser = await chromium.launch({ headless: false });
+  const page = await browser.newPage();
+
+  // Navigate to test content
+  await page.goto('http://localhost:3000/drafts/hero-test');
+
+  // Wait for block decoration
+  await page.waitForSelector('.hero');
+
+  // Take screenshot for validation
+  await page.screenshot({ path: 'hero-desktop.png', fullPage: true });
+
+  // Test mobile viewport
+  await page.setViewportSize({ width: 375, height: 667 });
+  await page.screenshot({ path: 'hero-mobile.png', fullPage: true });
+
+  // Test tablet viewport
+  await page.setViewportSize({ width: 768, height: 1024 });
+  await page.screenshot({ path: 'hero-tablet.png', fullPage: true });
+
+  // Validate DOM structure
+  const heroTitle = await page.textContent('.hero h1');
+  console.log('Hero title:', heroTitle);
+
+  // Test interactions
+  const button = page.locator('.hero .button');
+  await button.click();
+  await page.waitForTimeout(1000); // Wait for any animations
+
+  await browser.close();
+}
+
+testHeroBlock().catch(console.error);
+```
+
+**Run the test:**
+
+```bash
+node test-hero-block.js
+```
+
+### Option 2: Puppeteer
+
+Similar to Playwright but older. Use if Playwright isn't suitable.
+
+```bash
+npm install --save-dev puppeteer
+```
+
+API is very similar to Playwright. Substitute `puppeteer` for `playwright` in import statements.
+
+### Option 3: Browser MCP
+
+If you have access to a Browser MCP server, use it for interactive browser testing through Claude's tools.
+
+## Browser Testing Workflow
+
+### 1. Ensure dev server is running
+
+```bash
+aem up
+```
+
+Note the port (usually 3000).
+
+### 2. Write throwaway test script
+
+Create a temporary script file (e.g., `test-my-block.js`) with:
+- Navigation to test content URL
+- Waiting for block decoration
+- Taking screenshots at multiple viewports
+- Validating DOM structure or behavior
+- Testing interactions
+
+### 3. Run the script
+
+```bash
+node test-my-block.js
+```
+
+### 4. Review screenshots
+
+- Examine screenshots visually to validate appearance
+- Show screenshots to the user for feedback if needed
+- Include screenshots in PR description to aid review
+
+### 5. Clean up
+
+- Delete the test script (don't commit)
+- Keep screenshots temporarily for PR, then delete
+
+## Common Testing Scenarios
+
+### Testing Multiple Variants
+
+```javascript
+async function testBlockVariants() {
+  const browser = await chromium.launch({ headless: false });
+  const page = await browser.newPage();
+
+  const variants = ['default', 'dark', 'light', 'wide'];
+
+  for (const variant of variants) {
+    await page.goto(`http://localhost:3000/drafts/hero-${variant}`);
+    await page.waitForSelector('.hero');
+    await page.screenshot({
+      path: `hero-${variant}.png`,
+      fullPage: true
+    });
+  }
+
+  await browser.close();
+}
+```
+
+### Testing Interactive Elements
+
+```javascript
+async function testForm() {
+  const browser = await chromium.launch({ headless: false });
+  const page = await browser.newPage();
+
+  await page.goto('http://localhost:3000/drafts/contact-form');
+  await page.waitForSelector('.form');
+
+  // Fill out form
+  await page.fill('input[name="name"]', 'Test User');
+  await page.fill('input[name="email"]', 'test@example.com');
+  await page.fill('textarea[name="message"]', 'Test message');
+
+  // Take screenshot of filled form
+  await page.screenshot({ path: 'form-filled.png' });
+
+  // Submit form
+  await page.click('button[type="submit"]');
+
+  // Wait for success message
+  await page.waitForSelector('.form-success');
+  await page.screenshot({ path: 'form-success.png' });
+
+  await browser.close();
+}
+```
+
+### Testing Animations and Transitions
+
+```javascript
+async function testCarousel() {
+  const browser = await chromium.launch({ headless: false });
+  const page = await browser.newPage();
+
+  await page.goto('http://localhost:3000/drafts/carousel');
+  await page.waitForSelector('.carousel');
+
+  // Initial state
+  await page.screenshot({ path: 'carousel-1.png' });
+
+  // Click next button
+  await page.click('.carousel-next');
+  await page.waitForTimeout(500); // Wait for animation
+  await page.screenshot({ path: 'carousel-2.png' });
+
+  // Click next again
+  await page.click('.carousel-next');
+  await page.waitForTimeout(500);
+  await page.screenshot({ path: 'carousel-3.png' });
+
+  await browser.close();
+}
+```
+
+### Testing Responsive Behavior
+
+```javascript
+async function testResponsive() {
+  const browser = await chromium.launch({ headless: false });
+  const page = await browser.newPage();
+
+  await page.goto('http://localhost:3000/drafts/header');
+  await page.waitForSelector('.header');
+
+  // Desktop
+  await page.setViewportSize({ width: 1920, height: 1080 });
+  await page.screenshot({ path: 'header-desktop.png' });
+
+  // Tablet landscape
+  await page.setViewportSize({ width: 1024, height: 768 });
+  await page.screenshot({ path: 'header-tablet-landscape.png' });
+
+  // Tablet portrait
+  await page.setViewportSize({ width: 768, height: 1024 });
+  await page.screenshot({ path: 'header-tablet-portrait.png' });
+
+  // Mobile
+  await page.setViewportSize({ width: 375, height: 812 });
+  await page.screenshot({ path: 'header-mobile.png' });
+
+  await browser.close();
+}
+```
+
+## Browser Testing Best Practices
+
+### DO:
+- ✅ Test all viewport sizes (mobile, tablet, desktop)
+- ✅ Take screenshots for visual validation
+- ✅ Test all block variants in one script
+- ✅ Wait for block decoration before capturing state
+- ✅ Test interactive elements (clicks, forms, etc.)
+- ✅ Show screenshots to humans for feedback
+- ✅ Include screenshots in PRs to help reviewers
+
+### DON'T:
+- ❌ Commit throwaway test scripts to the repository
+- ❌ Try to automate visual regression testing (not worth the maintenance)
+- ❌ Write brittle assertions about specific DOM structure
+- ❌ Spend time making these tests maintainable (they're throwaway)
+- ❌ Test the same thing in both unit tests and browser tests
+
+## Playwright Tips and Tricks
+
+### Waiting for elements
+
+```javascript
+// Wait for selector
+await page.waitForSelector('.my-block');
+
+// Wait for specific text
+await page.waitForSelector('text=Click me');
+
+// Wait for network idle
+await page.waitForLoadState('networkidle');
+```
+
+### Taking targeted screenshots
+
+```javascript
+// Screenshot of specific element
+await page.locator('.hero').screenshot({ path: 'hero-only.png' });
+
+// Full page screenshot
+await page.screenshot({ path: 'full-page.png', fullPage: true });
+
+// Screenshot with specific viewport
+await page.screenshot({
+  path: 'mobile.png',
+  fullPage: true,
+  clip: { x: 0, y: 0, width: 375, height: 812 }
+});
+```
+
+### Debugging
+
+```javascript
+// Launch browser in non-headless mode
+const browser = await chromium.launch({ headless: false });
+
+// Slow down actions
+const browser = await chromium.launch({ slowMo: 500 });
+
+// Pause execution
+await page.pause();
+```
+
+### Extracting data
+
+```javascript
+// Get text content
+const text = await page.textContent('.selector');
+
+// Get attribute value
+const href = await page.getAttribute('a', 'href');
+
+// Check if element exists
+const exists = await page.locator('.selector').count() > 0;
+
+// Get all matching elements
+const items = await page.$$eval('.item', els => els.map(el => el.textContent));
+```
+
+## When Browser Tests Are Worth Keeping
+
+In rare cases, browser tests might be worth committing and maintaining:
+
+1. **Critical user flows** - Checkout process, authentication, critical forms
+2. **Cross-browser compatibility** - When you need to test in multiple browsers
+3. **Accessibility testing** - Using specialized tools like axe-core
+
+Even in these cases, keep tests focused on critical functionality only. The cost of maintaining browser tests is high.
+
+## Next Steps
+
+After browser testing:
+1. Review all screenshots carefully
+2. Show screenshots to stakeholders if needed
+3. Include key screenshots in your PR
+4. Delete the test script (don't commit it)
+5. Move on to other testing methods (linting, unit tests, etc.)
+
+Remember: Browser tests are a validation tool, not a regression prevention tool. Use them to confirm your implementation works, then move on.
diff --git a/.claude/.skills/testing-blocks/resources/testing-workflow.md b/.claude/.skills/testing-blocks/resources/testing-workflow.md
new file mode 100644
index 0000000..5a94518
--- /dev/null
+++ b/.claude/.skills/testing-blocks/resources/testing-workflow.md
@@ -0,0 +1,314 @@
+# Complete Testing Workflow
+
+This guide provides a step-by-step workflow for testing code changes from development through pull request approval.
+
+## Workflow Phases
+
+### Phase 1: During Development
+
+#### 1. Write unit tests as you code
+
+For any new utility functions or logic-heavy code, write unit tests alongside implementation:
+
+```bash
+# Open test in watch mode for immediate feedback
+npm run test:watch
+```
+
+This gives you instant feedback as you develop. Tests should be passing before you consider code complete.
+
+#### 2. Run tests in watch mode
+
+Keep `npm run test:watch` running during development to catch regressions immediately.
+
+#### 3. Manually test in browser
+
+View your changes in the local dev server as you work:
+
+```bash
+# Start dev server if not already running
+aem up
+```
+
+Navigate to your test content and verify the implementation looks and behaves correctly.
+
+### Phase 2: Before Committing
+
+#### 4. Run full test suite
+
+Ensure all keeper tests pass:
+
+```bash
+npm test
+```
+
+If tests fail:
+- Review the error messages
+- Fix broken functionality OR update tests if requirements changed
+- Re-run `npm test` until all pass
+
+#### 5. Run linting
+
+```bash
+npm run lint
+```
+
+If linting fails:
+
+```bash
+# Auto-fix what can be fixed
+npm run lint:fix
+
+# Manually fix remaining issues
+# Re-run to verify
+npm run lint
+```
+
+**Linting MUST pass before committing.** Non-negotiable.
+
+#### 6. Write throwaway browser test
+
+Create a temporary test script (e.g., `test-my-block.js`) to validate block behavior:
+
+```javascript
+// test-my-block.js (DO NOT COMMIT)
+import { chromium } from 'playwright';
+
+async function testMyBlock() {
+  const browser = await chromium.launch({ headless: false });
+  const page = await browser.newPage();
+
+  // Test desktop
+  await page.goto('http://localhost:3000/drafts/my-block-test');
+  await page.waitForSelector('.my-block');
+  await page.screenshot({ path: 'my-block-desktop.png', fullPage: true });
+
+  // Test mobile
+  await page.setViewportSize({ width: 375, height: 667 });
+  await page.screenshot({ path: 'my-block-mobile.png', fullPage: true });
+
+  await browser.close();
+}
+
+testMyBlock().catch(console.error);
+```
+
+#### 7. Run browser test
+
+Execute the script and review screenshots:
+
+```bash
+node test-my-block.js
+```
+
+Review each screenshot:
+- Does it look correct?
+- Are all variants working?
+- Is responsive behavior correct?
+- Do interactions work?
+
+#### 8. Manual validation
+
+Double-check test content in browser yourself. Don't rely solely on screenshots. Click around, test interactions, check on real devices if possible.
+
+### Phase 3: Before Opening PR
+
+#### 9. Commit and push
+
+```bash
+git add .
+git commit -m "Your commit message"
+git push -u origin your-feature-branch
+```
+
+#### 10. Verify branch is accessible
+
+Check that your branch preview loads:
+
+```
+https://your-branch--repo--owner.aem.page/path/to/test-content
+```
+
+Visit this URL in your browser to ensure the content is accessible for PSI checks.
+
+#### 11. Run `gh checks`
+
+Verify CI checks pass:
+
+```bash
+gh pr checks
+```
+
+Or if you haven't created the PR yet, you can check branch status:
+
+```bash
+gh pr status
+```
+
+#### 12. Create PR with test link
+
+Your PR description MUST include a test link for PSI checks:
+
+```markdown
+## Related Issues
+Fixes #123
+
+## Summary
+Added new hero block with support for multiple variants.
+
+## Testing
+Preview: https://hero-block--shsteimer-com--shsteimer.aem.page/drafts/hero-test
+```
+
+The test link is required for automatic performance testing.
+
+#### 13. Monitor GitHub checks
+
+After creating the PR, monitor checks:
+
+```bash
+# Watch checks in real-time
+gh pr checks --watch
+
+# Or check once
+gh pr checks
+```
+
+Wait for all checks to pass, especially PSI performance checks.
+
+### Phase 4: After PR Review
+
+#### 14. Address feedback
+
+If reviewers request changes:
+- Make the requested modifications
+- Follow the same workflow (test, lint, browser test)
+
+#### 15. Re-test
+
+After making changes:
+
+```bash
+# Run unit tests
+npm test
+
+# Run linting
+npm run lint
+
+# Create new browser test if needed
+node test-updated-block.js
+```
+
+#### 16. Verify checks pass
+
+```bash
+gh pr checks
+```
+
+Ensure all CI checks pass on the latest commit before requesting re-review.
+
+## Quick Reference Checklist
+
+Use this checklist for every code change:
+
+**During Development:**
+- [ ] Write unit tests for new utilities/logic
+- [ ] Run `npm run test:watch` during development
+- [ ] Manually test in browser at `http://localhost:3000`
+
+**Before Committing:**
+- [ ] Run `npm test` - all tests pass
+- [ ] Run `npm run lint` - linting passes
+- [ ] Write throwaway browser test script
+- [ ] Run browser test and review screenshots
+- [ ] Manually validate in browser
+
+**Before Opening PR:**
+- [ ] Commit and push to feature branch
+- [ ] Verify branch preview loads
+- [ ] Run `gh checks` to verify CI passes
+- [ ] Create PR with test link for PSI checks
+- [ ] Monitor `gh pr checks` until all pass
+
+**After PR Review:**
+- [ ] Address all feedback
+- [ ] Re-run tests and linting
+- [ ] Verify `gh pr checks` pass on latest commit
+
+## Integration with Other Skills
+
+This workflow integrates with other AEM skills:
+
+**content-driven-development** provides:
+- Test content URLs for validation
+- Content model for testing against
+
+**building-blocks** invokes testing-blocks:
+- After block implementation
+- With block name and test URLs
+
+**This skill returns:**
+- Confirmation tests pass
+- Screenshots for validation
+- Any issues discovered
+
+## Common Workflow Variations
+
+### For Bug Fixes
+
+1. Write a failing test that reproduces the bug
+2. Fix the bug
+3. Verify the test now passes
+4. Follow standard workflow
+
+### For Refactoring
+
+1. Ensure existing tests pass before starting
+2. Make refactoring changes
+3. Verify all tests still pass
+4. No new tests needed if behavior unchanged
+
+### For New Features
+
+1. Follow content-driven-development first
+2. Create test content
+3. Implement feature with unit tests
+4. Browser test to validate
+5. Follow standard workflow
+
+## Tips for Efficient Testing
+
+**Use watch mode during development:**
+```bash
+npm run test:watch
+```
+
+**Run single test file:**
+```bash
+npm test -- test/utils/my-utility.test.js
+```
+
+**Run tests matching pattern:**
+```bash
+npm test -- --grep "checkDomain"
+```
+
+**Generate coverage report:**
+```bash
+npm run test:coverage
+```
+
+**Monitor GitHub checks continuously:**
+```bash
+gh pr checks --watch
+```
+
+## Next Steps
+
+After completing this workflow:
+1. Delete throwaway browser test scripts
+2. Keep screenshots for PR, then delete
+3. Celebrate passing tests! 🎉
+4. Monitor PR for review feedback
+
+Remember: The goal is confidence your code works, not perfection. Follow the workflow, fix what breaks, and ship with confidence.
diff --git a/.claude/.skills/testing-blocks/resources/troubleshooting.md b/.claude/.skills/testing-blocks/resources/troubleshooting.md
new file mode 100644
index 0000000..6b34fd4
--- /dev/null
+++ b/.claude/.skills/testing-blocks/resources/troubleshooting.md
@@ -0,0 +1,461 @@
+# Testing Troubleshooting Guide
+
+Common issues encountered during testing and how to resolve them.
+
+## Tests Fail After Changes
+
+### Unit Tests Fail
+
+**Symptoms:**
+- Test suite runs but some tests fail
+- Error messages about unexpected values or behaviors
+
+**Diagnosis:**
+
+1. **Read the error message carefully**
+   - What assertion failed?
+   - What was expected vs actual?
+   - Which test file and line number?
+
+2. **Determine the cause:**
+   - Did you break existing functionality?
+   - Did requirements change?
+   - Is the test incorrect?
+
+**Solutions:**
+
+**If you broke functionality:**
+```bash
+# Fix the code, not the test
+# Re-run tests
+npm test
+```
+
+**If requirements changed:**
+```bash
+# Update the test to match new requirements
+# Ensure the change is intentional
+npm test
+```
+
+**If testing a specific file:**
+```bash
+# Run just one test file for faster feedback
+npm test -- test/utils/my-utility.test.js
+```
+
+**If debugging a specific test:**
+```bash
+# Use test.only to run just one test
+it.only('should do something', () => {
+  // This test will be the only one that runs
+});
+```
+
+### Browser Tests Fail
+
+**Symptoms:**
+- Browser test script throws errors
+- Screenshots not generated
+- Timeouts occur
+
+**Common Issues and Solutions:**
+
+**Issue: Dev server not running**
+```bash
+# Start the dev server
+aem up
+
+# Verify it's accessible
+curl http://localhost:3000
+```
+
+**Issue: Test content doesn't exist**
+- Verify the URL manually in a browser
+- Check that content is published/previewed
+- Ensure path in test script is correct
+
+**Issue: Block not decorated**
+```javascript
+// Add wait for specific selector
+await page.waitForSelector('.my-block');
+
+// Or wait for network idle
+await page.waitForLoadState('networkidle');
+
+// Or increase timeout
+await page.waitForSelector('.my-block', { timeout: 10000 });
+```
+
+**Issue: Timing problems**
+```javascript
+// Wait for animations to complete
+await page.waitForTimeout(500);
+
+// Wait for specific state
+await page.waitForFunction(() => {
+  return document.querySelector('.my-block').classList.contains('loaded');
+});
+```
+
+**Issue: Elements not clickable**
+```javascript
+// Wait for element to be clickable
+await page.locator('.button').click({ force: false });
+
+// Or scroll into view first
+await page.locator('.button').scrollIntoViewIfNeeded();
+await page.locator('.button').click();
+```
+
+## Linting Fails
+
+### Common Linting Issues
+
+**Unused variables**
+```javascript
+// Error: 'foo' is defined but never used
+const foo = 'bar';
+
+// Fix: Remove unused variable
+// Or use it
+```
+
+**Missing semicolons**
+```javascript
+// Error: Missing semicolon
+const foo = 'bar'
+
+// Fix: Add semicolon
+const foo = 'bar';
+```
+
+**Incorrect indentation**
+```bash
+# Auto-fix indentation issues
+npm run lint:fix
+```
+
+**Console.log statements**
+```javascript
+// Error: Unexpected console statement
+console.log('debug info');
+
+// Fix Option 1: Remove it
+// (remove the line)
+
+// Fix Option 2: Disable rule for this line
+// eslint-disable-next-line no-console
+console.log('debug info');
+```
+
+**Import issues**
+```javascript
+// Error: Unable to resolve path to module
+import { foo } from './utils';
+
+// Fix: Add .js extension
+import { foo } from './utils.js';
+```
+
+**Airbnb style violations**
+```javascript
+// Error: Expected a line break after this opening brace
+import { foo, bar } from './utils.js';
+
+// Fix: Let lint:fix handle it
+// Or manually format:
+import {
+  foo,
+  bar,
+} from './utils.js';
+```
+
+### Quick Fixes
+
+**Auto-fix everything possible:**
+```bash
+npm run lint:fix
+```
+
+**Check what would be fixed:**
+```bash
+npm run lint:js -- --fix-dry-run
+```
+
+**Lint specific files:**
+```bash
+npm run lint:js -- test/utils/my-test.test.js
+```
+
+## GitHub Checks Fail
+
+### Checks Don't Run
+
+**Issue: PSI checks not running**
+
+**Cause:** Missing test link in PR description
+
+**Solution:**
+```markdown
+## Testing
+Preview: https://branch--repo--owner.aem.page/path/to/test
+```
+
+The test link MUST be in the PR description for PSI checks to run.
+
+**Issue: Actions workflow disabled**
+
+Check repository settings → Actions → ensure workflows are enabled.
+
+### PSI Checks Fail
+
+**Issue: Poor performance score**
+
+**Common causes:**
+- Too much JavaScript loaded eagerly
+- CSS blocking render
+- Large unoptimized images
+- Third-party scripts in eager phase
+
+**Solutions:**
+
+**Move JavaScript to lazy or delayed phase:**
+```javascript
+// In scripts.js, move non-LCP code to loadLazy() or loadDelayed()
+```
+
+**Optimize images:**
+- Use WebP format
+- Lazy load below-the-fold images
+- Use appropriate dimensions
+
+**Defer non-critical CSS:**
+```css
+/* Move non-LCP styles to lazy-styles.css */
+```
+
+**Review performance report:**
+```bash
+# Check details in GitHub PR checks
+gh pr checks
+
+# Click on failed check for details
+```
+
+### Linting Checks Fail in CI
+
+**Issue: Tests pass locally but fail in CI**
+
+**Cause:** Linting not run locally or different config
+
+**Solution:**
+```bash
+# Always run lint before committing
+npm run lint
+
+# Ensure .eslintrc.js is committed
+git add .eslintrc.js
+git commit -m "Add eslint config"
+```
+
+## Tests Pass Locally But Fail in CI
+
+### Different Node Version
+
+**Symptoms:**
+- Syntax errors in CI
+- Missing features
+
+**Solution:**
+
+Check CI Node version matches local:
+```bash
+# Check local version
+node --version
+
+# Add .nvmrc if needed
+echo "20" > .nvmrc
+git add .nvmrc
+git commit -m "Add nvmrc for consistent Node version"
+```
+
+### Missing Dependencies
+
+**Symptoms:**
+- Module not found errors in CI
+- Dependencies work locally
+
+**Solution:**
+
+```bash
+# Ensure package.json is up to date
+git add package.json package-lock.json
+git commit -m "Update dependencies"
+
+# Or regenerate lock file
+rm package-lock.json
+npm install
+git add package-lock.json
+```
+
+### Environment Differences
+
+**Symptoms:**
+- Tests dependent on local files fail
+- Absolute paths don't work
+
+**Solution:**
+
+Use relative paths and environment-agnostic code:
+```javascript
+// Bad: Absolute path
+const path = '/Users/me/project/file.js';
+
+// Good: Relative path
+const path = './file.js';
+```
+
+### Race Conditions
+
+**Symptoms:**
+- Tests sometimes pass, sometimes fail
+- Timing-dependent failures
+
+**Solution:**
+
+Add proper waits:
+```javascript
+// Bad: No wait
+it('should update text', async () => {
+  await updateText();
+  expect(getText()).toBe('updated');
+});
+
+// Good: Wait for update
+it('should update text', async () => {
+  await updateText();
+  await waitFor(() => getText() === 'updated');
+  expect(getText()).toBe('updated');
+});
+```
+
+## Vitest-Specific Issues
+
+### Module Resolution Errors
+
+**Error:**
+```
+Failed to resolve import './utils.js'
+```
+
+**Solution:**
+
+Check import paths are correct:
+```javascript
+// From test/utils/my-test.test.js
+// Importing from scripts/utils/my-utility.js
+
+// Correct:
+import { myUtility } from '../../scripts/utils/my-utility.js';
+
+// Wrong (missing ../../):
+import { myUtility } from 'scripts/utils/my-utility.js';
+```
+
+### jsdom Errors
+
+**Error:**
+```
+document is not defined
+```
+
+**Solution:**
+
+Ensure vitest.config.js has jsdom environment:
+```javascript
+export default defineConfig({
+  test: {
+    environment: 'jsdom', // Important!
+  },
+});
+```
+
+### Coverage Not Generated
+
+**Error:**
+```
+Coverage provider not found
+```
+
+**Solution:**
+
+Install coverage package:
+```bash
+npm install --save-dev @vitest/coverage-v8
+```
+
+## Getting Help
+
+If you're stuck:
+
+1. **Read the error message completely** - Often contains the solution
+2. **Check the documentation** - vitest.dev, playwright.dev
+3. **Search existing issues** - GitHub issues for Vitest/Playwright
+4. **Simplify** - Create minimal reproduction of the issue
+5. **Ask for help** - Include error messages and context
+
+## Preventive Measures
+
+**To avoid issues:**
+
+- ✅ Run `npm test` before every commit
+- ✅ Run `npm run lint` before every commit
+- ✅ Use `npm run test:watch` during development
+- ✅ Test in browser manually before opening PR
+- ✅ Include test links in PR descriptions
+- ✅ Monitor `gh pr checks` after creating PR
+
+**Don't:**
+- ❌ Skip testing locally
+- ❌ Commit failing tests
+- ❌ Ignore linting errors
+- ❌ Force push without re-running tests
+- ❌ Merge PRs with failing checks
+
+## Quick Diagnostic Commands
+
+```bash
+# Check Node version
+node --version
+
+# Check npm version
+npm --version
+
+# Verify Vitest installed
+npm list vitest
+
+# Verify test config
+cat vitest.config.js
+
+# Check dev server running
+curl http://localhost:3000
+
+# Verify git status
+git status
+
+# Check GitHub PR status
+gh pr checks
+```
+
+## Next Steps
+
+After resolving issues:
+
+1. Re-run all checks
+2. Verify everything passes
+3. Commit fixes if needed
+4. Update documentation if issue was unclear
+5. Help others avoid the same issue
+
+Remember: Every error is a learning opportunity. Take time to understand why something failed, not just how to fix it.
diff --git a/.claude/.skills/testing-blocks/resources/unit-testing.md b/.claude/.skills/testing-blocks/resources/unit-testing.md
new file mode 100644
index 0000000..ccee349
--- /dev/null
+++ b/.claude/.skills/testing-blocks/resources/unit-testing.md
@@ -0,0 +1,264 @@
+# Unit Testing Guide
+
+Unit tests are keeper tests for logic-heavy code that benefits from automated regression testing. This guide covers when to write unit tests, how to structure them, and best practices for maintainable test suites.
+
+## When to Write Unit Tests
+
+Write unit tests for:
+- **Pure functions** - Functions with no side effects that transform inputs to outputs
+- **Utility libraries** - Shared helper functions used across blocks
+- **Data processors** - Code that parses, transforms, or validates data
+- **API integrations** - Functions that interact with external services
+- **Complex algorithms** - Business logic, calculations, or conditional flows
+
+Do NOT write unit tests for:
+- Block decoration functions (test these in browser)
+- DOM manipulation logic (test in browser)
+- CSS styles (test in browser)
+- Simple getters/setters
+- Code that primarily renders UI
+
+## Prerequisites
+
+This guide assumes Vitest is already configured in the project. If not, see `vitest-setup.md` for one-time setup instructions.
+
+**Verify test setup exists:**
+
+```bash
+npm test  # Should run without errors (even if no tests exist yet)
+```
+
+If the command fails or Vitest is not installed, consult `vitest-setup.md`.
+
+**Important:** Ensure test files are not served to production by adding them to `.hlxignore`:
+
+```
+# .hlxignore
+test/
+*.test.js
+```
+
+This prevents test files from being accessible on your live site.
+
+## Writing Unit Tests
+
+### File Location and Naming
+
+Place test files next to the code they test:
+- `scripts/utils/my-utility.js` → `test/utils/my-utility.test.js`
+- `blocks/hero/utils.js` → `test/blocks/hero/utils.test.js`
+
+**Naming convention:** `{filename}.test.js`
+
+### Test Structure
+
+```javascript
+import { describe, it, expect } from 'vitest';
+import { myUtility } from '../../scripts/utils/my-utility.js';
+
+describe('myUtility', () => {
+  it('should transform input correctly', () => {
+    const input = { foo: 'bar' };
+    const result = myUtility(input);
+    expect(result).toEqual({ foo: 'BAR' });
+  });
+
+  it('should handle edge cases', () => {
+    expect(myUtility(null)).toBeNull();
+    expect(myUtility({})).toEqual({});
+  });
+});
+```
+
+### Running Tests
+
+```bash
+npm test                 # Run all tests once
+npm run test:watch      # Run tests in watch mode
+npm run test:ui         # Open interactive UI
+npm run test:coverage   # Generate coverage report
+```
+
+## What Makes a Good Unit Test
+
+**Good unit tests are:**
+- **Fast** - Run in milliseconds
+- **Isolated** - Test one function/unit at a time
+- **Repeatable** - Same input always produces same output
+- **Self-validating** - Pass or fail clearly, no manual inspection
+- **Focused** - Test one behavior per test case
+
+## Complete Example
+
+Here's an example of a keeper test that's worth maintaining:
+
+```javascript
+// scripts/utils/url-helpers.js
+export function normalizeUrl(url, base) {
+  if (!url) return '';
+  if (url.startsWith('http://') || url.startsWith('https://')) return url;
+  if (url.startsWith('/')) return `${base}${url}`;
+  return `${base}/${url}`;
+}
+
+// test/utils/url-helpers.test.js
+import { describe, it, expect } from 'vitest';
+import { normalizeUrl } from '../../scripts/utils/url-helpers.js';
+
+describe('normalizeUrl', () => {
+  const base = 'https://example.com';
+
+  it('returns empty string for null/undefined', () => {
+    expect(normalizeUrl(null, base)).toBe('');
+    expect(normalizeUrl(undefined, base)).toBe('');
+  });
+
+  it('returns absolute URLs unchanged', () => {
+    expect(normalizeUrl('https://other.com/path', base)).toBe('https://other.com/path');
+    expect(normalizeUrl('http://other.com/path', base)).toBe('http://other.com/path');
+  });
+
+  it('prepends base to root-relative URLs', () => {
+    expect(normalizeUrl('/path/to/page', base)).toBe('https://example.com/path/to/page');
+  });
+
+  it('prepends base with slash to relative URLs', () => {
+    expect(normalizeUrl('path/to/page', base)).toBe('https://example.com/path/to/page');
+  });
+});
+```
+
+**Why this test is worth maintaining:**
+- URL normalization is used across many blocks
+- Bugs here would break multiple features
+- Logic is complex enough to benefit from regression tests
+- Test is fast and easy to maintain
+
+## Testing with jsdom
+
+When testing DOM-dependent code, jsdom provides a browser-like environment:
+
+```javascript
+import { describe, it, expect, beforeEach } from 'vitest';
+import { JSDOM } from 'jsdom';
+
+describe('DOM manipulation', () => {
+  let document;
+
+  beforeEach(() => {
+    const dom = new JSDOM('<!DOCTYPE html><html><body></body></html>');
+    document = dom.window.document;
+    global.document = document;
+  });
+
+  it('should create elements', () => {
+    const div = document.createElement('div');
+    div.textContent = 'Hello';
+    expect(div.textContent).toBe('Hello');
+  });
+});
+```
+
+## Integration Tests
+
+Integration tests validate that multiple components work together correctly. These fall into the "keeper" category if they test critical workflows.
+
+**When to write integration tests:**
+- Auto-blocking logic that depends on multiple functions
+- Complex workflows spanning multiple utilities
+- Critical user journeys that depend on multiple blocks
+
+Integration tests use the same Vitest setup as unit tests but test multiple components together.
+
+**Example integration test:**
+
+```javascript
+// test/integration/auto-blocking.test.js
+import { describe, it, expect, beforeEach } from 'vitest';
+import { JSDOM } from 'jsdom';
+import { buildAutoBlocks } from '../../scripts/scripts.js';
+
+describe('Auto-blocking integration', () => {
+  let document;
+
+  beforeEach(() => {
+    const dom = new JSDOM('<!DOCTYPE html><html><body></body></html>');
+    document = dom.window.document;
+    global.document = document;
+  });
+
+  it('should auto-block hero from first section with image', () => {
+    const main = document.createElement('main');
+    const section = document.createElement('div');
+    const picture = document.createElement('picture');
+    section.appendChild(picture);
+    main.appendChild(section);
+
+    buildAutoBlocks(main);
+
+    const hero = main.querySelector('.hero');
+    expect(hero).toBeTruthy();
+    expect(hero.querySelector('picture')).toBeTruthy();
+  });
+});
+```
+
+Integration tests are worth maintaining if:
+- The workflow is critical to site functionality
+- Multiple teams/developers work on related code
+- Bugs in this integration would be expensive to fix
+
+## Best Practices
+
+1. **Test behavior, not implementation** - Focus on what the function does, not how it does it
+2. **Use descriptive test names** - Test names should explain what they're testing
+3. **One assertion per test** - Or multiple assertions testing the same behavior
+4. **Avoid test interdependence** - Each test should be able to run independently
+5. **Keep tests simple** - Tests should be easier to understand than the code they test
+6. **Mock external dependencies** - API calls, file system access, etc.
+7. **Test edge cases** - Null, undefined, empty strings, boundary values
+
+## Common Patterns
+
+### Testing async functions
+
+```javascript
+it('should fetch data asynchronously', async () => {
+  const result = await fetchData();
+  expect(result).toBeDefined();
+});
+```
+
+### Using beforeEach for setup
+
+```javascript
+describe('Calculator', () => {
+  let calculator;
+
+  beforeEach(() => {
+    calculator = new Calculator();
+  });
+
+  it('should add numbers', () => {
+    expect(calculator.add(2, 3)).toBe(5);
+  });
+});
+```
+
+### Testing error conditions
+
+```javascript
+it('should throw error for invalid input', () => {
+  expect(() => {
+    validateInput('invalid');
+  }).toThrow('Invalid input');
+});
+```
+
+## Next Steps
+
+Once you've written unit tests:
+1. Run tests during development with `npm run test:watch`
+2. Run full test suite before commits with `npm test`
+3. Monitor coverage with `npm run test:coverage`
+4. Keep tests updated as code evolves
diff --git a/.claude/.skills/testing-blocks/resources/vitest-setup.md b/.claude/.skills/testing-blocks/resources/vitest-setup.md
new file mode 100644
index 0000000..9ec648f
--- /dev/null
+++ b/.claude/.skills/testing-blocks/resources/vitest-setup.md
@@ -0,0 +1,204 @@
+# Vitest Setup Guide
+
+This guide covers the one-time setup of Vitest for unit testing in AEM Edge Delivery projects. Once configured, you won't need to repeat these steps.
+
+## Installation
+
+Install Vitest and required dependencies:
+
+```bash
+npm install --save-dev vitest @vitest/ui jsdom
+```
+
+Optional but recommended for coverage reports:
+
+```bash
+npm install --save-dev @vitest/coverage-v8
+```
+
+## Configuration
+
+Create `vitest.config.js` in the project root:
+
+```javascript
+import { defineConfig } from 'vitest/config';
+
+export default defineConfig({
+  test: {
+    environment: 'jsdom',
+    globals: true,
+    coverage: {
+      provider: 'v8',
+      reporter: ['text', 'html'],
+      exclude: [
+        'node_modules/',
+        'test/',
+        '**/*.config.js',
+      ],
+    },
+  },
+});
+```
+
+### Configuration Options Explained
+
+- **environment: 'jsdom'** - Provides browser-like environment for testing DOM code
+- **globals: true** - Makes `describe`, `it`, `expect` available without imports
+- **coverage** - Configures code coverage reporting (optional but useful)
+
+## Package.json Scripts
+
+Add test scripts to your `package.json`:
+
+```json
+{
+  "scripts": {
+    "test": "vitest run",
+    "test:watch": "vitest",
+    "test:ui": "vitest --ui",
+    "test:coverage": "vitest run --coverage"
+  }
+}
+```
+
+### Script Descriptions
+
+- **`npm test`** - Run all tests once (use in CI or before commits)
+- **`npm run test:watch`** - Run tests in watch mode (use during development)
+- **`npm run test:ui`** - Open interactive web UI for tests
+- **`npm run test:coverage`** - Generate code coverage report
+
+## Directory Structure
+
+Create directories for test files:
+
+```bash
+mkdir -p test/utils
+mkdir -p test/blocks
+```
+
+### Recommended Structure
+
+```
+project-root/
+├── scripts/
+│   └── utils/
+│       └── my-utility.js
+├── blocks/
+│   └── hero/
+│       ├── hero.js
+│       ├── hero.css
+│       └── utils.js
+└── test/
+    ├── utils/
+    │   └── my-utility.test.js
+    └── blocks/
+        └── hero/
+            └── utils.test.js
+```
+
+**Test file naming:** `{filename}.test.js`
+
+## Verify Installation
+
+Run tests to verify setup:
+
+```bash
+npm test
+```
+
+If no tests exist yet, you should see:
+
+```
+No test files found, exiting with code 0
+```
+
+Create a simple test to verify everything works:
+
+```javascript
+// test/example.test.js
+import { describe, it, expect } from 'vitest';
+
+describe('Vitest setup', () => {
+  it('should be configured correctly', () => {
+    expect(true).toBe(true);
+  });
+});
+```
+
+Run tests again:
+
+```bash
+npm test
+```
+
+You should see the test pass. Once verified, delete `test/example.test.js`.
+
+## Usage with jsdom
+
+When testing DOM-dependent code, jsdom provides a browser-like environment:
+
+```javascript
+import { describe, it, expect, beforeEach } from 'vitest';
+import { JSDOM } from 'jsdom';
+
+describe('DOM manipulation', () => {
+  let document;
+
+  beforeEach(() => {
+    const dom = new JSDOM('<!DOCTYPE html><html><body></body></html>');
+    document = dom.window.document;
+    global.document = document;
+  });
+
+  it('should create elements', () => {
+    const div = document.createElement('div');
+    div.textContent = 'Hello';
+    expect(div.textContent).toBe('Hello');
+  });
+});
+```
+
+## CI Integration
+
+For GitHub Actions or other CI, tests run automatically with:
+
+```bash
+npm test
+```
+
+Consider adding to your CI workflow:
+
+```yaml
+- name: Run tests
+  run: npm test
+
+- name: Generate coverage
+  run: npm run test:coverage
+```
+
+## Troubleshooting
+
+**"vitest: command not found"**
+- Ensure `vitest` is in `devDependencies` in package.json
+- Run `npm install`
+
+**"Cannot find module 'jsdom'"**
+- Install jsdom: `npm install --save-dev jsdom`
+
+**Tests not finding imports**
+- Check import paths are correct relative to test file location
+- Ensure files being tested export the functions properly
+
+**Coverage not working**
+- Install coverage provider: `npm install --save-dev @vitest/coverage-v8`
+
+## Next Steps
+
+Once setup is complete:
+1. Write unit tests following the patterns in the main **testing-blocks** skill
+2. Run tests during development with `npm run test:watch`
+3. Run full test suite before commits with `npm test`
+4. Monitor coverage with `npm run test:coverage`
+
+This is a one-time setup. Once configured, focus on writing valuable tests rather than configuration.
diff --git a/.gitignore b/.gitignore
index 6c66aaa..5f4aed1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,10 +2,6 @@
 coverage/*
 logs/*
 node_modules/*
-.agents/*
-.skills/*
-AGENTS.md
-SKILLS.md
 
 helix-importer-ui
 .DS_Store
diff --git a/AGENTS.md b/AGENTS.md
new file mode 100644
index 0000000..d193691
--- /dev/null
+++ b/AGENTS.md
@@ -0,0 +1,48 @@
+# AGENTS.md
+
+<!-- upskill:skills:start -->
+## Skills
+
+You have access to a set of skills in .claude/skills. Each skill consists of a SKILL.md file, and other files such as scripts and resources, which are referenced from there.
+
+**YOU ARE REQUIRED TO USE THESE SKILLS TO ACCOMPLISH DEVELOPMENT TASKS. FAILING TO DO SO WILL RESULT IN WASTED TIME AND CYCLES.**
+
+### How Skills Work
+
+Each skill is a directory in `.claude/skills/` with the following structure:
+
+```
+.claude/skills/
+  └── {skill-name}/
+      ├── SKILL.md        # Main instructions (required)
+      ├── scripts/        # Optional supporting scripts
+      └── resources/      # Optional resources (examples, templates, etc.)
+```
+
+The SKILL.md file contains detailed instructions that you must follow exactly as written. Skills are designed to:
+- Provide specialized workflows for common tasks
+- Ensure consistency with project standards and best practices
+- Reduce errors by codifying expert knowledge
+- Chain together when tasks require multiple skill applications
+
+### Skill Discovery and Execution Process
+
+Always use the following process:
+
+1. **Discovery**: When a new conversation starts, discover available skills by running `./.agents/discover-skills`. This script will show you all available skills with their names, paths, and descriptions without loading everything into context.
+
+2. **Selection**: Use each skill based on its name and description when it feels appropriate to do so. Think carefully about all the skills available to you and choose the best ones to use. Note that some skills may reference other skills, so you may need to apply more than one skill to get things done.
+
+3. **Execution**: When you need to use a skill:
+   - Read the full SKILL.md file
+   - Announce you are doing so by saying "Using Skill: {Skill Name}"
+   - Follow the skill's instructions exactly as written
+   - Read any referenced resources or scripts as needed
+   - Complete all steps in the skill before moving to the next task
+
+### Available Skills
+
+Skills will be added to `.claude/skills/` as needed for this project. Check the `.claude/skills/` directory or run `./.agents/discover-skills` for the current list of available skills.
+
+**For ALL development work involving blocks, core scripts, or functionality, you MUST start with the content-driven-development skill.** It will orchestrate other skills as needed throughout the development workflow.
+<!-- upskill:skills:end -->
diff --git a/CLAUDE.md b/CLAUDE.md
new file mode 100644
index 0000000..e75524e
--- /dev/null
+++ b/CLAUDE.md
@@ -0,0 +1,234 @@
+# CLAUDE.md
+
+This project is a website built with Edge Delivery Services in Adobe Experience Manager Sites as a Cloud Service. As an agent, follow the instructions in this file to deliver code based on Adobe's standards for fast, easy-to-author, and maintainable web experiences.
+
+## Skills
+
+**For ALL development work involving blocks, core scripts, or functionality, you MUST start with the content-driven-development skill.** It will orchestrate other skills as needed throughout the development workflow.
+
+Two skills serve as primary entry points for common workflows:
+
+**content-driven-development** - Start here for ALL code changes including: new blocks, block modifications, CSS styling, bug fixes, core functionality (scripts.js, styles.css, delayed.js), auto-blocking changes, or any JavaScript/CSS work. This skill orchestrates the complete development workflow from content modeling through implementation and testing.
+
+**page-import** - Start here when importing or migrating webpages from any URL to AEM Edge Delivery Services. This skill orchestrates the complete import workflow including scraping, analysis, structure identification, and HTML generation.
+
+All other skills are either invoked by these primary skills or used for specific standalone tasks (e.g., searching platform documentation, finding reference implementations, reviewing PRs). Let skill descriptions guide you to the right tool for your task.
+
+## Project Overview
+
+This project is based on the https://github.com/adobe/aem-boilerplate/ project and set up as a new project. You are expected to follow the coding style and practices established in the boilerplate, but add functionality according to the needs of the site currently developed.
+
+The repository provides the basic structure, blocks, and configuration needed to run a complete site with `*.aem.live` as the backend.
+
+### Key Technologies
+- Edge Delivery Services for AEM Sites (documentation at https://www.aem.live/ – search with `site:www.aem.live` to restrict web search results)
+- Vanilla JavaScript (ES6+), no transpiling, no build steps
+- CSS3 with modern features, no Tailwind or other CSS frameworks
+- HTML5 semantic markup generated by the aem.live backend, decorated by our code
+- Node.js tooling
+
+## Setup Commands
+
+- Install dependencies: `npm install`
+- Start local development: `npx -y @adobe/aem-cli up --no-open --forward-browser-logs` (run in background, if possible)
+  - Install the AEM CLI globally by running `npm install -g @adobe/aem-cli` then `aem up` is equivalent to the command above
+- Run linting: `npm run lint`
+- Fix linting issues: `npm run lint:fix`
+
+## Project Structure
+
+```
+├── blocks/          # Reusable content blocks
+    └── {blockName}/   - Individual block directory
+        ├── {blockName}.js      # Block's JavaScript
+        └── {blockName}.css     # Block's styles
+├── styles/          # Global styles and CSS
+    ├── styles.css          # Minimal global styling and layout for your website required for LCP
+    └── lazy-styles.css     # Additional global styling and layout for below the fold/post LCP content
+├── scripts/         # JavaScript libraries and utilities
+    ├── aem.js           # Core AEM Library for Edge Delivery page decoration logic (NEVER MODIFY THIS FILE)
+    ├── scripts.js       # Global JavaScript utilities, main entry point for page decoration
+    └── delayed.js       # Delayed functionality such as martech loading
+├── fonts/           # Web fonts
+├── icons/           # SVG icons
+├── head.html        # Global HTML head content
+└── 404.html         # Custom 404 page
+```
+
+## Code Style Guidelines
+
+### JavaScript
+- Use ES6+ features (arrow functions, destructuring, etc.)
+- Follow Airbnb ESLint rules (already configured)
+- Always include `.js` file extensions in imports
+- Use Unix line endings (LF)
+
+**For detailed JavaScript guidelines:** Use the **building-blocks** skill which includes comprehensive decoration patterns and best practices.
+
+### CSS
+- Mobile-first responsive design (breakpoints: 600px/900px/1200px)
+- All selectors scoped to blocks: `.{blockName} .selector`
+- Follow Stylelint standard configuration
+
+**For detailed CSS guidelines:** Use the **building-blocks** skill which includes comprehensive styling patterns and best practices.
+
+### HTML
+- Use semantic HTML5 elements
+- Ensure accessibility standards (ARIA labels, proper heading hierarchy)
+- Follow AEM markup conventions for blocks and sections
+
+## Key Concepts
+
+### Content
+
+CMS authored content is a key part of every AEM Website. The content of a page is broken into sections. Sections can have default content (text, headings, links, etc.) as well as content in blocks.
+
+**For development workflow:** Use the **content-driven-development** skill for all development tasks. This skill ensures you identify or create test content before writing code, following AEM best practices.
+
+**Quick tips:**
+- Inspect page structure: `curl http://localhost:3000/path/to/page`
+- View source markdown: `curl http://localhost:3000/path/to/page.md`
+- Local test content: Use `--html-folder drafts` flag when starting dev server
+
+### Blocks
+
+Blocks are the re-usable building blocks of AEM. Blocks add styling and functionality to content. Each block has an initial content structure it expects, and transforms the HTML using DOM APIs to render a final structure.
+
+**Key principle:** The initial content structure is the contract between authors and developers. Design this structure before writing any code, and be careful when making changes that could break existing pages.
+
+**For creating or modifying blocks:** Use the **building-blocks** skill which guides you through:
+- Content model design (via content-driven-development)
+- JavaScript decoration patterns
+- CSS styling conventions
+- Testing and validation
+
+**Tip:** Use `curl http://localhost:3000/path/to/page` to inspect the HTML delivered by the backend before making assumptions.
+
+### Auto-Blocking
+
+Auto-blocking is the process of creating blocks that aren't explicitly authored into the page based on patterns in the content. See the `buildAutoBlocks` function in `scripts.js`.
+
+### Three-Phase Page Loading
+
+Pages are progressively loaded in three phases to maximize performance. This process begins when `loadPage` from scripts.js is called.
+
+* Eager - load only what is required to get to LCP. This generally includes decorating the overall page content to create sections, blocks, buttons, etc. and loading the first section of the page.
+* Lazy - load all other page content, including the header and footer.
+* Delayed - load things that can be safely loaded later here and incur a performance penalty when loaded earlier
+
+## Development Workflow
+
+**For all development tasks:** Use the **content-driven-development** skill which orchestrates the complete workflow:
+1. Content discovery and modeling
+2. Implementation (invokes building-blocks skill for blocks)
+3. Validation and testing (invokes testing-blocks skill)
+
+### Local Development
+1. Run `npx -y @adobe/aem-cli up --no-open` to start the AEM Proxy server
+2. Open `http://localhost:3000` in your browser, puppeteer, playwright, or other tools. If none of those are available, instruct the human to open the URL in the browser and give feedback
+3. Make changes to files - they will auto-reload
+4. Use browser dev tools to test responsive design
+
+### File Organization
+- Block files: `blocks/{blockname}/{blockname}.js` and `{blockname}.css`
+- Global styles: `styles/styles.css` (eager), `styles/lazy-styles.css` (lazy)
+- Font definitions: `styles/fonts.css`
+- Each block should be self-contained, responsive, and accessible
+
+## Testing & Quality Assurance
+
+**For comprehensive testing guidance:** Use the **testing-blocks** skill which covers:
+- Unit testing for logic-heavy utilities
+- Browser testing with Playwright/Puppeteer
+- Linting and code quality
+- Performance validation
+- PR preparation
+
+### Quick Reference
+- **Linting:** `npm run lint` (must pass before commits), `npm run lint:fix` to auto-fix
+- **Performance:** Follow https://www.aem.live/developer/keeping-it-100
+- **Accessibility:** Proper heading hierarchy, alt text, WCAG 2.1 AA guidelines
+
+## Deployment
+
+### Environments
+
+Edge Delivery Services provides you with three environments. Your local development server at `http://localhost:3000` serves code from your local working copy (even uncommitted code) and content that has been previewed by authors. You can access this at any time when the development server is running.
+
+For all other environments, you need to know the GitHub owner and repository name (`gh repo view --json nameWithOwner` or `git remote -v`) and the current branch name `git branch`)
+
+With this information, you can construct URLs for the preview environment (same content as `localhost:3000`) and the production environment (same content as the live website, approved by authors)
+
+- **Production Preview**: `https://main--{repo}--{owner}.aem.page/`
+- **Production Live**: `https://main--{repo}--{owner}.aem.live/`
+- **Feature Preview**: `https://{branch}--{repo}--{owner}.aem.page/`
+
+### Publishing Process
+1. Push changes to a feature branch
+2. AEM Code Sync automatically processes changes making them available on feature preview environment for that branch
+3. Open a pull request to merge changes to `main`
+   - **REQUIRED:** Include preview link in PR description: `https://{branch}--{repo}--{owner}.aem.page/{path}`
+   - This link is used for automated performance testing (PSI checks)
+   - Without this link, your PR will be rejected
+4. Verify checks pass: `gh checks` or `gh pr checks --watch`
+5. A human reviewer will review the code, inspect the preview URL, and merge the PR
+6. AEM Code Sync updates the main branch for production
+
+**For PR preparation and testing:** See the **testing-blocks** skill for comprehensive guidance on testing before opening a PR.
+
+## Common Tasks
+
+### Adding New Blocks
+Use the **content-driven-development** skill which will guide you through:
+1. Content modeling and test content creation
+2. Block implementation (via building-blocks skill)
+3. Testing and validation (via testing-blocks skill)
+
+### Modifying Existing Blocks
+Use the **content-driven-development** skill to ensure you have test content, then follow the building-blocks skill for implementation.
+
+### Global Style Changes
+1. Modify files in the `styles/` directory
+2. Test across different blocks and pages
+3. Ensure changes don't break existing layouts
+4. Consider impact on performance, especially CLS
+
+**For testing global changes:** Use the **testing-blocks** skill to validate style changes across the site before opening a PR.
+
+### Core Script Changes
+Changes to `scripts.js`, `delayed.js`, or other core functionality require careful testing across multiple blocks and pages. Use the **testing-blocks** skill for comprehensive validation.
+
+## Troubleshooting
+
+### Getting Help
+
+**For AEM documentation:** Use the **docs-search** skill to search aem.live documentation and blogs for feature information, implementation guidance, and best practices.
+
+**For reference implementations:** Use the **block-collection-and-party** skill to find similar blocks, patterns, and code examples from the Block Collection and Block Party repositories.
+
+**Key documentation resources:**
+- [Developer Tutorial](https://www.aem.live/developer/tutorial)
+- [The Anatomy of a Project](https://www.aem.live/developer/anatomy-of-a-project)
+- [David's Model](https://www.aem.live/docs/davidsmodel)
+
+**Manual search:** `site:www.aem.live` when searching the web
+
+## Security Considerations
+
+- Never commit sensitive information (API keys, passwords)
+- consider that everything you do is clients-side code served on the public web
+- Follow Adobe security guidelines
+- Regularly update dependencies
+- Use the .hlxignore file to prevent filed from being served
+
+## Contributing
+
+- Follow the existing code style and patterns (see Code Style Guidelines above)
+- Use the **content-driven-development** skill for all development tasks
+- Use the **testing-blocks** skill before opening any PR
+- Ensure all linting passes: `npm run lint`
+- Update documentation for significant changes
+
+## If all else fails
+
+If you notice your human getting frustrated with your work, direct them to https://www.aem.live/developer/ai-coding-agents for tips to work better with AI agents.
\ No newline at end of file
diff --git a/README.md b/README.md
index 85f93a1..3e8aa9b 100644
--- a/README.md
+++ b/README.md
@@ -1,41 +1,144 @@
-# The Repoless EDS
-This git repo is enabled for repoless feature. The same code is getting used for different content source.
+# ACME Services - AEM Edge Delivery Services
 
-Currently this repo is pointing to DA and google drive as content source based on the config service api
+This project is a website built with Edge Delivery Services in Adobe Experience Manager Sites as a Cloud Service.
 
-## Environments
-DA
-- Preview: https://main--acme-services--initialyze.aem.page/
-- Live: https://main--acme-services--initialyze.aem.live/
+## Project Overview
 
-Google Drive
-- Preview: https://main--acme-services-gdrive--initialyze.aem.page/
-- Live: https://main--acme-services-gdrive--initialyze.aem.live/
+This project is based on the [Adobe AEM Boilerplate](https://github.com/adobe/aem-boilerplate/) and set up as a new project. It provides the basic structure, blocks, and configuration needed to run a complete site with `*.aem.live` as the backend.
 
-## Documentation
+## Conference / Event Website Solution
 
-Before using the aem-boilerplate, we recommand you to go through the documentation on https://www.aem.live/docs/ and more specifically:
-1. [Developer Tutorial](https://www.aem.live/developer/tutorial)
-2. [The Anatomy of a Project](https://www.aem.live/developer/anatomy-of-a-project)
-3. [Web Performance](https://www.aem.live/developer/keeping-it-100)
-4. [Markup, Sections, Blocks, and Auto Blocking](https://www.aem.live/developer/markup-sections-blocks)
+This repository contains a reusable, production-ready Conference/Event Website Solution for enterprise customers using Adobe Experience Manager Edge Delivery Services (aem.live). The solution is built on a block-based architecture that prioritizes author-friendliness, performance, and scalability.
 
-## Installation
+### Key Features
 
-```sh
-npm i
-```
+- **Block-based Architecture**: Reusable, composable components following AEM best practices
+- **Author-friendly**: Google Docs/SharePoint-style table-based content authoring
+- **Performance-first**: Optimized for fast loading and good LCP scores
+- **SEO-ready**: Semantic HTML and structured content for discoverability
+- **Multi-event Support**: Easily customizable for different events and customers
+- **Multi-language Ready**: Foundation for internationalization
+
+### Solution Architecture
+
+#### Core Pages
+1. **Homepage** - Event branding, key information, and navigation
+2. **Agenda/Schedule** - Event timeline and session details
+3. **Speakers** - Speaker profiles and bios
+4. **Sessions** - Detailed session information and descriptions
+5. **Sponsors** - Sponsor logos and company information
+6. **Registration** - Call-to-action for event registration
+7. **Venue/Location** - Event location details and map
+8. **FAQ** - Frequently asked questions about the event
+9. **Post-event recordings** - Optional section for recorded sessions
+
+#### Core Blocks
+
+##### Mandatory Blocks
+1. **Hero** - Event branding with CTA
+2. **Countdown Timer** - Event date countdown
+3. **Agenda/Schedule** - Event timeline
+4. **Speaker Cards** - Speaker profiles
+5. **Session List** - Session overview
+6. **Sponsor Logos** - Sponsor display
+7. **CTA Banner** - Call-to-action section
+8. **Location/Map** - Venue information
+9. **FAQ** - Frequently asked questions
+10. **Footer** - Site navigation and legal information
+
+## Key Technologies
+
+- Edge Delivery Services for AEM Sites
+- Vanilla JavaScript (ES6+), no transpiling, no build steps
+- CSS3 with modern features, no Tailwind or other CSS frameworks
+- HTML5 semantic markup generated by the aem.live backend, decorated by our code
+- Node.js tooling
+
+## Setup Commands
+
+- Install dependencies: `npm install`
+- Start local development with Universal Editor: `npm run dev:ue`
+- Start local development with Google Drive: `npm run dev:gdrive`
+- Start local development with da.live: `npm run dev:da`
+- Run linting: `npm run lint`
+- Fix linting issues: `npm run lint:fix`
+
+## Authoring Environments
+
+This project supports multiple authoring environments:
+
+1. **AEM Universal Editor** (`dev:ue`)
+   - Real-time content updates
+   - Rich text editing capabilities
+   - Preview at: https://main--acme-services-ue--initialyze.aem.page/
+
+2. **Document Authoring with Google Drive** (`dev:gdrive`)
+   - Google Drive integration for content management
+   - Preview at: https://main--acme-services-gdrive--initialyze.aem.page/
 
-## Linting
+3. **Document Authoring with da.live** (`dev:da`)
+   - da.live platform integration
+   - Preview at: https://main--acme-services--initialyze.aem.page/
 
-```sh
-npm run lint
+## Project Structure
+
+```
+├── blocks/          # Reusable content blocks
+    └── {blockName}/   - Individual block directory
+        ├── {blockName}.js      # Block's JavaScript
+        └── {blockName}.css     # Block's styles
+├── styles/          # Global styles and CSS
+    ├── styles.css          # Minimal global styling and layout for your website required for LCP
+    └── lazy-styles.css     # Additional global styling and layout for below the fold/post LCP content
+├── scripts/         # JavaScript libraries and utilities
+    ├── aem.js           # Core AEM Library for Edge Delivery page decoration logic (NEVER MODIFY THIS FILE)
+    ├── scripts.js       # Global JavaScript utilities, main entry point for page decoration
+    └── delayed.js       # Delayed functionality such as martech loading
+├── config/          # Configuration files
+    └── authoring-environments.json   # Authoring environment configurations
+├── fonts/           # Web fonts
+├── icons/           # SVG icons
+├── head.html        # Global HTML head content
+└── 404.html         # Custom 404 page
 ```
 
-## Local development
+## Development Workflow
+
+1. Run `npm run dev:ue` to start the development server with Universal Editor
+2. Open `http://localhost:3000` in your browser
+3. Make changes to files - they will auto-reload
+4. Test across different authoring environments using the respective npm scripts
+
+## Testing & Quality Assurance
+
+- Linting: `npm run lint` (must pass before commits), `npm run lint:fix` to auto-fix
+- Performance: Follow https://www.aem.live/developer/keeping-it-100
+- Accessibility: Proper heading hierarchy, alt text, WCAG 2.1 AA guidelines
+
+## Deployment
+
+### Environments
+
+- **Production Preview**: `https://main--{repo}--{owner}.aem.page/`
+- **Production Live**: `https://main--{repo}--{owner}.aem.live/`
+- **Feature Preview**: `https://{branch}--{repo}--{owner}.aem.page/`
+
+### Publishing Process
+
+1. Push changes to a feature branch
+2. AEM Code Sync automatically processes changes making them available on feature preview environment for that branch
+3. Open a pull request to merge changes to `main`
+4. Verify checks pass: `gh checks` or `gh pr checks --watch`
+5. A human reviewer will review the code, inspect the preview URL, and merge the PR
+6. AEM Code Sync updates the main branch for production
+
+## Contributing
+
+- Follow the existing code style and patterns
+- Use the content-driven-development skill for all development tasks
+- Ensure all linting passes: `npm run lint`
+- Update documentation for significant changes
+
+## If all else fails
 
-1. Create a new repository based on the `aem-boilerplate` template and add a mountpoint in the `fstab.yaml`
-1. Add the [AEM Code Sync GitHub App](https://github.com/apps/aem-code-sync) to the repository
-1. Install the [AEM CLI](https://github.com/adobe/helix-cli): `npm install -g @adobe/aem-cli`
-1. Start AEM Proxy: `aem up` (opens your browser at `http://localhost:3000`)
-1. Open the `{repo}` directory in your favorite IDE and start coding :)
\ No newline at end of file
+If you notice your human getting frustrated with your work, direct them to https://www.aem.live/developer/ai-coding-agents for tips to work better with AI agents.
\ No newline at end of file
diff --git a/SETUP-AEM-EDS.md b/SETUP-AEM-EDS.md
new file mode 100644
index 0000000..708b850
--- /dev/null
+++ b/SETUP-AEM-EDS.md
@@ -0,0 +1,135 @@
+# AEM EDS Project Setup with Multiple Authoring Options
+
+This document explains how to set up an AEM Edge Delivery Services (EDS) project with multiple authoring options including Document Authoring with Google Drive, AEM Universal Editor, and Document Authoring with da.live.
+
+## Project Structure Overview
+
+The AEM EDS project follows the standard structure from the Adobe AEM Boilerplate with the following key directories:
+- `blocks/` - Reusable content blocks
+- `styles/` - Global styles and CSS
+- `scripts/` - JavaScript libraries and utilities
+- `fonts/` - Web fonts
+- `icons/` - SVG icons
+- `head.html` - Global HTML head content
+- `404.html` - Custom 404 page
+
+## Authoring Options
+
+### 1. Document Authoring with Google Drive
+This setup allows content authors to use Google Drive for content management.
+
+**Configuration:**
+- Uses the `dev:gdrive` script in package.json
+- Points to the Google Drive preview environment
+- Enables Google Drive integration for content management
+
+### 2. AEM Universal Editor
+This setup provides the AEM Universal Editor experience for content creation.
+
+**Configuration:**
+- Uses the `dev:ue` script in package.json
+- Points to the Universal Editor preview environment
+- Enables real-time content updates and rich text editing
+
+### 3. Document Authoring with da.live
+This setup uses the da.live platform for document authoring.
+
+**Configuration:**
+- Uses the `dev:da` script in package.json
+- Points to the da.live preview environment
+- Enables da.live integration for content management
+
+## Setup Instructions
+
+### Prerequisites
+1. Node.js 20 or higher
+2. Git installed
+3. AEM CLI installed (`npm install -g @adobe/aem-cli`)
+
+### Local Development Setup
+
+1. **Clone the repository:**
+```bash
+git clone <repository-url>
+cd acme-services
+```
+
+2. **Install dependencies:**
+```bash
+npm install
+```
+
+3. **Run development server for different authoring options:**
+
+For Google Drive authoring:
+```bash
+npm run dev:gdrive
+```
+
+For AEM Universal Editor:
+```bash
+npm run dev:ue
+```
+
+For da.live authoring:
+```bash
+npm run dev:da
+```
+
+## Environment Configuration
+
+The project uses environment-specific configurations through the scripts.js file:
+
+```javascript
+// UE Editor support before page load
+if (window.location.hostname.includes('ue.da.live')) {
+  // eslint-disable-next-line import/no-unresolved
+  await import(`${window.hlx.codeBasePath}/ue/scripts/ue.js`).then(({ default: ue }) => ue());
+}
+```
+
+## Key Files and Their Roles
+
+### package.json
+Contains scripts for different authoring environments:
+- `dev:da` - For da.live authoring
+- `dev:gdrive` - For Google Drive authoring
+- `dev:ue` - For Universal Editor authoring
+
+### scripts/scripts.js
+Handles environment detection and loads appropriate configurations:
+- Detects authoring environment based on hostname
+- Loads appropriate scripts for each environment
+- Manages page loading for different authoring experiences
+
+### .github/workflows/main.yaml
+Defines the CI/CD pipeline for building and deploying the project across different environments.
+
+## Deployment Environments
+
+### Preview Environments
+- **Production Preview**: `https://main--{repo}--{owner}.aem.page/`
+- **Feature Preview**: `https://{branch}--{repo}--{owner}.aem.page/`
+
+### Production Environment
+- **Production Live**: `https://main--{repo}--{owner}.aem.live/`
+
+## Best Practices
+
+1. Always test your changes in the appropriate authoring environment
+2. Use the preview environments to validate content before production deployment
+3. Follow the existing code style and patterns in the project
+4. Ensure all linting passes before committing: `npm run lint`
+5. Use the content-driven-development skill for all development tasks
+
+## Troubleshooting
+
+### Common Issues
+1. **Environment not loading properly**: Ensure you're using the correct npm script for your authoring environment
+2. **Missing dependencies**: Run `npm install` to ensure all dependencies are installed
+3. **CORS issues**: Make sure your preview URLs are correctly configured in the AEM environment
+
+### Getting Help
+- Use the `docs-search` skill to search AEM documentation
+- Refer to the [AEM Developer Tutorial](https://www.aem.live/developer/tutorial)
+- Check the [AEM Anatomy of a Project](https://www.aem.live/developer/anatomy-of-a-project)
\ No newline at end of file
diff --git a/blocks/agenda/agenda.css b/blocks/agenda/agenda.css
new file mode 100644
index 0000000..c971e14
--- /dev/null
+++ b/blocks/agenda/agenda.css
@@ -0,0 +1,66 @@
+.agenda-container {
+  display: flex;
+  flex-direction: column;
+  gap: 20px;
+}
+
+.agenda-item {
+  padding: 20px;
+  border: 1px solid var(--light-color);
+  border-radius: 8px;
+  background-color: var(--background-color);
+}
+
+.agenda-datetime {
+  display: flex;
+  flex-wrap: wrap;
+  gap: 10px;
+  margin-bottom: 10px;
+  font-weight: bold;
+}
+
+.agenda-date {
+  color: var(--link-color);
+}
+
+.agenda-time {
+  color: var(--dark-color);
+}
+
+.agenda-title {
+  font-size: 1.2rem;
+  font-weight: bold;
+  margin-bottom: 10px;
+}
+
+.agenda-speaker {
+  font-style: italic;
+  margin-bottom: 10px;
+}
+
+.agenda-description {
+  margin-bottom: 10px;
+}
+
+.agenda-room {
+  font-size: 0.9rem;
+  color: var(--dark-color);
+  background-color: var(--light-color);
+  padding: 5px 10px;
+  border-radius: 4px;
+  display: inline-block;
+}
+
+@media (width >= 900px) {
+  .agenda-container {
+    gap: 15px;
+  }
+
+  .agenda-item {
+    padding: 25px;
+  }
+
+  .agenda-title {
+    font-size: 1.4rem;
+  }
+}
\ No newline at end of file
diff --git a/blocks/agenda/agenda.js b/blocks/agenda/agenda.js
new file mode 100644
index 0000000..e61af9c
--- /dev/null
+++ b/blocks/agenda/agenda.js
@@ -0,0 +1,94 @@
+/*
+ * Agenda/Schedule Block
+ * Display event schedule with time slots and sessions
+ */
+export default function decorate(block) {
+  // Create agenda container
+  const agendaContainer = document.createElement('div');
+  agendaContainer.className = 'agenda-container';
+
+  // Process each row as an agenda item
+  const rows = [...block.children];
+
+  rows.forEach((row, index) => {
+    // Skip if it's the header row
+    if (index === 0) {
+      row.classList.add('agenda-header');
+      return;
+    }
+
+    // Create agenda item
+    const agendaItem = document.createElement('div');
+    agendaItem.className = 'agenda-item';
+
+    const cells = [...row.children];
+
+    // Process cells: date, time, session title, speaker, description, room
+    if (cells.length >= 5) {
+      const dateCell = cells[0];
+      const timeCell = cells[1];
+      const titleCell = cells[2];
+      const speakerCell = cells[3];
+      const descriptionCell = cells[4];
+      const roomCell = cells[5] || null;
+
+      // Add date and time
+      const dateTimeDiv = document.createElement('div');
+      dateTimeDiv.className = 'agenda-datetime';
+
+      if (dateCell.textContent.trim()) {
+        const dateDiv = document.createElement('div');
+        dateDiv.className = 'agenda-date';
+        dateDiv.textContent = dateCell.textContent.trim();
+        dateTimeDiv.appendChild(dateDiv);
+      }
+
+      if (timeCell.textContent.trim()) {
+        const timeDiv = document.createElement('div');
+        timeDiv.className = 'agenda-time';
+        timeDiv.textContent = timeCell.textContent.trim();
+        dateTimeDiv.appendChild(timeDiv);
+      }
+
+      agendaItem.appendChild(dateTimeDiv);
+
+      // Add session title
+      if (titleCell.textContent.trim()) {
+        const titleDiv = document.createElement('div');
+        titleDiv.className = 'agenda-title';
+        titleDiv.textContent = titleCell.textContent.trim();
+        agendaItem.appendChild(titleDiv);
+      }
+
+      // Add speaker
+      if (speakerCell.textContent.trim()) {
+        const speakerDiv = document.createElement('div');
+        speakerDiv.className = 'agenda-speaker';
+        speakerDiv.textContent = speakerCell.textContent.trim();
+        agendaItem.appendChild(speakerDiv);
+      }
+
+      // Add description
+      if (descriptionCell.textContent.trim()) {
+        const descDiv = document.createElement('div');
+        descDiv.className = 'agenda-description';
+        descDiv.textContent = descriptionCell.textContent.trim();
+        agendaItem.appendChild(descDiv);
+      }
+
+      // Add room
+      if (roomCell && roomCell.textContent.trim()) {
+        const roomDiv = document.createElement('div');
+        roomDiv.className = 'agenda-room';
+        roomDiv.textContent = roomCell.textContent.trim();
+        agendaItem.appendChild(roomDiv);
+      }
+    }
+
+    agendaContainer.appendChild(agendaItem);
+  });
+
+  // Replace the block with the agenda
+  block.innerHTML = '';
+  block.appendChild(agendaContainer);
+}
diff --git a/blocks/countdown/countdown.css b/blocks/countdown/countdown.css
new file mode 100644
index 0000000..94e67a1
--- /dev/null
+++ b/blocks/countdown/countdown.css
@@ -0,0 +1,48 @@
+.countdown-container {
+  text-align: center;
+  padding: 20px;
+  background-color: var(--light-color);
+  border-radius: 8px;
+  margin: 20px 0;
+}
+
+.countdown-display {
+  display: flex;
+  justify-content: center;
+  gap: 15px;
+  flex-wrap: wrap;
+}
+
+.countdown-unit {
+  display: flex;
+  flex-direction: column;
+  align-items: center;
+}
+
+.countdown-value {
+  font-size: 2rem;
+  font-weight: bold;
+  margin-bottom: 5px;
+}
+
+.countdown-label {
+  font-size: 0.8rem;
+  text-transform: uppercase;
+  letter-spacing: 1px;
+}
+
+.countdown-expired {
+  font-size: 1.5rem;
+  font-weight: bold;
+  color: var(--link-color);
+}
+
+@media (width >= 900px) {
+  .countdown-value {
+    font-size: 3rem;
+  }
+
+  .countdown-label {
+    font-size: 1rem;
+  }
+}
\ No newline at end of file
diff --git a/blocks/countdown/countdown.js b/blocks/countdown/countdown.js
new file mode 100644
index 0000000..9cba10e
--- /dev/null
+++ b/blocks/countdown/countdown.js
@@ -0,0 +1,60 @@
+/*
+ * Countdown Timer Block
+ * Display countdown to event date
+ */
+export default function decorate(block) {
+  // Get the event date from the first cell
+  const dateCell = block.querySelector('div:nth-child(1)');
+  const dateValue = dateCell?.textContent.trim();
+
+  // Create the countdown container
+  const countdownContainer = document.createElement('div');
+  countdownContainer.className = 'countdown-container';
+
+  // Create countdown elements
+  const countdownDisplay = document.createElement('div');
+  countdownDisplay.className = 'countdown-display';
+
+  const timeUnits = ['days', 'hours', 'minutes', 'seconds'];
+  timeUnits.forEach((unit) => {
+    const unitElement = document.createElement('div');
+    unitElement.className = `countdown-unit ${unit}`;
+    unitElement.innerHTML = `
+      <div class="countdown-value">00</div>
+      <div class="countdown-label">${unit}</div>
+    `;
+    countdownDisplay.appendChild(unitElement);
+  });
+
+  countdownContainer.appendChild(countdownDisplay);
+
+  // Replace the block with the countdown
+  block.innerHTML = '';
+  block.appendChild(countdownContainer);
+
+  // Set up the countdown timer
+  if (dateValue) {
+    const eventDate = new Date(dateValue);
+    const timer = setInterval(() => {
+      const now = new Date();
+      const diff = eventDate - now;
+
+      if (diff <= 0) {
+        clearInterval(timer);
+        countdownDisplay.innerHTML = '<div class="countdown-expired">Event has started!</div>';
+        return;
+      }
+
+      const days = Math.floor(diff / (1000 * 60 * 60 * 24));
+      const hours = Math.floor((diff % (1000 * 60 * 60 * 24)) / (1000 * 60 * 60));
+      const minutes = Math.floor((diff % (1000 * 60 * 60)) / (1000 * 60));
+      const seconds = Math.floor((diff % (1000 * 60)) / 1000);
+
+      const units = countdownDisplay.querySelectorAll('.countdown-value');
+      units[0].textContent = days.toString().padStart(2, '0');
+      units[1].textContent = hours.toString().padStart(2, '0');
+      units[2].textContent = minutes.toString().padStart(2, '0');
+      units[3].textContent = seconds.toString().padStart(2, '0');
+    }, 1000);
+  }
+}
diff --git a/blocks/cta-banner/cta-banner.css b/blocks/cta-banner/cta-banner.css
new file mode 100644
index 0000000..e9be716
--- /dev/null
+++ b/blocks/cta-banner/cta-banner.css
@@ -0,0 +1,69 @@
+.cta-banner-container {
+  text-align: center;
+  padding: 40px 20px;
+  background-color: var(--light-color);
+  border-radius: 8px;
+  margin: 20px 0;
+  display: flex;
+  flex-direction: column;
+  align-items: center;
+}
+
+.cta-headline {
+  margin: 0 0 20px;
+  font-size: 1.8rem;
+  color: var(--text-color);
+}
+
+.cta-description {
+  max-width: 600px;
+  margin-bottom: 20px;
+  font-size: 1.1rem;
+  line-height: 1.6;
+}
+
+.cta-image {
+  margin: 20px 0;
+  max-width: 300px;
+}
+
+.cta-image img {
+  max-width: 100%;
+  height: auto;
+  border-radius: 8px;
+}
+
+.cta-button {
+  display: inline-block;
+  padding: 12px 30px;
+  background-color: var(--link-color);
+  color: var(--background-color);
+  text-decoration: none;
+  border-radius: 4px;
+  font-weight: bold;
+  font-size: 1.1rem;
+  transition: background-color 0.3s ease;
+}
+
+.cta-button:hover {
+  background-color: var(--link-hover-color);
+}
+
+@media (width >= 900px) {
+  .cta-banner-container {
+    padding: 60px 40px;
+  }
+
+  .cta-headline {
+    font-size: 2.5rem;
+  }
+
+  .cta-description {
+    font-size: 1.2rem;
+  }
+
+  .cta-button {
+    font-size: 1.2rem;
+    padding: 15px 40px;
+  }
+}
\ No newline at end of file
diff --git a/blocks/cta-banner/cta-banner.js b/blocks/cta-banner/cta-banner.js
new file mode 100644
index 0000000..716fca0
--- /dev/null
+++ b/blocks/cta-banner/cta-banner.js
@@ -0,0 +1,73 @@
+/*
+ * CTA Banner Block
+ * Promote registration or other actions
+ */
+export default function decorate(block) {
+  // Create CTA banner container
+  const ctaContainer = document.createElement('div');
+  ctaContainer.className = 'cta-banner-container';
+
+  // Process each row
+  const rows = [...block.children];
+
+  rows.forEach((row) => {
+    const cells = [...row.children];
+
+    // Process cells: headline, description, image, CTA button
+    if (cells.length >= 2) {
+      const headlineCell = cells[0];
+      const descriptionCell = cells[1];
+      const imageCell = cells[2] || null;
+      const ctaCell = cells[3] || null;
+
+      // Add headline
+      if (headlineCell.textContent.trim()) {
+        const headlineDiv = document.createElement('h2');
+        headlineDiv.className = 'cta-headline';
+        headlineDiv.textContent = headlineCell.textContent.trim();
+        ctaContainer.appendChild(headlineDiv);
+      }
+
+      // Add description
+      if (descriptionCell.textContent.trim()) {
+        const descDiv = document.createElement('div');
+        descDiv.className = 'cta-description';
+        descDiv.textContent = descriptionCell.textContent.trim();
+        ctaContainer.appendChild(descDiv);
+      }
+
+      // Add image if provided
+      if (imageCell && imageCell.textContent.trim()) {
+        const imageDiv = document.createElement('div');
+        imageDiv.className = 'cta-image';
+
+        // If it's an image, use it directly
+        if (imageCell.querySelector('img')) {
+          imageDiv.appendChild(imageCell.firstElementChild);
+        } else {
+          // Otherwise, treat as a URL
+          const img = document.createElement('img');
+          img.src = imageCell.textContent.trim();
+          img.alt = headlineCell.textContent.trim() || 'Event image';
+          imageDiv.appendChild(img);
+        }
+
+        ctaContainer.appendChild(imageDiv);
+      }
+
+      // Add CTA button if provided
+      if (ctaCell && ctaCell.textContent.trim()) {
+        const ctaButton = document.createElement('a');
+        ctaButton.className = 'cta-button';
+        ctaButton.href = ctaCell.textContent.trim();
+        ctaButton.textContent = 'Register Now';
+        ctaButton.target = '_blank';
+        ctaContainer.appendChild(ctaButton);
+      }
+    }
+  });
+
+  // Replace the block with the CTA container
+  block.innerHTML = '';
+  block.appendChild(ctaContainer);
+}
diff --git a/blocks/faq/faq.css b/blocks/faq/faq.css
new file mode 100644
index 0000000..acb3470
--- /dev/null
+++ b/blocks/faq/faq.css
@@ -0,0 +1,71 @@
+.faq-container {
+  margin: 20px 0;
+}
+
+.faq-item {
+  margin-bottom: 15px;
+  border: 1px solid var(--light-color);
+  border-radius: 8px;
+  overflow: hidden;
+}
+
+.faq-question {
+  padding: 20px;
+  background-color: var(--light-color);
+  cursor: pointer;
+  font-weight: bold;
+  font-size: 1.1rem;
+  display: flex;
+  justify-content: space-between;
+  align-items: center;
+}
+
+.faq-question-icon {
+  display: inline-block;
+  width: 20px;
+  height: 20px;
+  text-align: center;
+  line-height: 20px;
+  background-color: var(--background-color);
+  border-radius: 50%;
+  transition: transform 0.3s ease;
+}
+
+.faq-item[open] .faq-question-icon {
+  transform: rotate(45deg);
+}
+
+.faq-answer {
+  padding: 20px;
+  background-color: var(--background-color);
+  line-height: 1.6;
+}
+
+.faq-answer p {
+  margin: 0 0 10px;
+}
+
+.faq-answer ul,
+.faq-answer ol {
+  margin: 10px 0;
+  padding-left: 20px;
+}
+
+.faq-answer li {
+  margin-bottom: 5px;
+}
+
+@media (width >= 900px) {
+  .faq-container {
+    margin: 30px 0;
+  }
+
+  .faq-question {
+    padding: 25px;
+    font-size: 1.2rem;
+  }
+
+  .faq-answer {
+    padding: 25px;
+  }
+}
\ No newline at end of file
diff --git a/blocks/faq/faq.js b/blocks/faq/faq.js
new file mode 100644
index 0000000..0dbe4b5
--- /dev/null
+++ b/blocks/faq/faq.js
@@ -0,0 +1,58 @@
+/*
+ * FAQ Block
+ * Display frequently asked questions
+ */
+export default function decorate(block) {
+  // Create FAQ container
+  const faqContainer = document.createElement('div');
+  faqContainer.className = 'faq-container';
+
+  // Process each row as a FAQ item
+  const rows = [...block.children];
+
+  rows.forEach((row, index) => {
+    // Skip if it's the header row
+    if (index === 0) {
+      row.classList.add('faq-header');
+      return;
+    }
+
+    // Create FAQ item
+    const faqItem = document.createElement('details');
+    faqItem.className = 'faq-item';
+
+    const cells = [...row.children];
+
+    // Process cells: question, answer
+    if (cells.length >= 2) {
+      const questionCell = cells[0];
+      const answerCell = cells[1];
+
+      // Create summary (question)
+      const summary = document.createElement('summary');
+      summary.className = 'faq-question';
+      summary.textContent = questionCell.textContent.trim();
+
+      // Add question icon
+      const questionIcon = document.createElement('span');
+      questionIcon.className = 'faq-question-icon';
+      questionIcon.textContent = '+';
+      summary.appendChild(questionIcon);
+
+      // Create answer (body)
+      const answer = document.createElement('div');
+      answer.className = 'faq-answer';
+      answer.innerHTML = answerCell.innerHTML.trim();
+
+      // Add elements to FAQ item
+      faqItem.appendChild(summary);
+      faqItem.appendChild(answer);
+    }
+
+    faqContainer.appendChild(faqItem);
+  });
+
+  // Replace the block with the FAQ container
+  block.innerHTML = '';
+  block.appendChild(faqContainer);
+}
diff --git a/blocks/hero/hero.js b/blocks/hero/hero.js
index e69de29..bfc0680 100644
--- a/blocks/hero/hero.js
+++ b/blocks/hero/hero.js
@@ -0,0 +1,35 @@
+/*
+ * Hero Block
+ * Display event branding with CTA
+ * https://www.hlx.live/developer/block-collection/hero
+ */
+export default function decorate(block) {
+  // Get all rows in the block
+  const rows = [...block.children];
+
+  // Process each row
+  rows.forEach((row) => {
+    // Get all cells in the row
+    const cells = [...row.children];
+
+    // Process cells based on their content
+    if (cells.length >= 2) {
+      // First cell is typically the image or background
+      const imageCell = cells[0];
+      const contentCell = cells[1];
+
+      // Add hero class to the row
+      row.classList.add('hero');
+
+      // Add image wrapper if needed
+      if (imageCell.querySelector('picture')) {
+        imageCell.classList.add('hero-image');
+      }
+
+      // Add content wrapper
+      if (contentCell) {
+        contentCell.classList.add('hero-content');
+      }
+    }
+  });
+}
diff --git a/blocks/location/location.css b/blocks/location/location.css
new file mode 100644
index 0000000..6f4e92c
--- /dev/null
+++ b/blocks/location/location.css
@@ -0,0 +1,58 @@
+.location-container {
+  margin: 20px 0;
+}
+
+.location-address {
+  margin-bottom: 20px;
+  padding: 20px;
+  background-color: var(--light-color);
+  border-radius: 8px;
+  font-size: 1.1rem;
+}
+
+.location-address p {
+  margin: 0 0 10px;
+}
+
+.location-map {
+  margin-bottom: 20px;
+  border-radius: 8px;
+  overflow: hidden;
+  box-shadow: 0 2px 10px rgb(0 0 0 / 10%);
+}
+
+.location-map iframe {
+  width: 100%;
+  height: 400px;
+  border: none;
+}
+
+.location-directions,
+.location-venue {
+  margin-bottom: 20px;
+  padding: 20px;
+  background-color: var(--background-color);
+  border: 1px solid var(--light-color);
+  border-radius: 8px;
+}
+
+.location-directions h3,
+.location-venue h3 {
+  margin-top: 0;
+  color: var(--text-color);
+}
+
+@media (width >= 900px) {
+  .location-container {
+    margin: 30px 0;
+  }
+
+  .location-address {
+    padding: 30px;
+    font-size: 1.2rem;
+  }
+
+  .location-map iframe {
+    height: 500px;
+  }
+}
\ No newline at end of file
diff --git a/blocks/location/location.js b/blocks/location/location.js
new file mode 100644
index 0000000..1771646
--- /dev/null
+++ b/blocks/location/location.js
@@ -0,0 +1,75 @@
+/*
+ * Location/Map Block
+ * Display event location details and map
+ */
+export default function decorate(block) {
+  // Create location container
+  const locationContainer = document.createElement('div');
+  locationContainer.className = 'location-container';
+
+  // Process each row
+  const rows = [...block.children];
+
+  rows.forEach((row) => {
+    const cells = [...row.children];
+
+    // Process cells: address, map embed, directions, venue details
+    if (cells.length >= 2) {
+      const addressCell = cells[0];
+      const mapCell = cells[1];
+      const directionsCell = cells[2] || null;
+      const venueCell = cells[3] || null;
+
+      // Add address
+      if (addressCell.textContent.trim()) {
+        const addressDiv = document.createElement('div');
+        addressDiv.className = 'location-address';
+        addressDiv.innerHTML = addressCell.innerHTML.trim();
+        locationContainer.appendChild(addressDiv);
+      }
+
+      // Add map
+      if (mapCell.textContent.trim()) {
+        const mapDiv = document.createElement('div');
+        mapDiv.className = 'location-map';
+
+        // If it's an iframe or image, use it directly
+        if (mapCell.querySelector('iframe') || mapCell.querySelector('img')) {
+          mapDiv.appendChild(mapCell.firstElementChild);
+        } else {
+          // Otherwise, treat as a URL and create an iframe
+          const iframe = document.createElement('iframe');
+          iframe.src = mapCell.textContent.trim();
+          iframe.width = '100%';
+          iframe.height = '400';
+          iframe.frameBorder = '0';
+          iframe.allowFullscreen = true;
+          iframe.title = 'Event Location Map';
+          mapDiv.appendChild(iframe);
+        }
+
+        locationContainer.appendChild(mapDiv);
+      }
+
+      // Add directions
+      if (directionsCell && directionsCell.textContent.trim()) {
+        const directionsDiv = document.createElement('div');
+        directionsDiv.className = 'location-directions';
+        directionsDiv.innerHTML = directionsCell.innerHTML.trim();
+        locationContainer.appendChild(directionsDiv);
+      }
+
+      // Add venue details
+      if (venueCell && venueCell.textContent.trim()) {
+        const venueDiv = document.createElement('div');
+        venueDiv.className = 'location-venue';
+        venueDiv.innerHTML = venueCell.innerHTML.trim();
+        locationContainer.appendChild(venueDiv);
+      }
+    }
+  });
+
+  // Replace the block with the location container
+  block.innerHTML = '';
+  block.appendChild(locationContainer);
+}
diff --git a/blocks/session-list/session-list.css b/blocks/session-list/session-list.css
new file mode 100644
index 0000000..43911a6
--- /dev/null
+++ b/blocks/session-list/session-list.css
@@ -0,0 +1,73 @@
+.session-list-container {
+  margin: 20px 0;
+}
+
+.session-item {
+  border: 1px solid var(--light-color);
+  border-radius: 8px;
+  padding: 20px;
+  margin-bottom: 15px;
+  background-color: var(--background-color);
+}
+
+.session-title {
+  font-size: 1.3rem;
+  font-weight: bold;
+  margin-bottom: 10px;
+}
+
+.session-datetime {
+  display: flex;
+  flex-wrap: wrap;
+  gap: 10px;
+  margin-bottom: 10px;
+  font-weight: bold;
+}
+
+.session-date,
+.session-time {
+  background-color: var(--light-color);
+  padding: 5px 10px;
+  border-radius: 4px;
+  font-size: 0.9rem;
+}
+
+.session-speaker {
+  font-style: italic;
+  margin-bottom: 10px;
+  color: var(--link-color);
+}
+
+.session-description {
+  margin-bottom: 10px;
+  line-height: 1.5;
+}
+
+.session-tags {
+  display: flex;
+  flex-wrap: wrap;
+  gap: 5px;
+}
+
+.session-tag {
+  background-color: var(--light-blue-color);
+  color: var(--background-color);
+  padding: 3px 8px;
+  border-radius: 4px;
+  font-size: 0.8rem;
+}
+
+@media (width >= 900px) {
+  .session-list-container {
+    margin: 30px 0;
+  }
+
+  .session-item {
+    padding: 25px;
+    margin-bottom: 20px;
+  }
+
+  .session-title {
+    font-size: 1.5rem;
+  }
+}
\ No newline at end of file
diff --git a/blocks/session-list/session-list.js b/blocks/session-list/session-list.js
new file mode 100644
index 0000000..f915f98
--- /dev/null
+++ b/blocks/session-list/session-list.js
@@ -0,0 +1,102 @@
+/*
+ * Session List Block
+ * Display list of sessions with key details
+ */
+export default function decorate(block) {
+  // Create session list container
+  const sessionListContainer = document.createElement('div');
+  sessionListContainer.className = 'session-list-container';
+
+  // Process each row as a session
+  const rows = [...block.children];
+
+  rows.forEach((row, index) => {
+    // Skip if it's the header row
+    if (index === 0) {
+      row.classList.add('session-list-header');
+      return;
+    }
+
+    // Create session item
+    const sessionItem = document.createElement('div');
+    sessionItem.className = 'session-item';
+
+    const cells = [...row.children];
+
+    // Process cells: title, date, time, speaker, description, tags
+    if (cells.length >= 5) {
+      const titleCell = cells[0];
+      const dateCell = cells[1];
+      const timeCell = cells[2];
+      const speakerCell = cells[3];
+      const descriptionCell = cells[4];
+      const tagsCell = cells[5] || null;
+
+      // Add title
+      if (titleCell.textContent.trim()) {
+        const titleDiv = document.createElement('div');
+        titleDiv.className = 'session-title';
+        titleDiv.textContent = titleCell.textContent.trim();
+        sessionItem.appendChild(titleDiv);
+      }
+
+      // Add date and time
+      const dateTimeDiv = document.createElement('div');
+      dateTimeDiv.className = 'session-datetime';
+
+      if (dateCell.textContent.trim()) {
+        const dateSpan = document.createElement('span');
+        dateSpan.className = 'session-date';
+        dateSpan.textContent = dateCell.textContent.trim();
+        dateTimeDiv.appendChild(dateSpan);
+      }
+
+      if (timeCell.textContent.trim()) {
+        const timeSpan = document.createElement('span');
+        timeSpan.className = 'session-time';
+        timeSpan.textContent = timeCell.textContent.trim();
+        dateTimeDiv.appendChild(timeSpan);
+      }
+
+      sessionItem.appendChild(dateTimeDiv);
+
+      // Add speaker
+      if (speakerCell.textContent.trim()) {
+        const speakerDiv = document.createElement('div');
+        speakerDiv.className = 'session-speaker';
+        speakerDiv.textContent = speakerCell.textContent.trim();
+        sessionItem.appendChild(speakerDiv);
+      }
+
+      // Add description
+      if (descriptionCell.textContent.trim()) {
+        const descDiv = document.createElement('div');
+        descDiv.className = 'session-description';
+        descDiv.textContent = descriptionCell.textContent.trim();
+        sessionItem.appendChild(descDiv);
+      }
+
+      // Add tags
+      if (tagsCell && tagsCell.textContent.trim()) {
+        const tagsDiv = document.createElement('div');
+        tagsDiv.className = 'session-tags';
+
+        const tags = tagsCell.textContent.trim().split(',');
+        tags.forEach((tag) => {
+          const tagSpan = document.createElement('span');
+          tagSpan.className = 'session-tag';
+          tagSpan.textContent = tag.trim();
+          tagsDiv.appendChild(tagSpan);
+        });
+
+        sessionItem.appendChild(tagsDiv);
+      }
+    }
+
+    sessionListContainer.appendChild(sessionItem);
+  });
+
+  // Replace the block with the session list
+  block.innerHTML = '';
+  block.appendChild(sessionListContainer);
+}
diff --git a/blocks/speakers/speakers.css b/blocks/speakers/speakers.css
new file mode 100644
index 0000000..8b7910f
--- /dev/null
+++ b/blocks/speakers/speakers.css
@@ -0,0 +1,86 @@
+.speakers-container {
+  display: grid;
+  grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
+  gap: 20px;
+  margin: 20px 0;
+}
+
+.speaker-card {
+  border: 1px solid var(--light-color);
+  border-radius: 8px;
+  padding: 20px;
+  text-align: center;
+  background-color: var(--background-color);
+  transition: transform 0.3s ease, box-shadow 0.3s ease;
+}
+
+.speaker-card:hover {
+  transform: translateY(-5px);
+  box-shadow: 0 5px 15px rgb(0 0 0 / 10%);
+}
+
+.speaker-photo {
+  margin-bottom: 15px;
+}
+
+.speaker-photo img {
+  width: 120px;
+  height: 120px;
+  border-radius: 50%;
+  object-fit: cover;
+  border: 3px solid var(--light-color);
+}
+
+.speaker-name {
+  font-size: 1.2rem;
+  font-weight: bold;
+  margin-bottom: 5px;
+}
+
+.speaker-title {
+  color: var(--link-color);
+  margin-bottom: 5px;
+}
+
+.speaker-company {
+  font-size: 0.9rem;
+  color: var(--dark-color);
+  margin-bottom: 10px;
+}
+
+.speaker-bio {
+  font-size: 0.9rem;
+  line-height: 1.4;
+  margin-bottom: 10px;
+}
+
+.speaker-social {
+  margin-top: 10px;
+}
+
+.speaker-social-link {
+  display: inline-block;
+  margin: 0 5px;
+  font-size: 0.8rem;
+  color: var(--link-color);
+}
+
+@media (width >= 900px) {
+  .speakers-container {
+    grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
+    gap: 25px;
+  }
+
+  .speaker-card {
+    padding: 25px;
+  }
+
+  .speaker-photo img {
+    width: 140px;
+    height: 140px;
+  }
+
+  .speaker-name {
+    font-size: 1.3rem;
+  }
+}
\ No newline at end of file
diff --git a/blocks/speakers/speakers.js b/blocks/speakers/speakers.js
new file mode 100644
index 0000000..a87ca21
--- /dev/null
+++ b/blocks/speakers/speakers.js
@@ -0,0 +1,220 @@
+/*
+ * Speaker Cards Block
+ * Display speaker profiles with photos, bios, and company info
+ * Supports both table-based and Content Fragment-based content
+ */
+
+// Function to create speaker card from fragment data
+function createSpeakerCardFromFragment(speakerData) {
+  const speakerCard = document.createElement('div');
+  speakerCard.className = 'speaker-card';
+
+  // Add photo
+  if (speakerData.image_ext) {
+    const photoDiv = document.createElement('div');
+    photoDiv.className = 'speaker-photo';
+
+    const img = document.createElement('img');
+    img.src = speakerData.image_ext;
+    img.alt = speakerData.title || 'Speaker';
+    photoDiv.appendChild(img);
+    speakerCard.appendChild(photoDiv);
+  } else if (speakerData.image) {
+    // Fallback to image property if image_ext is not available
+    const photoDiv = document.createElement('div');
+    photoDiv.className = 'speaker-photo';
+
+    const img = document.createElement('img');
+    img.src = speakerData.image;
+    img.alt = speakerData.title || 'Speaker';
+    photoDiv.appendChild(img);
+    speakerCard.appendChild(photoDiv);
+  }
+
+  // Add name
+  if (speakerData.title) {
+    const nameDiv = document.createElement('div');
+    nameDiv.className = 'speaker-name';
+    nameDiv.textContent = speakerData.title;
+    speakerCard.appendChild(nameDiv);
+  }
+
+  // Add title
+  if (speakerData.jobTitle) {
+    const titleDiv = document.createElement('div');
+    titleDiv.className = 'speaker-title';
+    titleDiv.textContent = speakerData.jobTitle;
+    speakerCard.appendChild(titleDiv);
+  }
+
+  // Add company
+  if (speakerData.companyName) {
+    const companyDiv = document.createElement('div');
+    companyDiv.className = 'speaker-company';
+    companyDiv.textContent = speakerData.companyName;
+    speakerCard.appendChild(companyDiv);
+  }
+
+  // Add bio (from description)
+  if (speakerData.description && speakerData.description.html) {
+    const bioDiv = document.createElement('div');
+    bioDiv.className = 'speaker-bio';
+    bioDiv.textContent = speakerData.description.html;
+    speakerCard.appendChild(bioDiv);
+  }
+
+  // Add social links (if available)
+  if (speakerData.tags && speakerData.tags.length > 0) {
+    const socialDiv = document.createElement('div');
+    socialDiv.className = 'speaker-social';
+
+    speakerData.tags.forEach((tag) => {
+      const linkSpan = document.createElement('span');
+      linkSpan.className = 'speaker-social-link';
+      linkSpan.textContent = tag;
+      socialDiv.appendChild(linkSpan);
+    });
+
+    speakerCard.appendChild(socialDiv);
+  }
+
+  return speakerCard;
+}
+
+// Function to process table-based speakers (used in both modes)
+function processTableBasedSpeakers(block, container) {
+  // Process each row as a speaker
+  const rows = [...block.children];
+
+  rows.forEach((row, index) => {
+    // Skip if it's the header row
+    if (index === 0) {
+      row.classList.add('speakers-header');
+      return;
+    }
+
+    // Create speaker card
+    const speakerCard = document.createElement('div');
+    speakerCard.className = 'speaker-card';
+
+    const cells = [...row.children];
+
+    // Process cells: name, title, company, photo, bio, social links
+    if (cells.length >= 4) {
+      const nameCell = cells[0];
+      const titleCell = cells[1];
+      const companyCell = cells[2];
+      const photoCell = cells[3];
+      const bioCell = cells[4] || null;
+      const socialCell = cells[5] || null;
+
+      // Add photo
+      if (photoCell.textContent.trim()) {
+        const photoDiv = document.createElement('div');
+        photoDiv.className = 'speaker-photo';
+
+        // If it's an image, use it directly
+        if (photoCell.querySelector('img')) {
+          photoDiv.appendChild(photoCell.firstElementChild);
+        } else {
+          // Otherwise, treat as a URL
+          const img = document.createElement('img');
+          img.src = photoCell.textContent.trim();
+          img.alt = nameCell.textContent.trim();
+          photoDiv.appendChild(img);
+        }
+
+        speakerCard.appendChild(photoDiv);
+      }
+
+      // Add name
+      if (nameCell.textContent.trim()) {
+        const nameDiv = document.createElement('div');
+        nameDiv.className = 'speaker-name';
+        nameDiv.textContent = nameCell.textContent.trim();
+        speakerCard.appendChild(nameDiv);
+      }
+
+      // Add title
+      if (titleCell.textContent.trim()) {
+        const titleDiv = document.createElement('div');
+        titleDiv.className = 'speaker-title';
+        titleDiv.textContent = titleCell.textContent.trim();
+        speakerCard.appendChild(titleDiv);
+      }
+
+      // Add company
+      if (companyCell.textContent.trim()) {
+        const companyDiv = document.createElement('div');
+        companyDiv.className = 'speaker-company';
+        companyDiv.textContent = companyCell.textContent.trim();
+        speakerCard.appendChild(companyDiv);
+      }
+
+      // Add bio
+      if (bioCell && bioCell.textContent.trim()) {
+        const bioDiv = document.createElement('div');
+        bioDiv.className = 'speaker-bio';
+        bioDiv.textContent = bioCell.textContent.trim();
+        speakerCard.appendChild(bioDiv);
+      }
+
+      // Add social links
+      if (socialCell && socialCell.textContent.trim()) {
+        const socialDiv = document.createElement('div');
+        socialDiv.className = 'speaker-social';
+
+        const socialLinks = socialCell.textContent.trim().split(',');
+        socialLinks.forEach((link) => {
+          const linkSpan = document.createElement('span');
+          linkSpan.className = 'speaker-social-link';
+          linkSpan.textContent = link.trim();
+          socialDiv.appendChild(linkSpan);
+        });
+
+        speakerCard.appendChild(socialDiv);
+      }
+    }
+
+    container.appendChild(speakerCard);
+  });
+}
+
+// Function to load speakers from Content Fragment
+async function loadSpeakersFromFragment(fragmentPath, container) {
+  try {
+    const response = await fetch(fragmentPath);
+    const data = await response.json();
+
+    if (data && data.items) {
+      data.items.forEach((item) => {
+        const speakerCard = createSpeakerCardFromFragment(item);
+        container.appendChild(speakerCard);
+      });
+    }
+  } catch (error) {
+    // Fallback to default behavior
+    processTableBasedSpeakers(null, container);
+  }
+}
+
+export default function decorate(block) {
+  // Create speakers container
+  const speakersContainer = document.createElement('div');
+  speakersContainer.className = 'speakers-container';
+
+  // Check if this is a fragment-based block
+  const { fragmentPath } = block.dataset;
+
+  if (fragmentPath) {
+    // Load content from fragment
+    loadSpeakersFromFragment(fragmentPath, speakersContainer);
+  } else {
+    // Fallback to table-based content
+    processTableBasedSpeakers(block, speakersContainer);
+  }
+
+  // Replace the block with the speakers container
+  block.innerHTML = '';
+  block.appendChild(speakersContainer);
+}
diff --git a/blocks/sponsors/sponsors.css b/blocks/sponsors/sponsors.css
new file mode 100644
index 0000000..f85ad94
--- /dev/null
+++ b/blocks/sponsors/sponsors.css
@@ -0,0 +1,83 @@
+.sponsors-container {
+  display: grid;
+  grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));
+  gap: 20px;
+  margin: 20px 0;
+}
+
+.sponsor-item {
+  text-align: center;
+  padding: 20px;
+  border: 1px solid var(--light-color);
+  border-radius: 8px;
+  background-color: var(--background-color);
+  transition: transform 0.3s ease;
+}
+
+.sponsor-item:hover {
+  transform: scale(1.05);
+}
+
+.sponsor-logo {
+  margin-bottom: 15px;
+}
+
+.sponsor-logo img {
+  max-width: 100%;
+  height: auto;
+  max-height: 80px;
+  object-fit: contain;
+}
+
+.sponsor-name {
+  font-weight: bold;
+  margin-bottom: 10px;
+  font-size: 1.1rem;
+}
+
+.sponsor-website {
+  display: inline-block;
+  margin: 10px 0;
+  padding: 8px 16px;
+  background-color: var(--link-color);
+  color: var(--background-color);
+  text-decoration: none;
+  border-radius: 4px;
+  font-size: 0.9rem;
+  transition: background-color 0.3s ease;
+}
+
+.sponsor-website:hover {
+  background-color: var(--link-hover-color);
+}
+
+.sponsor-tier {
+  display: inline-block;
+  background-color: var(--light-color);
+  padding: 5px 10px;
+  border-radius: 4px;
+  font-size: 0.8rem;
+  margin: 5px 0;
+}
+
+.sponsor-description {
+  font-size: 0.9rem;
+  line-height: 1.4;
+  margin-top: 10px;
+}
+
+@media (width >= 900px) {
+  .sponsors-container {
+    grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
+    gap: 25px;
+    margin: 30px 0;
+  }
+
+  .sponsor-item {
+    padding: 25px;
+  }
+
+  .sponsor-name {
+    font-size: 1.2rem;
+  }
+}
\ No newline at end of file
diff --git a/blocks/sponsors/sponsors.js b/blocks/sponsors/sponsors.js
new file mode 100644
index 0000000..5d1f4b4
--- /dev/null
+++ b/blocks/sponsors/sponsors.js
@@ -0,0 +1,94 @@
+/*
+ * Sponsor Logos Block
+ * Display sponsor logos and company information
+ */
+export default function decorate(block) {
+  // Create sponsors container
+  const sponsorsContainer = document.createElement('div');
+  sponsorsContainer.className = 'sponsors-container';
+
+  // Process each row as a sponsor
+  const rows = [...block.children];
+
+  rows.forEach((row, index) => {
+    // Skip if it's the header row
+    if (index === 0) {
+      row.classList.add('sponsors-header');
+      return;
+    }
+
+    // Create sponsor item
+    const sponsorItem = document.createElement('div');
+    sponsorItem.className = 'sponsor-item';
+
+    const cells = [...row.children];
+
+    // Process cells: company name, logo, website, tier level, description
+    if (cells.length >= 3) {
+      const nameCell = cells[0];
+      const logoCell = cells[1];
+      const websiteCell = cells[2];
+      const tierCell = cells[3] || null;
+      const descCell = cells[4] || null;
+
+      // Add logo
+      if (logoCell.textContent.trim()) {
+        const logoDiv = document.createElement('div');
+        logoDiv.className = 'sponsor-logo';
+
+        // If it's an image, use it directly
+        if (logoCell.querySelector('img')) {
+          logoDiv.appendChild(logoCell.firstElementChild);
+        } else {
+          // Otherwise, treat as a URL
+          const img = document.createElement('img');
+          img.src = logoCell.textContent.trim();
+          img.alt = nameCell.textContent.trim();
+          logoDiv.appendChild(img);
+        }
+
+        sponsorItem.appendChild(logoDiv);
+      }
+
+      // Add company name
+      if (nameCell.textContent.trim()) {
+        const nameDiv = document.createElement('div');
+        nameDiv.className = 'sponsor-name';
+        nameDiv.textContent = nameCell.textContent.trim();
+        sponsorItem.appendChild(nameDiv);
+      }
+
+      // Add website link
+      if (websiteCell.textContent.trim()) {
+        const websiteLink = document.createElement('a');
+        websiteLink.className = 'sponsor-website';
+        websiteLink.href = websiteCell.textContent.trim();
+        websiteLink.textContent = 'Visit Website';
+        websiteLink.target = '_blank';
+        sponsorItem.appendChild(websiteLink);
+      }
+
+      // Add tier level
+      if (tierCell && tierCell.textContent.trim()) {
+        const tierDiv = document.createElement('div');
+        tierDiv.className = 'sponsor-tier';
+        tierDiv.textContent = tierCell.textContent.trim();
+        sponsorItem.appendChild(tierDiv);
+      }
+
+      // Add description
+      if (descCell && descCell.textContent.trim()) {
+        const descDiv = document.createElement('div');
+        descDiv.className = 'sponsor-description';
+        descDiv.textContent = descCell.textContent.trim();
+        sponsorItem.appendChild(descDiv);
+      }
+    }
+
+    sponsorsContainer.appendChild(sponsorItem);
+  });
+
+  // Replace the block with the sponsors container
+  block.innerHTML = '';
+  block.appendChild(sponsorsContainer);
+}
diff --git a/docs/authoring-model.md b/docs/authoring-model.md
new file mode 100644
index 0000000..2b56722
--- /dev/null
+++ b/docs/authoring-model.md
@@ -0,0 +1,83 @@
+# Conference Website Authoring Model
+
+## Overview
+This document outlines the authoring model for the conference website solution, designed to be intuitive for marketing teams while providing all necessary content structure for a professional event website.
+
+## Core Content Types
+
+### 1. Speaker Profiles
+**Purpose**: Display speaker information including photos, bios, and company details
+
+**Table Structure**:
+| Name | Title | Company | Photo | Bio | Social Links |
+|------|-------|---------|-------|-----|--------------|
+| Jane Smith | Chief Technology Officer | TechCorp | /images/speakers/jane-smith.jpg | 15+ years in software development... | LinkedIn, Twitter |
+| John Doe | Product Manager | InnovateCo | /images/speakers/john-doe.jpg | Leading product initiatives in AI... | LinkedIn |
+
+### 2. Session Details
+**Purpose**: Provide comprehensive session information including agenda, speakers, and descriptions
+
+**Table Structure**:
+| Date | Time | Session Title | Speaker | Description | Room | Tags |
+|------|------|---------------|---------|-------------|------|------|
+| 2023-10-15 | 09:00-10:00 | Welcome & Opening Remarks | John Doe | Opening session for the conference | Main Hall | Keynote |
+| 2023-10-15 | 10:15-11:15 | AI in Modern Development | Jane Smith | Exploring AI integration in development workflows | Room A | AI, Development |
+
+### 3. Sponsor Information
+**Purpose**: Showcase event sponsors with logos and company details
+
+**Table Structure**:
+| Company Name | Logo | Website | Tier Level | Description |
+|--------------|------|---------|------------|-------------|
+| Adobe | /images/sponsors/adobe.png | https://adobe.com | Platinum | Leading creative software company |
+| Google | /images/sponsors/google.png | https://google.com | Gold | Technology and internet company |
+
+### 4. Event Metadata
+**Purpose**: Core event information that appears on all pages
+
+**Table Structure**:
+| Field | Value |
+|-------|-------|
+| Event Name | Annual Tech Conference 2023 |
+| Event Date | 2023-10-15 to 2023-10-17 |
+| Location | San Francisco, CA |
+| Registration URL | https://example.com/register |
+| Event Theme | Innovation in Digital Transformation |
+
+## Best Practices for Authors
+
+### 1. Content Reuse
+- Create speaker profiles once and reuse across sessions
+- Use consistent naming conventions for images
+- Maintain a central speaker database for easy updates
+
+### 2. Image Guidelines
+- Use recommended image sizes (e.g., 400x400px for speaker photos)
+- All images should be in WebP or JPEG format
+- Include alt text for accessibility
+
+### 3. Formatting Rules
+- Use consistent date formats (YYYY-MM-DD)
+- Keep session descriptions under 200 words
+- Limit social links to 3 per speaker
+- Use bullet points for lists
+
+### 4. Validation Checks
+- Ensure all required fields are filled
+- Verify image URLs are accessible
+- Check that dates are valid and in sequence
+- Confirm social media links are valid
+
+## Error Prevention
+
+### Common Issues and Solutions
+1. **Missing Images**: Always provide placeholder images when real images are not available
+2. **Inconsistent Dates**: Use date picker tools when available
+3. **Broken Links**: Validate all external links before publishing
+4. **Formatting Errors**: Follow the table structure exactly as specified
+
+### Authoring Tools
+- Use Google Docs or SharePoint for table-based content creation
+- Implement validation in content management system
+- Provide templates for common content types
+- Include help text and examples for each field
\ No newline at end of file
diff --git a/docs/content-fragment-usage.md b/docs/content-fragment-usage.md
new file mode 100644
index 0000000..462c0c1
--- /dev/null
+++ b/docs/content-fragment-usage.md
@@ -0,0 +1,218 @@
+# Content Fragment Usage Guide
+
+This document explains how to use AEM Content Fragments with the conference website solution for speakers, sessions, and sponsors.
+
+## Overview
+
+The conference solution supports both traditional table-based content authoring and AEM Content Fragment integration. This allows content authors to leverage the power of Content Fragments for managing speaker, session, and sponsor information while maintaining backward compatibility with existing table-based workflows.
+
+## Setting Up Content Fragments
+
+### 1. Create Content Fragment Models
+
+First, create the following Content Fragment Models in your AEM instance:
+
+#### Speaker Fragment Model
+```
+{
+  "name": "Speaker",
+  "description": "Speaker profile information",
+  "fields": [
+    {
+      "name": "title",
+      "type": "text",
+      "required": true
+    },
+    {
+      "name": "jobTitle",
+      "type": "text"
+    },
+    {
+      "name": "companyName",
+      "type": "text"
+    },
+    {
+      "name": "description",
+      "type": "longText"
+    },
+    {
+      "name": "image_ext",
+      "type": "text"
+    },
+    {
+      "name": "tags",
+      "type": "multiText"
+    }
+  ]
+}
+```
+
+#### Session Fragment Model
+```
+{
+  "name": "Session",
+  "description": "Session information",
+  "fields": [
+    {
+      "name": "title",
+      "type": "text",
+      "required": true
+    },
+    {
+      "name": "date",
+      "type": "text"
+    },
+    {
+      "name": "time",
+      "type": "text"
+    },
+    {
+      "name": "description",
+      "type": "longText"
+    },
+    {
+      "name": "speaker",
+      "type": "contentFragment"
+    },
+    {
+      "name": "room",
+      "type": "text"
+    },
+    {
+      "name": "tags",
+      "type": "multiText"
+    }
+  ]
+}
+```
+
+#### Sponsor Fragment Model
+```
+{
+  "name": "Sponsor",
+  "description": "Sponsor information",
+  "fields": [
+    {
+      "name": "companyName",
+      "type": "text",
+      "required": true
+    },
+    {
+      "name": "logo",
+      "type": "image"
+    },
+    {
+      "name": "website",
+      "type": "text"
+    },
+    {
+      "name": "description",
+      "type": "longText"
+    },
+    {
+      "name": "tags",
+      "type": "multiText"
+    }
+  ]
+}
+```
+
+### 2. Create Content Fragments
+
+Create individual content fragments for each speaker, session, and sponsor using the above models.
+
+## Using Content Fragments in Blocks
+
+### Speaker Block
+
+To use Content Fragments with the speaker block, add a `data-fragment-path` attribute to the block:
+
+```html
+<!-- In your page content -->
+<div class="speaker-block" data-fragment-path="/content/dam/conference/speakers.json">
+  <!-- Content will be loaded from the fragment -->
+</div>
+```
+
+The block will automatically fetch and display speaker data from the specified fragment.
+
+### Session Block
+
+To use Content Fragments with the session block, add a `data-fragment-path` attribute to the block:
+
+```html
+<!-- In your page content -->
+<div class="session-list-block" data-fragment-path="/content/dam/conference/sessions.json">
+  <!-- Content will be loaded from the fragment -->
+</div>
+```
+
+### Sponsor Block
+
+To use Content Fragments with the sponsor block, add a `data-fragment-path` attribute to the block:
+
+```html
+<!-- In your page content -->
+<div class="sponsor-block" data-fragment-path="/content/dam/conference/sponsors.json">
+  <!-- Content will be loaded from the fragment -->
+</div>
+```
+
+## Fallback Behavior
+
+If a `data-fragment-path` attribute is not provided, the blocks will fall back to the traditional table-based content authoring method, allowing for backward compatibility with existing content.
+
+## Fragment Data Format
+
+The Content Fragments should return data in a JSON format that the blocks can consume. For speakers, the expected structure is:
+
+```json
+{
+  "items": [
+    {
+      "id": "adrian-lee",
+      "title": "Adrian Lee",
+      "description": {
+        "html": "Adrian designs pipelines integrating AI-generated text into editorial processes."
+      },
+      "image_ext": "https://example.com/image.jpg",
+      "tags": [
+        "aem-initialyzer:conference"
+      ],
+      "jobTitle": "Marketing Technologist",
+      "companyName": "CopyGen"
+    }
+  ]
+}
+```
+
+## Best Practices
+
+1. **Consistent Naming**: Use consistent naming conventions for your fragment models and fields.
+2. **Version Control**: Keep your fragment models version-controlled to ensure consistency across environments.
+3. **Testing**: Test both fragment-based and table-based modes to ensure proper functionality.
+4. **Performance**: Consider caching strategies for frequently accessed fragments.
+5. **Documentation**: Document the structure of your fragments for content authors.
+
+## Troubleshooting
+
+### Fragment Loading Issues
+
+If fragments are not loading properly:
+1. Verify that the fragment path is correct and accessible
+2. Check that the fragment returns valid JSON
+3. Ensure that CORS settings allow access to the fragment endpoint
+4. Confirm that the fragment model matches the expected data structure
+
+### Fallback to Table-Based Content
+
+If fragment loading fails, the blocks will automatically fall back to table-based content authoring. This ensures that your content remains accessible even if there are issues with the fragment system.
+
+## Migration Strategy
+
+When migrating from table-based content to Content Fragments:
+1. Create the appropriate Content Fragment Models
+2. Create Content Fragments for existing speakers, sessions, and sponsors
+3. Update page content to use `data-fragment-path` attributes
+4. Test thoroughly to ensure proper display
+5. Gradually phase out table-based content as needed
\ No newline at end of file
diff --git a/docs/content-fragments.md b/docs/content-fragments.md
new file mode 100644
index 0000000..b11e3cc
--- /dev/null
+++ b/docs/content-fragments.md
@@ -0,0 +1,198 @@
+# Content Fragment Integration
+
+This document outlines how to integrate AEM Content Fragments with the conference website solution for speakers, sessions, and sponsors.
+
+## Overview
+
+AEM Content Fragments provide a structured way to manage content that can be reused across multiple pages and blocks. This solution will leverage Content Fragments for speakers, sessions, and sponsors to enable content reuse and centralized management.
+
+## Configuration Setup
+
+### 1. Content Fragment Models
+
+For each content type, we'll need to create appropriate Content Fragment Models:
+
+#### Speaker Fragment Model
+```
+{
+  "name": "Speaker",
+  "description": "Speaker profile information",
+  "fields": [
+    {
+      "name": "fullName",
+      "type": "text",
+      "required": true
+    },
+    {
+      "name": "jobTitle",
+      "type": "text"
+    },
+    {
+      "name": "company",
+      "type": "text"
+    },
+    {
+      "name": "bio",
+      "type": "longText"
+    },
+    {
+      "name": "photo",
+      "type": "image"
+    },
+    {
+      "name": "socialLinks",
+      "type": "multiText"
+    }
+  ]
+}
+```
+
+#### Session Fragment Model
+```
+{
+  "name": "Session",
+  "description": "Session information",
+  "fields": [
+    {
+      "name": "title",
+      "type": "text",
+      "required": true
+    },
+    {
+      "name": "date",
+      "type": "date"
+    },
+    {
+      "name": "time",
+      "type": "text"
+    },
+    {
+      "name": "description",
+      "type": "longText"
+    },
+    {
+      "name": "speaker",
+      "type": "contentFragment"
+    },
+    {
+      "name": "room",
+      "type": "text"
+    },
+    {
+      "name": "tags",
+      "type": "multiText"
+    }
+  ]
+}
+```
+
+#### Sponsor Fragment Model
+```
+{
+  "name": "Sponsor",
+  "description": "Sponsor information",
+  "fields": [
+    {
+      "name": "companyName",
+      "type": "text",
+      "required": true
+    },
+    {
+      "name": "logo",
+      "type": "image"
+    },
+    {
+      "name": "website",
+      "type": "text"
+    },
+    {
+      "name": "tier",
+      "type": "text"
+    },
+    {
+      "name": "description",
+      "type": "longText"
+    }
+  ]
+}
+```
+
+### 2. Block Implementation for Content Fragments
+
+The blocks will need to be updated to fetch content from Content Fragments rather than tables:
+
+#### Speaker Cards Block
+The speakers block will be updated to:
+- Accept a Content Fragment path or reference
+- Fetch speaker data from the Content Fragment
+- Display speaker information using the fragment fields
+
+#### Session List Block
+The session list block will be updated to:
+- Accept a Content Fragment path or reference
+- Fetch session data from the Content Fragment
+- Display session information with speaker details
+
+#### Sponsors Block
+The sponsors block will be updated to:
+- Accept a Content Fragment path or reference
+- Fetch sponsor data from the Content Fragment
+- Display sponsor logos and information
+
+## Implementation Approach
+
+### 1. Fragment Loading Function
+Create a helper function to load and process Content Fragments:
+
+```javascript
+async function loadContentFragment(fragmentPath) {
+  try {
+    const response = await fetch(fragmentPath);
+    const data = await response.json();
+    return data;
+  } catch (error) {
+    console.error('Failed to load content fragment:', error);
+    return null;
+  }
+}
+```
+
+### 2. Block Configuration
+Each block will support both:
+- Table-based authoring (legacy support)
+- Content Fragment reference (new approach)
+
+### 3. Configuration File
+Create a configuration file to define fragment paths:
+
+```json
+{
+  "fragments": {
+    "speakers": "/content/dam/speakers",
+    "sessions": "/content/dam/sessions",
+    "sponsors": "/content/dam/sponsors"
+  }
+}
+```
+
+## Usage Instructions
+
+### For Content Authors
+1. Create Content Fragments using the defined models
+2. Place fragments in the appropriate folders
+3. Reference fragments in blocks using the fragment path
+4. Content will automatically populate the blocks
+
+### For Developers
+1. Update block JavaScript to support fragment loading
+2. Implement fallback to table-based content
+3. Add fragment configuration in the project
+4. Test fragment loading and display
+
+## Benefits of Content Fragment Integration
+
+1. **Centralized Content Management**: Single source of truth for speaker, session, and sponsor information
+2. **Content Reuse**: Same speakers can be referenced across multiple sessions
+3. **Consistency**: Ensures uniform presentation of information
+4. **Scalability**: Easy to add new content without modifying block structures
+5. **Maintenance**: Updates to content fragments automatically propagate to all references
\ No newline at end of file
diff --git a/ue/models/_section.json b/ue/models/_section.json
index c42ed03..5bd434b 100644
--- a/ue/models/_section.json
+++ b/ue/models/_section.json
@@ -55,6 +55,7 @@
         "image",
         "quote",
         "search",
+        "speaker",
         "tabs",
         "table",
         "text",
diff --git a/ue/models/speaker.json b/ue/models/speaker.json
new file mode 100644
index 0000000..f8cc546
--- /dev/null
+++ b/ue/models/speaker.json
@@ -0,0 +1,31 @@
+{
+  "definitions": [
+    {
+      "title": "Speaker",
+      "id": "speaker",
+      "plugins": {
+        "xwalk": {
+          "page": {
+            "resourceType": "core/franklin/components/block/v1/block",
+            "template": {
+              "model": "speaker"
+            }
+          }
+        }
+      }
+    }
+  ],
+  "models": [
+    {
+      "id": "speaker",
+      "fields": [
+        {
+          "component": "aem-content",
+          "name": "fragmentPath",
+          "label": "Content Fragment Path",
+          "description": "Path to the Content Fragment containing speaker data"
+        }
+      ]
+    }
+  ]
+}
\ No newline at end of file