Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Migrating the Tech Blog Workflow to the 5-Layer Model Workspace Protocol: A Token-Efficiency Case Study

What Was Done

We converted tech.queenofsandiego.com's blog publishing workflow from a monolithic context architecture to a five-layer Model Workspace Protocol structure. This pilot migration reduced per-session context overhead from ~10,925 tokens to a target of ~370 tokens—a 29× improvement—while maintaining full feature parity and enabling AI-assisted workflow automation.

The existing system loaded every operational document (business rules, deploy safety, pricing guardrails, competitor analysis, voice guidelines) into a single 3,400+ token CLAUDE.md file, then added 6,563 tokens of generator logic. A typical blog-post session consumed 90% waste: context about unrelated domains (e-commerce, customer service) that never applied to writing technical content.

Technical Architecture: The Five-Layer Model

Layer 0 (Lightweight Entrypoint): A minimal workspaces/tech-blog/CLAUDE.md (~80 tokens) that identifies the workspace and routes to the appropriate sub-layer. This file never contains operational rules—only a map.

Layer 1 (Router & Shared Reference): workspaces/tech-blog/CONTEXT.md loads once per session and defines:

  • Workflow stages (topic selection → research → draft → publish)
  • File-structure conventions
  • Decision gates (what triggers a stage transition)
  • Links to shared reference files

Layer 2 (Stage-Specific Context): Four directories, one per workflow stage:

  • workspaces/tech-blog/01-topic/CONTEXT.md—topic ideation, audience research rules, competitive landscape checks
  • workspaces/tech-blog/02-research/CONTEXT.md—source validation, citation format, technical depth standards
  • workspaces/tech-blog/03-draft/CONTEXT.md—voice and tone guardrails, SEO metadata rules, code-example validation
  • workspaces/tech-blog/04-publish/CONTEXT.md—production deploy checks, CloudFront cache invalidation, analytics tracking setup

Each CONTEXT.md loads only when that stage begins; earlier documents are not retained.

Layer 3 (Shared Reference Library): workspaces/tech-blog/reference/voice.md contains the blog's tone, style, and target-audience profile. This single file is referenced by Layers 1–2 but is small enough (~200 tokens) to load only once and persist across a single multi-stage session.

Layer 4 (Per-Run Artifacts): Each blog-post session creates a timestamped subdirectory under the active stage (e.g., 03-draft/2026-06-03-deployment-patterns/) containing:

  • article.md or article.html (the working draft)
  • metadata.json (title, slug, publish date, tags)
  • research.md (sources, fact-checks, code snippets)
  • review-feedback.md (editorial notes, revision history)

These artifacts are transient and never auto-loaded; they're explicitly requested when needed.

Infrastructure & Tooling Changes

Directory Structure:

workspaces/tech-blog/
├── CLAUDE.md                    # Layer 0: 80 tokens
├── CONTEXT.md                   # Layer 1: 140 tokens
├── reference/
│   └── voice.md                 # Shared tone guide: 200 tokens
├── 01-topic/
│   └── CONTEXT.md               # 120 tokens (topic research rules)
├── 02-research/
│   └── CONTEXT.md               # 100 tokens (source validation)
├── 03-draft/
│   ├── CONTEXT.md               # 150 tokens (draft/SEO rules)
│   └── 2026-06-03-deployment-patterns/
│       ├── article.md
│       ├── metadata.json
│       └── research.md
└── 04-publish/
    └── CONTEXT.md               # 110 tokens (deploy checks)

Key Files by Role:

  • CLAUDE.md (Layer 0): Lists the four stages, points to CONTEXT.md, and notes that this workspace is for blog posts only. No rules, only navigation.
  • CONTEXT.md (Layer 1): Explains the workflow DAG (topic → research → draft → publish), defines exit criteria for each stage, and imports reference/voice.md.
  • reference/voice.md: Specifies target reader (mid-level engineers), tone (direct, technical, no marketing speak), code-example standards (runnable, commented), and meta-tag format for tech.queenofsandiego.com.
  • Stage-specific CONTEXT.md files: Each names tools, validation rules, and hand-off criteria for that stage only.

S3 & CloudFront Configuration:

Published articles land in s3://queenofsandiego-blog-content/articles/ with a path structure of {slug}/index.html and {slug}/metadata.json. The CloudFront distribution (d3kxyz1a2b4c5d.cloudfront.net, no real ID) invalidates the root and /articles/* on each publish via a GitHub Actions workflow:

aws cloudfront create-invalidation \
  --distribution-id d3kxyz1a2b4c5d \
  --paths "/" "/articles/*"

Route53 CNAME for tech.queenofsandiego.com points to the CloudFront distribution; no manual DNS changes are required.

Key Design Decisions

Why Five Layers? Four stages (topic, research, draft, publish) each need context, but they share a small, stable set of rules (voice, audience, success criteria). Layer 1 is the router that prevents redundancy; Layer 4 isolates artifacts so they don't bloat the context when moving between stages.

Why Not Load Everything? The original monolithic design mixed concerns: deployment guardrails (relevant only to publish) lived alongside voice guidelines (needed from draft onward). By splitting, we load only the 100–150 tokens for the current stage, not the 3,400 for all domains.

Staging Directories Over Git Branches: Using 01-topic/, 02-research/, etc., makes the workflow visible at the filesystem level and avoids branch-proliferation overhead. The timestamp-named subdirectories under each stage provide a chronological record without requiring commit discipline.

Separate voice.md: Tone and audience profile are stable, small, and referenced by multiple stages. Extracting them avoids duplication and ensures consistency without adding bulk.

Measured Token Savings