```html

Building an Auto-Generated Technical Blog System Across Four Domain Properties

Overview

This session implemented a comprehensive technical documentation system that auto-generates detailed blog posts from Claude Code development sessions. The system captures granular technical work across four distinct domain properties: queenofsandiego.com, sailjada.com, dangerouscentaur.com, and burialsatseasandiego.com, publishing to corresponding tech subdomains with zero manual intervention.

What Was Done

  • Created tech_blog_generator.py — a Python tool that parses Claude Code session transcripts (JSONL format) and generates HTML blog posts with technical detail
  • Created tech_blog_init.py — infrastructure-as-code script that provisions S3 buckets, CloudFront distributions, and DNS records for four tech blogs
  • Created tech_blog_stop.sh — a Claude Code Stop hook that automatically invokes the generator at session end
  • Updated ~/.claude/settings.json to register the Stop hook
  • Updated navigation menus across all four properties to link to their respective tech blogs from the "Ship's Papers" section
  • Provisioned infrastructure with proper SSL/TLS termination and content delivery optimization

Technical Architecture

Session Capture and Processing

Claude Code stores development session transcripts as JSONL (newline-delimited JSON) files in ~/.claude/projects/. Each line contains metadata about the session step: file modifications, command execution, tool usage, and user messages. The generator parses this raw transcript and extracts:

  • File Operations: Exact paths written/edited with context
  • Commands Executed: Full command text (shell, API calls, infrastructure commands)
  • Tool Usage: What external tools were invoked and why
  • Decision Rationale: User messages explaining "why" at each step

The generator filters out sensitive data patterns: API keys, passwords, tokens, credential files, and personal identifiers. It preserves infrastructure identifiers (S3 bucket names, CloudFront distribution IDs, Route53 zone IDs, ACM certificate ARNs) because these are non-sensitive and essential for technical documentation.

Blog Generation Pipeline

The tech_blog_generator.py script:

  1. Reads the project memory file to determine which domain(s) were worked on in the session
  2. Parses the session transcript JSONL file
  3. Groups work by category: infrastructure, code changes, deployment, configuration
  4. Generates structured HTML with semantic headings and code blocks
  5. Uploads the post to the appropriate S3 bucket (e.g., qos-tech-blog for queenofsandiego.com)
  6. Invalidates the CloudFront distribution cache to serve fresh content immediately

The Stop hook (tech_blog_stop.sh) runs automatically when a Claude Code session ends, making the entire process invisible to the user.

Infrastructure Provisioning

S3 Buckets

Four S3 buckets were created with consistent naming:

  • qos-tech-blog — Tech blog for queenofsandiego.com
  • jada-tech-blog — Tech blog for sailjada.com
  • dc-tech-blog — Tech blog for dangerouscentaur.com
  • bats-tech-blog — Tech blog for burialsatseasandiego.com

All buckets are configured as static website origins with block-all-public-access enabled. Public access is controlled exclusively through CloudFront distributions, which enforce HTTPS.

CloudFront Distributions

Three new CloudFront distributions were created for QOS, JADA, and BATS. Each distribution:

  • Points to its respective S3 bucket as the origin
  • Uses a wildcard ACM certificate already provisioned (e.g., *.queenofsandiego.com)
  • Has HTTP-to-HTTPS redirect enabled
  • Caches content with a 1-hour TTL to balance freshness with performance
  • Uses the S3 bucket REST endpoint as the origin (e.g., qos-tech-blog.s3.us-west-2.amazonaws.com)

For dangerouscentaur.com, the tech blog was integrated into the existing wildcard CloudFront distribution (Distribution ID: E2Q4UU71SRNTMB) that already serves the main site from the dc-sites S3 bucket. A second origin was added for dc-tech-blog with path-based routing (/tech/*) to avoid distribution multiplication.

DNS Configuration

DNS setup differed by registrar:

  • Route53-managed domains (queenofsandiego.com, sailjada.com): Created CNAME records pointing tech.[domain] to the CloudFront distribution domain name (e.g., d1234567890abc.cloudfront.net)
  • GoDaddy-managed domain (burialsatseasandiego.com): Used GoDaddy API to create CNAME records for tech.burialsatseasandiego.com → CloudFront domain
  • Namecheap-managed domain (dangerouscentaur.com): Created CNAME via Namecheap API for path-based routing to existing distribution

SSL/TLS Certificates

Wildcard certificates were already provisioned in ACM:

  • *.queenofsandiego.com — covers tech.queenofsandiego.com
  • *.sailjada.com — covers tech.sailjada.com
  • dangerouscentaur.com wildcard — existing
  • burialsatseasandiego.com — new certificate requested with DNS validation via GoDaddy

Certificate validation records were automatically added to respective DNS providers during infrastructure initialization.

Integration with Existing Sites

Updated navigation menus on all four properties to expose the tech blog:

  • /Users/cb/Documents/repos/sites/queenofsandiego.com/index.html — Added link in Ship's Papers dropdown
  • /Users/cb/Documents/repos/sites/sailjada.com/index.html — Similar menu integration
  • /Users/cb/Documents/repos/sites/dangerouscentaur.com/index.html — Added to Ship's Papers
  • /Users/cb/Documents/repos/