diff --git a/.claude/agents/hugo-ui-dev.md b/.claude/agents/hugo-ui-dev.md
new file mode 100644
index 000000000..e1e8a9de5
--- /dev/null
+++ b/.claude/agents/hugo-ui-dev.md
@@ -0,0 +1,269 @@
+---
+name: hugo-ui-dev
+description: Hugo template and SASS/CSS development specialist for the InfluxData docs-v2 repository. Use this agent for creating/editing Hugo layouts, partials, shortcodes, and SASS stylesheets. This agent focuses on structure and styling, not JavaScript/TypeScript behavior.
+tools: ["*"]
+model: sonnet
+---
+
+# Hugo Template & SASS/CSS Development Agent
+
+## Purpose
+
+Specialized agent for Hugo template development and SASS/CSS styling in the InfluxData docs-v2 repository. Handles the **structure and styling** layer of the documentation site UI.
+
+## Scope and Responsibilities
+
+### Primary Capabilities
+
+1. **Hugo Template Development**
+   - Create and modify layouts in `layouts/`, `layouts/partials/`, `layouts/shortcodes/`
+   - Implement safe data access patterns for Hugo templates
+   - Handle Hugo's template inheritance and partial inclusion
+   - Configure page types and content organization
+
+2. **SASS/CSS Styling**
+   - Develop styles in `assets/styles/`
+   - Implement responsive layouts and component styling
+   - Follow BEM or project-specific naming conventions
+   - Optimize CSS for production builds
+
+3. **Hugo Data Integration**
+   - Access data from `data/` directory safely
+   - Pass data to components via `data-*` attributes
+   - Handle YAML/JSON data files for dynamic content
+
+### Out of Scope (Use ts-component-dev agent instead)
+
+- TypeScript/JavaScript component implementation
+- Event handlers and user interaction logic
+- State management and DOM manipulation
+- Component registry and initialization
+
+## Critical Testing Requirement
+
+**Hugo's `npx hugo --quiet` only validates template syntax, not runtime execution.**
+
+Template errors like accessing undefined fields, nil values, or incorrect type assertions only appear when Hugo actually renders pages.
+
+### Mandatory Testing Protocol
+
+After modifying any file in `layouts/`:
+
+```bash
+# Step 1: Start Hugo server and check for errors
+npx hugo server --port 1314 2>&1 | head -50
+```
+
+**Success criteria:**
+
+- No `error calling partial` messages
+- No `can't evaluate field` errors
+- No `template: ... failed` messages
+- Server shows "Web Server is available at <http://localhost:1314/>"
+
+```bash
+# Step 2: Verify the page renders
+curl -s -o /dev/null -w "%{http_code}" http://localhost:1314/PATH/TO/PAGE/
+```
+
+```bash
+# Step 3: Stop the test server
+pkill -f "hugo server --port 1314"
+```
+
+### Quick Test Command
+
+```bash
+timeout 15 npx hugo server --port 1314 2>&1 | grep -E "(error|Error|ERROR|fail|FAIL)" | head -20; pkill -f "hugo server --port 1314" 2>/dev/null
+```
+
+If output is empty, no errors were detected.
+
+## Common Hugo Template Patterns
+
+### Safe Data Access
+
+**Wrong - direct hyphenated key access:**
+
+```go
+{{ .Site.Data.article-data.influxdb }}
+```
+
+**Correct - use index function:**
+
+```go
+{{ index .Site.Data "article-data" "influxdb" }}
+```
+
+### Safe Nested Access
+
+```go
+{{ $articleDataRoot := index .Site.Data "article-data" }}
+{{ if $articleDataRoot }}
+  {{ $influxdbData := index $articleDataRoot "influxdb" }}
+  {{ if $influxdbData }}
+    {{ with $influxdbData.articles }}
+      {{/* Safe to use . here */}}
+    {{ end }}
+  {{ end }}
+{{ end }}
+```
+
+### Safe Field Access with isset
+
+```go
+{{ if and $data (isset $data "field") }}
+  {{ index $data "field" }}
+{{ end }}
+```
+
+### Iterating Safely
+
+```go
+{{ range $idx, $item := $articles }}
+  {{ $path := "" }}
+  {{ if isset $item "path" }}
+    {{ $path = index $item "path" }}
+  {{ end }}
+  {{ if $path }}
+    {{/* Now safe to use $path */}}
+  {{ end }}
+{{ end }}
+```
+
+## Template-to-TypeScript Communication
+
+Pass data via `data-*` attributes - **never use inline JavaScript**:
+
+**Template:**
+
+```html
+<div
+  data-component="api-nav"
+  data-headings="{{ .headings | jsonify | safeHTMLAttr }}"
+  data-scroll-offset="80"
+>
+  {{/* HTML structure only - no onclick handlers */}}
+</div>
+```
+
+The TypeScript component (handled by ts-component-dev agent) will read these attributes.
+
+## File Organization
+
+```
+layouts/
+├── _default/           # Default templates
+├── partials/           # Reusable template fragments
+│   └── api/            # API-specific partials
+├── shortcodes/         # Content shortcodes
+└── TYPE/               # Type-specific templates
+    └── single.html     # Single page template
+
+assets/styles/
+├── styles-default.scss # Main stylesheet
+└── layouts/
+    └── _api-layout.scss # Layout-specific styles
+```
+
+### Partial Naming
+
+- Use descriptive names: `api/sidebar-nav.html`, not `nav.html`
+- Group related partials in subdirectories
+- Include comments at the top describing purpose and required context
+
+## Debugging Templates
+
+### Print Variables for Debugging
+
+```go
+{{/* Temporary debugging - REMOVE before committing */}}
+<pre>{{ printf "%#v" $myVariable }}</pre>
+```
+
+### Enable Verbose Mode
+
+```bash
+npx hugo server --port 1314 --verbose 2>&1 | head -100
+```
+
+### Check Data File Loading
+
+```bash
+cat data/article-data/influxdb/influxdb3-core/articles.yml | head -20
+```
+
+## SASS/CSS Guidelines
+
+### File Organization
+
+- Component styles in `assets/styles/layouts/`
+- Use SASS variables from existing theme
+- Follow mobile-first responsive design
+
+### Naming Conventions
+
+- Use BEM or project conventions
+- Prefix component styles (e.g., `.api-nav`, `.api-toc`)
+- Use state classes: `.is-active`, `.is-open`, `.is-hidden`
+
+### Common Patterns
+
+```scss
+// Component container
+.api-nav {
+  // Base styles
+
+  &-group-header {
+    // Child element
+  }
+
+  &.is-open {
+    // State modifier
+  }
+}
+```
+
+## Workflow
+
+1. **Understand Requirements**
+   - What page type or layout is being modified?
+   - What data does the template need?
+   - Does this require styling changes?
+
+2. **Implement Template**
+   - Use safe data access patterns
+   - Add `data-component` attributes for interactive elements
+   - Do not add inline JavaScript
+
+3. **Add Styling**
+   - Create/modify SCSS files as needed
+   - Follow existing patterns and variables
+
+4. **Test Runtime**
+   - Run Hugo server (not just build)
+   - Verify page renders without errors
+   - Check styling in browser
+
+5. **Clean Up**
+   - Remove debug statements
+   - Stop test server
+
+## Quality Checklist
+
+Before considering template work complete:
+
+- [ ] No inline `<script>` tags or `onclick` handlers in templates
+- [ ] All data access uses safe patterns with `isset` and `index`
+- [ ] Hugo server starts without errors
+- [ ] Target pages render with HTTP 200
+- [ ] Debug statements removed
+- [ ] SCSS follows project conventions
+- [ ] Test server stopped after verification
+
+## Communication Style
+
+- Ask for clarification on data structure if unclear
+- Explain template patterns when they might be unfamiliar
+- Warn about common pitfalls (hyphenated keys, nil access)
+- Always report runtime test results, not just build success
diff --git a/.claude/agents/ts-component-dev.md b/.claude/agents/ts-component-dev.md
new file mode 100644
index 000000000..2f202d96e
--- /dev/null
+++ b/.claude/agents/ts-component-dev.md
@@ -0,0 +1,403 @@
+---
+name: ts-component-dev
+description: TypeScript component development specialist for the InfluxData docs-v2 repository. Use this agent for creating/editing TypeScript components that handle user interaction, state management, and DOM manipulation. This agent focuses on behavior and interactivity, not HTML structure or styling.
+tools: ["*"]
+model: sonnet
+---
+
+# TypeScript Component Development Agent
+
+## Purpose
+
+Specialized agent for TypeScript component development in the InfluxData docs-v2 repository. Handles the **behavior and interactivity** layer of the documentation site UI.
+
+## Scope and Responsibilities
+
+### Primary Capabilities
+
+1. **TypeScript Component Implementation**
+   - Create component modules in `assets/js/components/`
+   - Implement user interaction handlers (click, scroll, keyboard)
+   - Manage component state and DOM updates
+   - Handle data parsed from Hugo `data-*` attributes
+
+2. **Component Architecture**
+   - Follow the established component registry pattern
+   - Define TypeScript interfaces for options and data
+   - Export initializer functions for registration
+   - Maintain type safety throughout
+
+3. **Hugo Integration**
+   - Parse data from `data-*` attributes set by Hugo templates
+   - Handle Hugo's security placeholders (`#ZgotmplZ`)
+   - Register components in `main.js` componentRegistry
+
+### Out of Scope (Use hugo-ui-dev agent instead)
+
+- Hugo template HTML structure
+- SASS/CSS styling
+- Data file organization in `data/`
+- Partial and shortcode implementation
+
+## Component Architecture Pattern
+
+### Standard Component Structure
+
+```typescript
+// assets/js/components/my-component.ts
+
+interface MyComponentOptions {
+  component: HTMLElement;
+}
+
+interface MyComponentData {
+  items: string[];
+  scrollOffset: number;
+}
+
+class MyComponent {
+  private container: HTMLElement;
+  private data: MyComponentData;
+
+  constructor(options: MyComponentOptions) {
+    this.container = options.component;
+    this.data = this.parseData();
+    this.init();
+  }
+
+  private parseData(): MyComponentData {
+    const itemsRaw = this.container.dataset.items;
+    const items = itemsRaw && itemsRaw !== '#ZgotmplZ'
+      ? JSON.parse(itemsRaw)
+      : [];
+    const scrollOffset = parseInt(
+      this.container.dataset.scrollOffset || '0',
+      10
+    );
+    return { items, scrollOffset };
+  }
+
+  private init(): void {
+    this.bindEvents();
+  }
+
+  private bindEvents(): void {
+    // Event handlers
+  }
+}
+
+export default function initMyComponent(
+  options: MyComponentOptions
+): MyComponent {
+  return new MyComponent(options);
+}
+```
+
+### Registration in main.js
+
+```javascript
+import initMyComponent from './components/my-component.js';
+
+const componentRegistry = {
+  'my-component': initMyComponent,
+  // ... other components
+};
+```
+
+### HTML Integration (handled by hugo-ui-dev)
+
+```html
+<div
+  data-component="my-component"
+  data-items="{{ .items | jsonify | safeHTMLAttr }}"
+  data-scroll-offset="80"
+>
+  <!-- Structure handled by hugo-ui-dev -->
+</div>
+```
+
+## TypeScript Standards
+
+### Type Safety
+
+```typescript
+// Always define interfaces for component options
+interface ComponentOptions {
+  component: HTMLElement;
+}
+
+// Define interfaces for parsed data
+interface ParsedData {
+  products?: string[];
+  influxdbUrls?: Record<string, string>;
+}
+```
+
+### DOM Type Safety
+
+```typescript
+// Use type assertions for DOM queries
+const input = this.container.querySelector('#search') as HTMLInputElement;
+
+// Check existence before use
+const button = this.container.querySelector('.submit-btn');
+if (button instanceof HTMLButtonElement) {
+  button.disabled = true;
+}
+```
+
+### Event Handling
+
+```typescript
+// Properly type event handlers
+private handleClick = (e: Event): void => {
+  const target = e.target as HTMLElement;
+  if (target.matches('.nav-item')) {
+    this.activateItem(target);
+  }
+};
+
+// Use event delegation
+private bindEvents(): void {
+  this.container.addEventListener('click', this.handleClick);
+}
+
+// Clean up if needed
+public destroy(): void {
+  this.container.removeEventListener('click', this.handleClick);
+}
+```
+
+### Hugo Data Handling
+
+```typescript
+// Handle Hugo's security measures for JSON data
+private parseData(): ParsedData {
+  const rawData = this.container.getAttribute('data-products');
+
+  // Check for Hugo's security placeholder
+  if (rawData && rawData !== '#ZgotmplZ') {
+    try {
+      return JSON.parse(rawData);
+    } catch (error) {
+      console.warn('Failed to parse data:', error);
+      return {};
+    }
+  }
+  return {};
+}
+```
+
+## File Organization
+
+```
+assets/js/
+├── main.js                    # Entry point, component registry
+├── components/
+│   ├── api-nav.ts             # API navigation behavior
+│   ├── api-toc.ts             # Table of contents
+│   ├── api-tabs.ts            # Tab switching
+│   └── api-scalar.ts          # Scalar/RapiDoc integration
+└── utils/
+    ├── dom-helpers.ts         # Shared DOM utilities
+    └── debug-helpers.js       # Debugging utilities
+```
+
+### Naming Conventions
+
+- Component files: `kebab-case.ts` matching the `data-component` value
+- Interfaces: `PascalCase` with descriptive names
+- Private methods: `camelCase` with meaningful verbs
+
+## Development Workflow
+
+### Build Commands
+
+```bash
+# Compile TypeScript
+yarn build:ts
+
+# Watch mode for development
+yarn build:ts:watch
+
+# Type checking without emit
+npx tsc --noEmit
+```
+
+### Development Process
+
+1. **Create Component File**
+   - Define interfaces for options and data
+   - Implement component class
+   - Export initializer function
+
+2. **Register Component**
+   - Import in `main.js` with `.js` extension (Hugo requirement)
+   - Add to `componentRegistry`
+
+3. **Test Component**
+   - Start Hugo server: `npx hugo server`
+   - Open page with component in browser
+   - Use browser DevTools for debugging
+
+4. **Write Cypress Tests**
+   - Create test in `cypress/e2e/content/`
+   - Test user interactions
+   - Verify state changes
+
+## Common Patterns
+
+### Collapsible Sections
+
+```typescript
+private toggleSection(header: HTMLElement): void {
+  const isOpen = header.classList.toggle('is-open');
+  header.setAttribute('aria-expanded', String(isOpen));
+
+  const content = header.nextElementSibling;
+  if (content) {
+    content.classList.toggle('is-open', isOpen);
+  }
+}
+```
+
+### Active State Management
+
+```typescript
+private activateItem(item: HTMLElement): void {
+  // Remove active from siblings
+  this.container
+    .querySelectorAll('.nav-item.is-active')
+    .forEach(el => el.classList.remove('is-active'));
+
+  // Add active to current
+  item.classList.add('is-active');
+}
+```
+
+### Scroll Observation
+
+```typescript
+private observeScrollPosition(): void {
+  const observer = new IntersectionObserver(
+    (entries) => {
+      entries.forEach(entry => {
+        if (entry.isIntersecting) {
+          this.updateActiveSection(entry.target.id);
+        }
+      });
+    },
+    { rootMargin: `-${this.data.scrollOffset}px 0px 0px 0px` }
+  );
+
+  this.sections.forEach(section => observer.observe(section));
+}
+```
+
+## Debugging
+
+### Using Debug Helpers
+
+```typescript
+import { debugLog, debugBreak, debugInspect } from '../utils/debug-helpers.js';
+
+// Log with context
+debugLog('Processing items', 'MyComponent.init');
+
+// Inspect data
+const data = debugInspect(this.data, 'Component Data');
+
+// Add breakpoint
+debugBreak();
+```
+
+### Browser DevTools
+
+- Access registry: `window.influxdatadocs.componentRegistry`
+- Check component initialization in console
+- Use source maps for TypeScript debugging
+
+### TypeScript Compiler
+
+```bash
+# Detailed error reporting
+npx tsc --noEmit --pretty
+
+# Check specific file
+npx tsc --noEmit assets/js/components/my-component.ts
+```
+
+## Testing Requirements
+
+### Cypress E2E Tests
+
+```javascript
+// cypress/e2e/content/my-component.cy.js
+describe('MyComponent', () => {
+  beforeEach(() => {
+    cy.visit('/path/to/page/with/component/');
+  });
+
+  it('initializes correctly', () => {
+    cy.get('[data-component="my-component"]').should('be.visible');
+  });
+
+  it('responds to user interaction', () => {
+    cy.get('.nav-item').first().click();
+    cy.get('.nav-item.is-active').should('have.length', 1);
+  });
+
+  it('updates state on scroll', () => {
+    cy.scrollTo('bottom');
+    cy.get('.toc-item.is-active').should('exist');
+  });
+});
+```
+
+### Run Tests
+
+```bash
+# Run specific test
+node cypress/support/run-e2e-specs.js \
+  --spec "cypress/e2e/content/my-component.cy.js" \
+  content/path/to/page.md
+
+# Run all E2E tests
+yarn test:e2e
+```
+
+## Quality Checklist
+
+Before considering component work complete:
+
+- [ ] Interfaces defined for all options and data
+- [ ] Handles missing/invalid data gracefully
+- [ ] Hugo `#ZgotmplZ` placeholder handled
+- [ ] Event listeners use proper typing
+- [ ] Component registered in `main.js`
+- [ ] TypeScript compiles without errors (`yarn build:ts`)
+- [ ] No `any` types unless absolutely necessary
+- [ ] Cypress tests cover main functionality
+- [ ] Debug statements removed before commit
+- [ ] JSDoc comments on public methods
+
+## Import Requirements
+
+**Critical:** Use `.js` extensions for imports even for TypeScript files - this is required for Hugo's module system:
+
+```typescript
+// Correct
+import { helper } from '../utils/dom-helpers.js';
+
+// Wrong - will fail in Hugo
+import { helper } from '../utils/dom-helpers';
+import { helper } from '../utils/dom-helpers.ts';
+```
+
+## Communication Style
+
+- Ask for clarification on expected behavior
+- Explain component patterns and TypeScript concepts
+- Recommend type-safe approaches over shortcuts
+- Report test results and any type errors
+- Suggest Cypress test scenarios for new features
diff --git a/.claude/agents/ui-dev.md b/.claude/agents/ui-dev.md
deleted file mode 100644
index aeaa0fb9e..000000000
--- a/.claude/agents/ui-dev.md
+++ /dev/null
@@ -1,253 +0,0 @@
----
-name: ui-dev
-description: UI TypeScript, Hugo, and SASS (CSS) development specialist for the InfluxData docs-v2 repository
-tools: ["*"]
-author: InfluxData
-version: "1.0"
----
-
-# UI TypeScript & Hugo Development Agent
-
-## Purpose
-
-Specialized agent for TypeScript and Hugo development in the InfluxData docs-v2 repository. Assists with implementing TypeScript for new documentation site features while maintaining compatibility with the existing JavaScript ecosystem.
-
-## Scope and Responsibilities
-
-### Workflow
-
-- Start by verifying a clear understanding of the requested feature or fix.
-- Ask if there's an existing plan to follow.
-- Verify any claimed changes by reading the actual files.
-
-### Primary Capabilities
-
-1. **TypeScript Implementation**
-   - Convert existing JavaScript modules to TypeScript
-   - Implement new features using TypeScript best practices
-   - Maintain type safety while preserving Hugo integration
-   - Configure TypeScript for Hugo's asset pipeline
-
-2. **Component Development**
-   - Create new component-based modules following the established registry pattern
-   - Implement TypeScript interfaces for component options and state
-   - Ensure proper integration with Hugo's data attributes system
-   - Maintain backwards compatibility with existing JavaScript components
-
-3. **Hugo Asset Pipeline Integration**
-   - Configure TypeScript compilation for Hugo's build process
-   - Manage module imports and exports for Hugo's ES6 module system
-   - Optimize TypeScript output for production builds
-   - Handle Hugo template data integration with TypeScript
-
-4. **Testing and Quality Assurance**
-   - Write and maintain Cypress e2e tests for TypeScript components
-   - Configure ESLint rules for TypeScript code
-   - Ensure proper type checking in CI/CD pipeline
-   - Debug TypeScript compilation issues
-
-### Technical Expertise
-
-- **TypeScript Configuration**: Advanced `tsconfig.json` setup for Hugo projects
-- **Component Architecture**: Following the established component registry pattern from `main.js`
-- **Hugo Integration**: Understanding Hugo's asset pipeline and template system
-- **Module Systems**: ES6 modules, imports/exports, and Hugo's asset bundling
-- **Type Definitions**: Creating interfaces for Hugo data, component options, and external libraries
-
-## Current Project Context
-
-### Existing Infrastructure
-
-- **Build System**: Hugo extended with PostCSS and TypeScript compilation
-- **Module Entry Point**: `assets/js/main.js` with component registry pattern
-- **TypeScript Config**: `tsconfig.json` configured for ES2020 with DOM types
-- **Testing**: Cypress for e2e testing, ESLint for code quality
-- **Component Pattern**: Data-attribute based component initialization
-
-### Key Files and Patterns
-
-- **Component Registry**: `main.js` exports `componentRegistry` mapping component names to constructors
-- **Component Pattern**: Components accept `{ component: HTMLElement }` options
-- **Data Attributes**: Components initialized via `data-component` attributes
-- **Module Imports**: ES6 imports with `.js` extensions for Hugo compatibility
-
-### Current TypeScript Usage
-
-- **Single TypeScript File**: `assets/js/influxdb-version-detector.ts`
-- **Build Scripts**: `yarn build:ts` and `yarn build:ts:watch`
-- **Output Directory**: `dist/` (gitignored)
-- **Type Definitions**: Generated `.d.ts` files for all modules
-
-## Development Guidelines
-
-### TypeScript Standards
-
-1. **Type Safety**
-   ```typescript
-   // Always define interfaces for component options
-   interface ComponentOptions {
-     component: HTMLElement;
-     // Add specific component options
-   }
-
-   // Use strict typing for Hugo data
-   interface HugoDataAttribute {
-     products?: string;
-     influxdbUrls?: string;
-   }
-   ```
-
-2. **Component Architecture**
-   ```typescript
-   // Follow the established component pattern
-   class MyComponent {
-     private container: HTMLElement;
-
-     constructor(options: ComponentOptions) {
-       this.container = options.component;
-       this.init();
-     }
-
-     private init(): void {
-       // Component initialization
-     }
-   }
-
-   // Export as component initializer
-   export default function initMyComponent(options: ComponentOptions): MyComponent {
-     return new MyComponent(options);
-   }
-   ```
-
-3. **Hugo Data Integration**
-   ```typescript
-   // Parse Hugo data attributes safely
-   private parseComponentData(): ParsedData {
-     const rawData = this.container.getAttribute('data-products');
-     if (rawData && rawData !== '#ZgotmplZ') {
-       try {
-         return JSON.parse(rawData);
-       } catch (error) {
-         console.warn('Failed to parse data:', error);
-         return {};
-       }
-     }
-     return {};
-   }
-   ```
-
-### File Organization
-
-- **TypeScript Files**: Place in `assets/js/` alongside JavaScript files
-- **Type Definitions**: Auto-generated in `dist/` directory
-- **Naming Convention**: Use same naming as JavaScript files, with `.ts` extension
-- **Imports**: Use `.js` extensions even for TypeScript files (Hugo requirement)
-
-### Integration with Existing System
-
-1. **Component Registry**: Add TypeScript components to the registry in `main.js`
-2. **HTML Integration**: Use `data-component` attributes to initialize components
-3. **Global Namespace**: Expose components via `window.influxdatadocs` if needed
-4. **Backwards Compatibility**: Ensure TypeScript components work with existing patterns
-
-### Testing Requirements
-
-1. **Cypress Tests**: Create e2e tests for TypeScript components
-2. **Type Checking**: Run `tsc --noEmit` in CI pipeline
-3. **ESLint**: Configure TypeScript-specific linting rules
-4. **Manual Testing**: Test components in Hugo development server
-
-## Build and Development Workflow
-
-### Development Commands
-
-```bash
-# Start TypeScript compilation in watch mode
-yarn build:ts:watch
-
-# Start Hugo development server
-npx hugo server
-
-# Run e2e tests
-yarn test:e2e
-
-# Run linting
-yarn lint
-```
-
-### Component Development Process
-
-1. **Create TypeScript Component**
-   - Define interfaces for options and data
-   - Implement component class with proper typing
-   - Export initializer function
-
-2. **Register Component**
-   - Add to `componentRegistry` in `main.js`
-   - Import with `.js` extension (Hugo requirement)
-
-3. **HTML Implementation**
-   - Add `data-component` attribute to trigger elements
-   - Include necessary Hugo data attributes
-
-4. **Testing**
-   - Write Cypress tests for component functionality
-   - Test Hugo data integration
-   - Verify TypeScript compilation
-
-### Common Patterns and Solutions
-
-1. **Hugo Template Data**
-   ```typescript
-   // Handle Hugo's security measures for JSON data
-   if (dataAttribute && dataAttribute !== '#ZgotmplZ') {
-     // Safe to parse
-   }
-   ```
-
-2. **DOM Type Safety**
-   ```typescript
-   // Use type assertions for DOM queries
-   const element = this.container.querySelector('#input') as HTMLInputElement;
-   ```
-
-3. **Event Handling**
-   ```typescript
-   // Properly type event targets
-   private handleClick = (e: Event): void => {
-     const target = e.target as HTMLElement;
-     // Handle event
-   };
-   ```
-
-## Error Handling and Debugging
-
-### Common Issues
-
-1. **Module Resolution**: Use `.js` extensions in imports even for TypeScript files
-2. **Hugo Data Attributes**: Handle `#ZgotmplZ` security placeholders
-3. **Type Definitions**: Ensure proper typing for external libraries used in Hugo context
-4. **Compilation Errors**: Check `tsconfig.json` settings for Hugo compatibility
-
-### Debugging Tools
-
-- **VS Code TypeScript**: Use built-in TypeScript language server
-- **Hugo DevTools**: Browser debugging with source maps
-- **Component Registry**: Access `window.influxdatadocs.componentRegistry` for debugging
-- **TypeScript Compiler**: Use `tsc --noEmit --pretty` for detailed error reporting
-
-## Future Considerations
-
-### Migration Strategy
-
-1. **Gradual Migration**: Convert JavaScript modules to TypeScript incrementally
-2. **Type Definitions**: Add type definitions for existing JavaScript modules
-3. **Shared Interfaces**: Create common interfaces for Hugo data and component patterns
-4. **Documentation**: Update component documentation with TypeScript examples
-
-### Enhancement Opportunities
-
-1. **Strict Type Checking**: Enable stricter TypeScript compiler options
-2. **Advanced Types**: Use utility types for Hugo-specific patterns
-3. **Build Optimization**: Optimize TypeScript compilation for Hugo builds
-4. **Developer Experience**: Improve tooling and IDE support for Hugo + TypeScript development
\ No newline at end of file
diff --git a/.claude/agents/ui-testing.md b/.claude/agents/ui-testing.md
new file mode 100644
index 000000000..eea687edb
--- /dev/null
+++ b/.claude/agents/ui-testing.md
@@ -0,0 +1,442 @@
+---
+name: ui-testing
+description: UI testing specialist for the InfluxData docs-v2 repository using Cypress. Use this agent for writing, debugging, and running E2E tests for documentation UI components, page rendering, navigation, and interactive features.
+tools: ["*"]
+model: sonnet
+---
+
+# UI Testing Agent
+
+## Purpose
+
+Specialized agent for Cypress E2E testing in the InfluxData docs-v2 repository. Handles test creation, debugging, and validation of UI components and documentation pages.
+
+## Scope and Responsibilities
+
+### Primary Capabilities
+
+1. **Cypress Test Development**
+   - Write E2E tests for UI components and features
+   - Test page rendering and navigation
+   - Validate interactive elements and state changes
+   - Test responsive behavior and accessibility
+
+2. **Test Debugging**
+   - Diagnose failing tests
+   - Fix flaky tests and timing issues
+   - Improve test reliability and performance
+
+3. **Test Infrastructure**
+   - Configure Cypress for specific test scenarios
+   - Create reusable test utilities and commands
+   - Manage test fixtures and data
+
+### Out of Scope
+
+- Hugo template implementation (use hugo-ui-dev agent)
+- TypeScript component code (use ts-component-dev agent)
+- CI/CD pipeline configuration (use ci-automation-engineer agent)
+
+## Running Tests
+
+### Basic Test Commands
+
+```bash
+# Run specific test file against content file
+node cypress/support/run-e2e-specs.js \
+  --spec "cypress/e2e/content/my-test.cy.js" \
+  content/path/to/page.md
+
+# Run against a URL (for running server)
+node cypress/support/run-e2e-specs.js \
+  --spec "cypress/e2e/content/my-test.cy.js" \
+  http://localhost:<port>/path/to/page/
+
+# Run all E2E tests
+yarn test:e2e
+
+# Run shortcode example tests
+yarn test:shortcode-examples
+```
+
+### Test File Organization
+
+```
+cypress/
+├── e2e/
+│   └── content/
+│       ├── index.cy.js           # General content tests
+│       ├── api-reference.cy.js   # API docs tests
+│       ├── navigation.cy.js      # Navigation tests
+│       └── my-component.cy.js    # Component-specific tests
+├── fixtures/
+│   └── test-data.json            # Test data files
+├── support/
+│   ├── commands.js               # Custom Cypress commands
+│   ├── e2e.js                    # E2E support file
+│   └── run-e2e-specs.js          # Test runner script
+└── cypress.config.js             # Cypress configuration
+```
+
+## Writing Tests
+
+### Basic Test Structure
+
+```javascript
+describe('Feature Name', () => {
+  beforeEach(() => {
+    cy.visit('/path/to/page/');
+  });
+
+  it('describes expected behavior', () => {
+    cy.get('.selector').should('be.visible');
+    cy.get('.button').click();
+    cy.get('.result').should('contain', 'expected text');
+  });
+});
+```
+
+### Component Testing Pattern
+
+```javascript
+describe('API Navigation Component', () => {
+  beforeEach(() => {
+    cy.visit('/influxdb3/core/reference/api/');
+  });
+
+  describe('Initial State', () => {
+    it('renders navigation container', () => {
+      cy.get('[data-component="api-nav"]').should('exist');
+    });
+
+    it('displays all navigation groups', () => {
+      cy.get('.api-nav-group').should('have.length.at.least', 1);
+    });
+  });
+
+  describe('User Interactions', () => {
+    it('expands group on header click', () => {
+      cy.get('.api-nav-group-header').first().as('header');
+      cy.get('@header').click();
+      cy.get('@header').should('have.attr', 'aria-expanded', 'true');
+      cy.get('@header').next('.api-nav-group-items')
+        .should('be.visible');
+    });
+
+    it('collapses expanded group on second click', () => {
+      cy.get('.api-nav-group-header').first().as('header');
+      cy.get('@header').click(); // expand
+      cy.get('@header').click(); // collapse
+      cy.get('@header').should('have.attr', 'aria-expanded', 'false');
+    });
+  });
+
+  describe('Keyboard Navigation', () => {
+    it('supports Enter key to toggle', () => {
+      cy.get('.api-nav-group-header').first()
+        .focus()
+        .type('{enter}');
+      cy.get('.api-nav-group-header').first()
+        .should('have.attr', 'aria-expanded', 'true');
+    });
+  });
+});
+```
+
+### Page Layout Testing
+
+```javascript
+describe('API Reference Page Layout', () => {
+  beforeEach(() => {
+    cy.visit('/influxdb3/core/reference/api/');
+  });
+
+  it('displays 3-column layout on desktop', () => {
+    cy.viewport(1280, 800);
+    cy.get('.sidebar').should('be.visible');
+    cy.get('.api-content').should('be.visible');
+    cy.get('.api-toc').should('be.visible');
+  });
+
+  it('collapses to single column on mobile', () => {
+    cy.viewport(375, 667);
+    cy.get('.sidebar').should('not.be.visible');
+    cy.get('.api-content').should('be.visible');
+  });
+});
+```
+
+### Tab Component Testing
+
+```javascript
+describe('Tab Navigation', () => {
+  beforeEach(() => {
+    cy.visit('/page/with/tabs/');
+  });
+
+  it('shows first tab content by default', () => {
+    cy.get('.tab-content').first().should('be.visible');
+    cy.get('.tab-content').eq(1).should('not.be.visible');
+  });
+
+  it('switches tab content on click', () => {
+    cy.get('.tabs a').eq(1).click();
+    cy.get('.tab-content').first().should('not.be.visible');
+    cy.get('.tab-content').eq(1).should('be.visible');
+  });
+
+  it('updates active tab styling', () => {
+    cy.get('.tabs a').eq(1).click();
+    cy.get('.tabs a').first().should('not.have.class', 'is-active');
+    cy.get('.tabs a').eq(1).should('have.class', 'is-active');
+  });
+});
+```
+
+### Scroll Behavior Testing
+
+```javascript
+describe('Table of Contents Scroll Sync', () => {
+  beforeEach(() => {
+    cy.visit('/page/with/toc/');
+  });
+
+  it('highlights current section in TOC on scroll', () => {
+    // Scroll to a specific section
+    cy.get('#section-two').scrollIntoView();
+
+    // Wait for scroll handler
+    cy.wait(100);
+
+    // Verify TOC highlight
+    cy.get('.toc-nav a[href="#section-two"]')
+      .should('have.class', 'is-active');
+  });
+
+  it('scrolls to section when TOC link clicked', () => {
+    cy.get('.toc-nav a[href="#section-three"]').click();
+    cy.get('#section-three').should('be.visible');
+  });
+});
+```
+
+## Common Testing Patterns
+
+### Waiting for Dynamic Content
+
+```javascript
+// Wait for element to appear
+cy.get('.dynamic-content', { timeout: 10000 }).should('exist');
+
+// Wait for network request
+cy.intercept('GET', '/api/data').as('getData');
+cy.wait('@getData');
+
+// Wait for animation
+cy.get('.animated-element').should('be.visible');
+cy.wait(300); // animation duration
+```
+
+### Testing Data Attributes
+
+```javascript
+it('component receives correct data', () => {
+  cy.get('[data-component="my-component"]')
+    .should('have.attr', 'data-items')
+    .and('not.be.empty')
+    .and('not.equal', '#ZgotmplZ');
+});
+```
+
+### Testing Accessibility
+
+```javascript
+describe('Accessibility', () => {
+  it('has proper ARIA attributes', () => {
+    cy.get('.expandable-header')
+      .should('have.attr', 'aria-expanded');
+    cy.get('.nav-item')
+      .should('have.attr', 'role', 'menuitem');
+  });
+
+  it('is keyboard navigable', () => {
+    cy.get('.nav-item').first().focus();
+    cy.focused().type('{downarrow}');
+    cy.focused().should('have.class', 'nav-item');
+  });
+});
+```
+
+### Testing Responsive Behavior
+
+```javascript
+const viewports = [
+  { name: 'mobile', width: 375, height: 667 },
+  { name: 'tablet', width: 768, height: 1024 },
+  { name: 'desktop', width: 1280, height: 800 },
+];
+
+viewports.forEach(({ name, width, height }) => {
+  describe(`${name} viewport`, () => {
+    beforeEach(() => {
+      cy.viewport(width, height);
+      cy.visit('/path/to/page/');
+    });
+
+    it('renders correctly', () => {
+      cy.get('.main-content').should('be.visible');
+    });
+  });
+});
+```
+
+## Debugging Failing Tests
+
+### Enable Debug Mode
+
+```javascript
+// Add .debug() to pause and inspect
+cy.get('.element').debug().should('be.visible');
+
+// Log intermediate values
+cy.get('.element').then($el => {
+  cy.log('Element classes:', $el.attr('class'));
+});
+```
+
+### Screenshot on Failure
+
+```javascript
+// Automatic (configure in cypress.config.js)
+screenshotOnRunFailure: true
+
+// Manual screenshot
+cy.screenshot('debug-state');
+```
+
+### Interactive Mode
+
+```bash
+# Open Cypress Test Runner for interactive debugging
+npx cypress open
+```
+
+### Common Issues
+
+**Timing Issues:**
+
+```javascript
+// Wrong - may fail due to timing
+cy.get('.element').click();
+cy.get('.result').should('exist');
+
+// Better - wait for element
+cy.get('.element').click();
+cy.get('.result', { timeout: 5000 }).should('exist');
+```
+
+**Element Not Interactable:**
+
+```javascript
+// Force click when element is covered
+cy.get('.element').click({ force: true });
+
+// Scroll into view first
+cy.get('.element').scrollIntoView().click();
+```
+
+**Stale Element Reference:**
+
+```javascript
+// Re-query element after DOM changes
+cy.get('.container').within(() => {
+  cy.get('.item').click();
+  cy.get('.item').should('have.class', 'active'); // Re-queries
+});
+```
+
+## Custom Commands
+
+### Creating Custom Commands
+
+```javascript
+// cypress/support/commands.js
+
+// Check page loads without errors
+Cypress.Commands.add('pageLoadsSuccessfully', () => {
+  cy.get('body').should('exist');
+  cy.get('.error-page').should('not.exist');
+});
+
+// Visit and wait for component
+Cypress.Commands.add('visitWithComponent', (url, component) => {
+  cy.visit(url);
+  cy.get(`[data-component="${component}"]`).should('exist');
+});
+
+// Expand all collapsible sections
+Cypress.Commands.add('expandAllSections', () => {
+  cy.get('[aria-expanded="false"]').each($el => {
+    cy.wrap($el).click();
+  });
+});
+```
+
+### Using Custom Commands
+
+```javascript
+describe('My Test', () => {
+  it('uses custom commands', () => {
+    cy.visitWithComponent('/api/', 'api-nav');
+    cy.expandAllSections();
+    cy.pageLoadsSuccessfully();
+  });
+});
+```
+
+## Test Data Management
+
+### Fixtures
+
+```json
+// cypress/fixtures/api-endpoints.json
+{
+  "endpoints": [
+    { "path": "/write", "method": "POST" },
+    { "path": "/query", "method": "GET" }
+  ]
+}
+```
+
+```javascript
+// Using fixtures
+cy.fixture('api-endpoints').then((data) => {
+  data.endpoints.forEach(endpoint => {
+    it(`documents ${endpoint.method} ${endpoint.path}`, () => {
+      cy.contains(`${endpoint.method} ${endpoint.path}`).should('exist');
+    });
+  });
+});
+```
+
+## Quality Checklist
+
+Before considering tests complete:
+
+- [ ] Tests cover main user flows
+- [ ] Tests are reliable (no flaky failures)
+- [ ] Appropriate timeouts for async operations
+- [ ] Meaningful assertions with clear failure messages
+- [ ] Tests organized by feature/component
+- [ ] Common patterns extracted to custom commands
+- [ ] Tests run successfully: `node cypress/support/run-e2e-specs.js --spec "path/to/test.cy.js" content/path.md`
+- [ ] No hardcoded waits (use cy.wait() with aliases or assertions)
+- [ ] Accessibility attributes tested where applicable
+
+## Communication Style
+
+- Report test results clearly (pass/fail counts)
+- Explain failure reasons and debugging steps
+- Suggest test coverage improvements
+- Recommend patterns for common scenarios
+- Ask for clarification on expected behavior when writing new tests
diff --git a/.claude/skills/docs-cli-workflow/SKILL.md b/.claude/skills/docs-cli-workflow/SKILL.md
new file mode 100644
index 000000000..a5d6e9866
--- /dev/null
+++ b/.claude/skills/docs-cli-workflow/SKILL.md
@@ -0,0 +1,133 @@
+---
+name: docs-cli-workflow
+description: Guides when to use docs create/edit CLI tools versus direct file editing for InfluxData documentation.
+author: InfluxData
+version: "1.0"
+---
+
+# docs CLI Workflow Guidance
+
+## Purpose
+
+Help recognize when to suggest `docs create` or `docs edit` CLI tools instead of direct file editing.
+These tools provide scaffolding, context gathering, and education about conventions that direct editing misses.
+
+## When This Skill Applies
+
+Check for these trigger keywords in user messages:
+
+- "new page", "new doc", "create documentation", "add a page"
+- "edit this URL", "edit <https://docs>", "update this page" (with a URL)
+- "document this feature", "write docs for"
+- "I have a draft", "from this draft"
+- Any docs.influxdata.com URL
+
+**Skip this skill when:**
+
+- User provides an explicit file path (e.g., "fix typo in content/influxdb3/...")
+- Small fixes (typos, broken links)
+- User says "just edit it" or similar
+- Frontmatter-only changes
+
+## Decision: Which Tool to Suggest
+
+### Suggest `docs create` when
+
+| Trigger                                | Why CLI is better                                         |
+| -------------------------------------- | --------------------------------------------------------- |
+| Content targets multiple products      | CLI scaffolds shared content pattern automatically        |
+| User unsure where page should live     | CLI analyzes structure, suggests location                 |
+| Draft references existing docs         | CLI extracts links, provides context to avoid duplication |
+| User seems unfamiliar with conventions | CLI prompt includes style guide, shortcode examples       |
+| Complex new feature documentation      | CLI gathers product metadata, version info                |
+
+### Suggest `docs edit` when
+
+| Trigger                                | Why CLI is better                                      |
+| -------------------------------------- | ------------------------------------------------------ |
+| User provides docs.influxdata.com URL  | CLI finds source file(s) including shared content      |
+| User doesn't know source file location | CLI maps URL to file path(s)                           |
+| Page uses shared content               | CLI identifies both frontmatter file AND shared source |
+
+### Edit directly when
+
+| Scenario                         | Why direct is fine              |
+| -------------------------------- | ------------------------------- |
+| User provides explicit file path | They already know where to edit |
+| Small typo/link fixes            | CLI overhead not worth it       |
+| User says "just edit it"         | Explicit preference to skip CLI |
+| Frontmatter-only changes         | No content generation needed    |
+
+## How to Suggest
+
+When a trigger is detected, present a concise recommendation and wait for confirmation.
+
+### For `docs create`
+
+```
+I'd recommend using the docs CLI for this:
+
+npx docs create <draft-path> --products <product>
+
+**Why**: [1-2 sentences explaining the specific benefit]
+
+Options:
+1. **Use CLI** - I'll run the command and guide you through product selection
+2. **Edit directly** - Skip the CLI, I'll create/edit files manually
+
+Which do you prefer?
+```
+
+### For `docs edit`
+
+```
+I can use the docs CLI to find the source files for this page:
+
+npx docs edit <url>
+
+**Why**: [1-2 sentences explaining the benefit]
+
+Options:
+1. **Use CLI** - I'll find and open the relevant files
+2. **I know the file** - Tell me the path and I'll edit directly
+
+Which do you prefer?
+```
+
+### Key principles
+
+- Show the actual command (educational)
+- Explain *why* for this specific case
+- Always offer the direct alternative
+- Keep it brief (4-6 lines max)
+- **Wait for user confirmation before running**
+
+## Edge Cases
+
+| Situation                           | Behavior                                                 |
+| ----------------------------------- | -------------------------------------------------------- |
+| Already in a `docs create` workflow | Don't re-suggest                                         |
+| URL points to non-existent page     | Suggest `docs create --url <url>` instead of `docs edit` |
+| User provides both URL and draft    | Suggest `docs create --url <url> --from-draft <draft>`   |
+| User declines CLI twice in session  | Stop suggesting, respect preference                      |
+
+## After User Confirms
+
+Run the appropriate command and let the CLI handle the rest.
+No additional guidance needed—the CLI manages product selection, file generation, and context gathering.
+
+## CLI Reference
+
+```bash
+# Create new documentation from a draft
+npx docs create <draft-path> --products <product-key>
+
+# Create at specific URL location
+npx docs create --url <url> --from-draft <draft-path>
+
+# Find and open files for an existing page
+npx docs edit <url>
+npx docs edit --list <url>  # List files without opening
+```
+
+For full CLI documentation, run `npx docs --help`.
diff --git a/.claude/skills/hugo-template-dev/SKILL.md b/.claude/skills/hugo-template-dev/SKILL.md
new file mode 100644
index 000000000..7139074f0
--- /dev/null
+++ b/.claude/skills/hugo-template-dev/SKILL.md
@@ -0,0 +1,555 @@
+---
+name: hugo-template-dev
+description: Hugo template development skill for InfluxData docs-v2. Enforces proper build and runtime testing to catch template errors that build-only validation misses.
+author: InfluxData
+version: "1.0"
+---
+
+# Hugo Template Development Skill
+
+## Purpose
+
+This skill enforces proper Hugo template development practices, including **mandatory runtime testing** to catch errors that static builds miss.
+
+## Critical Testing Requirement
+
+**Hugo's `npx hugo --quiet` only validates template syntax, not runtime execution.**
+
+Template errors like accessing undefined fields, nil values, or incorrect type assertions only appear when Hugo actually renders pages. You MUST test templates by running the server.
+
+## Mandatory Testing Protocol
+
+### For ANY Hugo Template Change
+
+After modifying files in `layouts/`, `layouts/partials/`, or `layouts/shortcodes/`:
+
+```bash
+# Step 1: Start Hugo server and capture output
+npx hugo server --port 1314 2>&1 | head -50
+```
+
+**Success criteria:**
+
+- No `error calling partial` messages
+- No `can't evaluate field` errors
+- No `template: ... failed` messages
+- Server shows "Web Server is available at <http://localhost:1314/>"
+
+**If errors appear:** Fix the template and repeat Step 1 before proceeding.
+
+```bash
+# Step 2: Verify the page renders (only after Step 1 passes)
+curl -s -o /dev/null -w "%{http_code}" http://localhost:1314/PATH/TO/PAGE/
+```
+
+**Expected:** HTTP 200 status code
+
+```bash
+# Step 3: Stop the test server
+pkill -f "hugo server --port 1314"
+```
+
+### Quick Test Command
+
+Use this one-liner to test and get immediate feedback:
+
+```bash
+timeout 15 npx hugo server --port 1314 2>&1 | grep -E "(error|Error|ERROR|fail|FAIL)" | head -20; pkill -f "hugo server --port 1314" 2>/dev/null
+```
+
+If output is empty, no errors were detected.
+
+## Common Hugo Template Errors
+
+### 1. Accessing Hyphenated Keys
+
+**Wrong:**
+
+```go
+{{ .Site.Data.article-data.influxdb }}
+```
+
+**Correct:**
+
+```go
+{{ index .Site.Data "article-data" "influxdb" }}
+```
+
+### 2. Nil Field Access
+
+**Wrong:**
+
+```go
+{{ range $articles }}
+  {{ .path }}  {{/* Fails if item is nil or wrong type */}}
+{{ end }}
+```
+
+**Correct:**
+
+```go
+{{ range $articles }}
+  {{ if . }}
+    {{ with index . "path" }}
+      {{ . }}
+    {{ end }}
+  {{ end }}
+{{ end }}
+```
+
+### 3. Type Assertion on Interface{}
+
+**Wrong:**
+
+```go
+{{ range $data }}
+  {{ .fields.menuName }}
+{{ end }}
+```
+
+**Correct:**
+
+```go
+{{ range $data }}
+  {{ if isset . "fields" }}
+    {{ $fields := index . "fields" }}
+    {{ if isset $fields "menuName" }}
+      {{ index $fields "menuName" }}
+    {{ end }}
+  {{ end }}
+{{ end }}
+```
+
+### 4. Empty Map vs Nil Check
+
+**Problem:** Hugo's `{{ if . }}` passes for empty maps `{}`:
+
+```go
+{{/* This doesn't catch empty maps */}}
+{{ if $data }}
+  {{ .field }}  {{/* Still fails if $data is {} */}}
+{{ end }}
+```
+
+**Solution:** Check for specific keys:
+
+```go
+{{ if and $data (isset $data "field") }}
+  {{ index $data "field" }}
+{{ end }}
+```
+
+## Hugo Data Access Patterns
+
+### Safe Nested Access
+
+```go
+{{/* Build up access with nil checks at each level */}}
+{{ $articleDataRoot := index .Site.Data "article-data" }}
+{{ if $articleDataRoot }}
+  {{ $influxdbData := index $articleDataRoot "influxdb" }}
+  {{ if $influxdbData }}
+    {{ $productData := index $influxdbData $dataKey }}
+    {{ if $productData }}
+      {{ with $productData.articles }}
+        {{/* Safe to use . here */}}
+      {{ end }}
+    {{ end }}
+  {{ end }}
+{{ end }}
+```
+
+### Iterating Over Data Safely
+
+```go
+{{ range $idx, $item := $articles }}
+  {{/* Declare variables with defaults */}}
+  {{ $path := "" }}
+  {{ $name := "" }}
+
+  {{/* Safely extract values */}}
+  {{ if isset $item "path" }}
+    {{ $path = index $item "path" }}
+  {{ end }}
+
+  {{ if $path }}
+    {{/* Now safe to use $path */}}
+  {{ end }}
+{{ end }}
+```
+
+## File Organization
+
+### Layouts Directory Structure
+
+```
+layouts/
+├── _default/           # Default templates
+├── partials/           # Reusable template fragments
+│   └── api/            # API-specific partials
+├── shortcodes/         # Content shortcodes
+└── TYPE/               # Type-specific templates (api/, etc.)
+    └── single.html     # Single page template
+```
+
+### Partial Naming
+
+- Use descriptive names: `api/sidebar-nav.html`, not `nav.html`
+- Group related partials in subdirectories
+- Include comments at the top describing purpose and required context
+
+## Separation of Concerns: Templates vs TypeScript
+
+**Principle:** Hugo templates handle structure and data binding. TypeScript handles behavior and interactivity.
+
+### What Goes Where
+
+| Concern          | Location                    | Example                             |
+| ---------------- | --------------------------- | ----------------------------------- |
+| HTML structure   | `layouts/**/*.html`         | Navigation markup, tab containers   |
+| Data binding     | `layouts/**/*.html`         | `{{ .Title }}`, `{{ range .Data }}` |
+| Static styling   | `assets/styles/**/*.scss`   | Layout, colors, typography          |
+| User interaction | `assets/js/components/*.ts` | Click handlers, scroll behavior     |
+| State management | `assets/js/components/*.ts` | Active tabs, collapsed sections     |
+| DOM manipulation | `assets/js/components/*.ts` | Show/hide, class toggling           |
+
+### Anti-Pattern: Inline JavaScript in Templates
+
+**Wrong - JavaScript mixed with template:**
+
+```html
+{{/* DON'T DO THIS */}}
+<nav class="api-nav">
+  {{ range $articles }}
+    <button onclick="toggleSection('{{ .id }}')">{{ .name }}</button>
+  {{ end }}
+</nav>
+
+<script>
+function toggleSection(id) {
+  document.getElementById(id).classList.toggle('is-open');
+}
+</script>
+```
+
+**Correct - Clean separation:**
+
+Template (`layouts/partials/api/sidebar-nav.html`):
+
+```html
+<nav class="api-nav" data-component="api-nav">
+  {{ range $articles }}
+    <button class="api-nav-group-header" aria-expanded="false">
+      {{ .name }}
+    </button>
+    <ul class="api-nav-group-items">
+      {{/* items */}}
+    </ul>
+  {{ end }}
+</nav>
+```
+
+TypeScript (`assets/js/components/api-nav.ts`):
+
+```typescript
+interface ApiNavOptions {
+  component: HTMLElement;
+}
+
+export default function initApiNav({ component }: ApiNavOptions): void {
+  const headers = component.querySelectorAll('.api-nav-group-header');
+
+  headers.forEach((header) => {
+    header.addEventListener('click', () => {
+      const isOpen = header.classList.toggle('is-open');
+      header.setAttribute('aria-expanded', String(isOpen));
+      header.nextElementSibling?.classList.toggle('is-open', isOpen);
+    });
+  });
+}
+```
+
+Register in `main.js`:
+
+```javascript
+import initApiNav from './components/api-nav.js';
+
+const componentRegistry = {
+  'api-nav': initApiNav,
+  // ... other components
+};
+```
+
+### Data Passing Pattern
+
+Pass Hugo data to TypeScript via `data-*` attributes:
+
+Template:
+
+```html
+<div
+  data-component="api-toc"
+  data-headings="{{ .headings | jsonify | safeHTMLAttr }}"
+  data-scroll-offset="80"
+>
+</div>
+```
+
+TypeScript:
+
+```typescript
+interface TocOptions {
+  component: HTMLElement;
+}
+
+interface TocData {
+  headings: string[];
+  scrollOffset: number;
+}
+
+function parseData(component: HTMLElement): TocData {
+  const headingsRaw = component.dataset.headings;
+  const headings = headingsRaw ? JSON.parse(headingsRaw) : [];
+  const scrollOffset = parseInt(component.dataset.scrollOffset || '0', 10);
+
+  return { headings, scrollOffset };
+}
+
+export default function initApiToc({ component }: TocOptions): void {
+  const data = parseData(component);
+  // Use data.headings and data.scrollOffset
+}
+```
+
+### Minimal Inline Scripts (Exception)
+
+The **only** acceptable inline scripts are minimal initialization that MUST run before component registration:
+
+```html
+{{/* Acceptable: Critical path, no logic, runs immediately */}}
+<script>
+  document.documentElement.dataset.theme =
+    localStorage.getItem('theme') || 'light';
+</script>
+```
+
+Everything else belongs in `assets/js/`.
+
+### File Organization for Components
+
+```
+assets/
+├── js/
+│   ├── main.js                    # Entry point, component registry
+│   ├── components/
+│   │   ├── api-nav.ts             # API navigation behavior
+│   │   ├── api-toc.ts             # Table of contents
+│   │   ├── api-tabs.ts            # Tab switching (if needed beyond CSS)
+│   │   └── api-scalar.ts          # Scalar/RapiDoc integration
+│   └── utils/
+│       └── dom-helpers.ts         # Shared DOM utilities
+└── styles/
+    └── layouts/
+        └── _api-layout.scss       # API-specific styles
+```
+
+### TypeScript Component Checklist
+
+When creating a new interactive feature:
+
+1. [ ] Create TypeScript file in `assets/js/components/`
+2. [ ] Define interface for component options
+3. [ ] Export default initializer function
+4. [ ] Register in `main.js` componentRegistry
+5. [ ] Add `data-component` attribute to HTML element
+6. [ ] Pass data via `data-*` attributes (not inline JS)
+7. [ ] Write Cypress tests for the component
+8. [ ] **NO inline `<script>` tags in templates**
+
+## Debugging Templates
+
+### Enable Verbose Mode
+
+```bash
+npx hugo server --port 1314 --verbose 2>&1 | head -100
+```
+
+### Print Variables for Debugging
+
+```go
+{{/* Temporary debugging - REMOVE before committing */}}
+<pre>{{ printf "%#v" $myVariable }}</pre>
+```
+
+### Check Data File Loading
+
+```bash
+# Verify data files exist and are valid YAML
+cat data/article-data/influxdb/influxdb3-core/articles.yml | head -20
+```
+
+## Integration with CI/CD
+
+### Pre-commit Hook (Recommended)
+
+Add to `.lefthook.yml` or pre-commit configuration:
+
+```yaml
+pre-commit:
+  commands:
+    hugo-template-test:
+      glob: "layouts/**/*.html"
+      run: |
+        timeout 20 npx hugo server --port 1314 2>&1 | grep -E "error|Error" && exit 1 || exit 0
+        pkill -f "hugo server --port 1314" 2>/dev/null
+```
+
+### GitHub Actions Workflow
+
+```yaml
+- name: Test Hugo templates
+  run: |
+    npx hugo server --port 1314 &
+    sleep 10
+    curl -f http://localhost:1314/ || exit 1
+    pkill -f hugo
+```
+
+### Cypress E2E Tests for UI Features
+
+After template changes that affect UI functionality, run Cypress tests to verify:
+
+**Run a specific test file against a content page:**
+
+```bash
+node cypress/support/run-e2e-specs.js \
+  --spec "cypress/e2e/content/api-reference.cy.js" \
+  content/influxdb3/core/reference/api/_index.md
+```
+
+**Run tests against a URL (for deployed or running server):**
+
+```bash
+node cypress/support/run-e2e-specs.js \
+  --spec "cypress/e2e/content/api-reference.cy.js" \
+  http://localhost:<port>/influxdb3/core/reference/api/
+```
+
+**Example Cypress test structure for API reference:**
+
+```javascript
+// cypress/e2e/content/api-reference.cy.js
+describe('API Reference Documentation', () => {
+  beforeEach(() => {
+    cy.visit('/influxdb3/core/reference/api/');
+  });
+
+  it('displays 3-column layout with sidebar, content, and TOC', () => {
+    cy.get('.sidebar').should('be.visible');
+    cy.get('.api-content').should('be.visible');
+    cy.get('.api-toc').should('be.visible');
+  });
+
+  it('switches tabs correctly', () => {
+    cy.get('.tabs a').contains('Authentication').click();
+    cy.get('.tab-content').contains('Bearer Token').should('be.visible');
+  });
+
+  it('displays API navigation in sidebar', () => {
+    cy.get('.api-nav').should('be.visible');
+    cy.get('.api-nav').contains('API v3');
+  });
+
+  it('TOC updates highlight on scroll', () => {
+    cy.get('.api-toc-nav a').first().click();
+    cy.get('.api-toc-nav a.is-active').should('exist');
+  });
+});
+```
+
+**Check for JavaScript console errors (common pattern for feature development):**
+
+```javascript
+// cypress/e2e/content/my-component.cy.js
+describe('My Component', () => {
+  it('should not throw JavaScript console errors', () => {
+    cy.visit('/path/to/page/');
+
+    // Wait for component to initialize
+    cy.get('[data-component="my-component"]', { timeout: 5000 })
+      .should('be.visible');
+
+    cy.window().then((win) => {
+      const logs = [];
+      const originalError = win.console.error;
+
+      // Intercept console.error calls
+      win.console.error = (...args) => {
+        logs.push(args.join(' '));
+        originalError.apply(win.console, args);
+      };
+
+      // Allow time for async operations
+      cy.wait(2000);
+
+      cy.then(() => {
+        // Filter for relevant errors (customize for your component)
+        const relevantErrors = logs.filter(
+          (log) =>
+            log.includes('my-component') ||
+            log.includes('Failed to parse') ||
+            log.includes('is not a function')
+        );
+        expect(relevantErrors).to.have.length(0);
+      });
+    });
+  });
+});
+```
+
+This pattern is especially useful for catching:
+
+- TypeScript/JavaScript runtime errors in components
+- JSON parsing failures from `data-*` attributes
+- Undefined function calls from missing imports
+- Template data binding issues that only manifest at runtime
+
+**Integrate Cypress into development workflow:**
+
+1. Create test file in `cypress/e2e/content/` for your feature
+2. Run tests after template changes to verify UI behavior
+3. Include test execution in PR checklist
+
+**Quick Cypress commands:**
+
+| Purpose                | Command                                                                                     |
+| ---------------------- | ------------------------------------------------------------------------------------------- |
+| Run specific spec      | `node cypress/support/run-e2e-specs.js --spec "path/to/spec.cy.js" content/path/to/page.md` |
+| Run all E2E tests      | `yarn test:e2e`                                                                             |
+| Run shortcode examples | `yarn test:shortcode-examples`                                                              |
+
+## Quick Reference
+
+| Action                    | Command                                                              |
+| ------------------------- | -------------------------------------------------------------------- |
+| Test templates (runtime)  | `npx hugo server --port 1314 2>&1 \| head -50`                       |
+| Build only (insufficient) | `npx hugo --quiet`                                                   |
+| Check specific page       | `curl -s -o /dev/null -w "%{http_code}" http://localhost:1314/path/` |
+| Stop test server          | `pkill -f "hugo server --port 1314"`                                 |
+| Debug data access         | `<pre>{{ printf "%#v" $var }}</pre>`                                 |
+
+## Remember
+
+1. **Never trust `npx hugo --quiet` alone** - it only checks syntax
+2. **Always run the server** to test template changes
+3. **Check error output first** before declaring success
+4. **Use `isset` and `index`** for safe data access
+5. **Hyphenated keys require `index` function** - dot notation fails
+
+## Related Agents
+
+This skill focuses on Hugo template development practices. For specialized tasks, use:
+
+- **hugo-ui-dev** - Hugo templates and SASS/CSS styling
+- **ts-component-dev** - TypeScript component behavior and interactivity
+- **ui-testing** - Cypress E2E testing for UI components
diff --git a/docs/plans/2025-01-10-docs-cli-workflow-design.md b/docs/plans/2025-01-10-docs-cli-workflow-design.md
new file mode 100644
index 000000000..1aba665c9
--- /dev/null
+++ b/docs/plans/2025-01-10-docs-cli-workflow-design.md
@@ -0,0 +1,134 @@
+# docs-cli-workflow Skill Design
+
+## Overview
+
+A Claude Code skill that guides when to use `docs create` and `docs edit` CLI tools versus direct file editing for InfluxData documentation.
+
+## Problem
+
+Claude under-utilizes the `docs create` and `docs edit` CLI tools even when they would provide significant value:
+
+- Better scaffolding for multi-product content
+- Context gathering (link extraction, structure analysis)
+- Education about style guidelines and shortcodes
+- Automatic file location from URLs
+
+## Skill Identity
+
+- **Name**: `docs-cli-workflow`
+- **Location**: `.claude/skills/docs-cli-workflow/SKILL.md`
+- **Scope**: Decision guidance only (not full workflow management)
+- **Behavior**: Suggest and wait for user confirmation
+
+## Activation
+
+### Trigger Keywords
+
+The skill activates when user messages contain:
+
+- "new page", "new doc", "create documentation", "add a page"
+- "edit this URL", "edit <https://docs>", "update this page" (with URL)
+- "document this feature", "write docs for"
+- "I have a draft", "from this draft"
+- References to docs.influxdata.com URLs
+
+### Non-Triggers (Direct Editing is Fine)
+
+- "fix this typo in content/..."
+- "update the frontmatter in..."
+- Explicit file paths the user already knows
+- Small edits to existing files user has open
+
+## Decision Logic
+
+### When to Suggest `docs create`
+
+| Trigger                            | Why CLI is Better                                         |
+| ---------------------------------- | --------------------------------------------------------- |
+| Content targets multiple products  | CLI scaffolds shared content pattern automatically        |
+| User unsure where page should live | CLI analyzes structure, suggests location                 |
+| Draft references existing docs     | CLI extracts links, provides context to avoid duplication |
+| User unfamiliar with conventions   | CLI prompt includes style guide, shortcode examples       |
+| Complex new feature documentation  | CLI gathers product metadata, version info                |
+
+### When to Suggest `docs edit`
+
+| Trigger                                | Why CLI is Better                                      |
+| -------------------------------------- | ------------------------------------------------------ |
+| User provides docs.influxdata.com URL  | CLI finds source file(s) including shared content      |
+| User doesn't know source file location | CLI maps URL → file path(s)                            |
+| Page uses shared content               | CLI identifies both frontmatter file AND shared source |
+
+### When to Skip CLI (Edit Directly)
+
+| Scenario                         | Why Direct is Fine              |
+| -------------------------------- | ------------------------------- |
+| User provides explicit file path | They already know where to edit |
+| Small typo/link fixes            | Overhead not worth it           |
+| User says "just edit it"         | Explicit preference             |
+| Frontmatter-only changes         | No content generation needed    |
+
+## Suggestion Format
+
+### For `docs create`
+
+```
+I'd recommend using the docs CLI for this:
+
+npx docs create <draft-path> --products <product>
+
+**Why**: [1-2 sentences explaining the specific benefit for this request]
+
+Options:
+1. **Use CLI** - I'll run the command and guide you through product selection
+2. **Edit directly** - Skip the CLI, I'll create/edit files manually
+
+Which do you prefer?
+```
+
+### For `docs edit`
+
+```
+I can use the docs CLI to find the source files for this page:
+
+npx docs edit <url>
+
+**Why**: [1-2 sentences - e.g., "This will locate the source file and any shared content it uses"]
+
+Options:
+1. **Use CLI** - I'll find and open the relevant files
+2. **I know the file** - Tell me the path and I'll edit directly
+
+Which do you prefer?
+```
+
+### Principles
+
+- Show the actual command (educational)
+- Explain *why* for this specific case
+- Always offer the direct alternative
+- Keep it brief - 4-6 lines max
+
+## Edge Cases
+
+| Edge Case                                | Behavior                                               |
+| ---------------------------------------- | ------------------------------------------------------ |
+| User already in a `docs create` workflow | Don't re-suggest                                       |
+| URL points to non-existent page          | Suggest `docs create --url` instead of `docs edit`     |
+| User provides both URL and draft         | Suggest `docs create --url <url> --from-draft <draft>` |
+| User declines CLI twice in session       | Stop suggesting, note preference                       |
+
+## Post-Confirmation Behavior
+
+After user confirms they want to use the CLI:
+
+1. Run the appropriate command
+2. Let the CLI handle the rest (product selection, file generation, etc.)
+3. No additional skill guidance needed
+
+## Related Files
+
+- `scripts/docs-cli.js` - Main CLI entry point
+- `scripts/docs-create.js` - Content scaffolding implementation
+- `scripts/docs-edit.js` - File finder implementation
+- `scripts/lib/content-scaffolding.js` - Context preparation logic