Building a Multi-Site Technical Blog Pipeline with Auto-Generation from Claude Sessions

```html

This session implemented a comprehensive technical documentation system that automatically generates detailed blog posts from development work across four distinct sites: queenofsandiego.com, dangerouscentaur.com, sailjada.com, and burialsatseasandiego.com. The system captures granular technical details from Claude Code sessions and publishes them to dedicated tech subdomains without exposing credentials.

Core Architecture

The solution consists of three primary components:

Session Capture Hook (/Users/cb/.claude/hooks/tech_blog_stop.sh): Executes when a Claude Code session ends, extracting session transcript data
Blog Generator (/Users/cb/Documents/repos/tools/tech_blog_generator.py): Parses session transcripts, extracts tool use and file modifications, generates HTML posts
Infrastructure Initializer (/Users/cb/Documents/repos/tools/tech_blog_init.py): Provisions S3 buckets, CloudFront distributions, and DNS records for each tech blog

This architecture decouples session capture from infrastructure management, allowing future enhancements without disrupting the publishing pipeline.

Infrastructure Provisioning

The tech blog system required establishing separate S3+CloudFront+DNS infrastructure for each site:

queenofsandiego.com tech blog: S3 bucket qos-tech-blog, CloudFront distribution, Route53 CNAME record pointing tech.queenofsandiego.com to CloudFront endpoint
sailjada.com tech blog: S3 bucket jada-tech-blog, CloudFront distribution with existing wildcard certificate *.sailjada.com, Route53 DNS record
dangerouscentaur.com tech blog: Leveraged existing wildcard CloudFront distribution (E2Q4UU71SRNTMB) on dc-sites S3 bucket; added tech.dangerouscentaur.com as additional CNAME via Namecheap DNS
burialsatseasandiego.com tech blog: S3 bucket bats-tech-blog, new CloudFront distribution, GoDaddy DNS nameserver management with ACM certificate DNS validation

The decision to create dedicated S3+CloudFront stacks for three sites while reusing the existing dangerouscentaur wildcard distribution balanced operational consistency with resource efficiency. Burialsatseasandiego required special handling because its DNS is managed by GoDaddy rather than Route53, necessitating manual ACM validation record creation.

Session Transcript Processing

The blog generator parses Claude Code session transcripts stored in JSONL format at /Users/cb/.claude/projects/-Users-cb-Documents-repos/sessions/. Each line is a JSON object containing interaction metadata including tool use blocks for file operations, command executions, and agent reasoning.

The extraction pipeline identifies:

File write/edit operations with exact paths
Executed commands and their purposes
Tool invocations including S3, CloudFront, Route53, and DNS operations
Agent reasoning that explains architectural decisions

A critical security filter removes entries containing credential patterns (passwords, API keys, tokens, database connection strings) before content generation. This ensures technical granularity without exposing sensitive data.

Navigation Integration

Each primary site's index.html received a new navigation link in the "Ship's Papers" dropdown menu pointing to its respective tech blog. For queenofsandiego.com, the link appears as:

<li><a href="https://tech.queenofsandiego.com">Technical Blog</a></li>

This decision placed the tech blog at equivalent navigation weight to other operational documentation, signaling to stakeholders (particularly Sergio) that technical transparency is a first-class concern.

Certificate and SSL/TLS Strategy

Three sites benefited from existing AWS Certificate Manager wildcard certificates:

*.queenofsandiego.com wildcard cert (already provisioned)
*.sailjada.com wildcard cert (already provisioned)
*.dangerouscentaur.com wildcard cert (used by existing CloudFront dist)

Burialsatseasandiego.com required new certificate provisioning since it's a different domain. ACM validation records were created via GoDaddy API, validating ownership before CloudFront could serve HTTPS traffic.

Infrastructure Configuration Persistence

The initialization process generates and stores a configuration file at /Users/cb/.claude/projects/-Users-cb-Documents-repos/memory/project_tech_blogs.md documenting:

S3 bucket names and regions
CloudFront distribution IDs and behaviors
DNS CNAME mappings and nameserver information
Certificate ARNs and validation statuses

This persistent record enables the Stop hook to reference correct deployment targets without hardcoding.

Session Hook Integration

The Stop hook script was registered in /Users/cb/.claude/settings.json under the hooks configuration, executing automatically after each session completes. The hook:

Retrieves the most recent session transcript from the sessions directory
Invokes the blog generator with the transcript path and source site identifier
Captures generator output (HTML post content) and metadata
Uploads the generated HTML to the appropriate S3 bucket via AWS CLI
Invalidates the CloudFront cache to ensure immediate visibility
Logs all operations for debugging and audit purposes to /Users/cb/.claude/logs/tech_blog_generation.log

Deployment Verification

The implementation was tested by running the generator against the current session transcript. The resulting post was uploaded to qos-tech-blog S3 bucket at key 2024-01-15-session-infrastructure-setup.html, with CloudFront invalidation on path /* completing within seconds. HTTP access to tech.queenofsandiego.com returned the generated content with correct MIME type and caching headers.

Technical Decisions and Trade-offs

Why generate from transcripts instead of custom logging? Transcripts already contain complete session data including agent reasoning, failed attempts, and corrections. Building a new logging layer would duplicate existing information and create maintenance burden. Transcript-based generation ensures every detail is captured automatically.

Why separate S3 buckets instead of one bucket with path prefixes? Separate buckets provide independent CloudFront behaviors, cache invalidation strategies, and potential for different retention policies per site. They also simplify future migration if any site transitions to a different infrastructure provider.

Why leverage existing wildcard distributions? Dangerouscentaur already had a functioning CloudFront distribution. Rather than create duplicate infrastructure, adding a CNAME alias proved more efficient and maintained consistency with existing TLS certificates.