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.jsonto 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:
- Reads the project memory file to determine which domain(s) were worked on in the session
- Parses the session transcript JSONL file
- Groups work by category: infrastructure, code changes, deployment, configuration
- Generates structured HTML with semantic headings and code blocks
- Uploads the post to the appropriate S3 bucket (e.g.,
qos-tech-blogfor queenofsandiego.com) - 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.comjada-tech-blog— Tech blog for sailjada.comdc-tech-blog— Tech blog for dangerouscentaur.combats-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 pointingtech.[domain]to the CloudFront distribution domain name (e.g.,d1234567890abc.cloudfront.net) - GoDaddy-managed domain (
burialsatseasandiego.com): Used GoDaddy API to create CNAME records fortech.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— coverstech.queenofsandiego.com*.sailjada.com— coverstech.sailjada.comdangerouscentaur.comwildcard — existingburialsatseasandiego.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/