Queen of San Diego — Tech Blog

Under the hood at queenofsandiego.com

```html

Implementing the 5-Layer Model Workspace Protocol: Tech Blog Migration Pilot

What Was Done

We converted the tech.queenofsandiego.com blog publishing workflow from a monolithic context structure into a 5-layer Model Workspace Protocol implementation. This pilot migration reduces token overhead by ~97% (from ~10,925 tokens to a target of ~370 tokens per session) while improving workflow isolation, reusability, and maintainability.

The existing workflow suffered from a classic context bloat problem: the root /repos/sites/queenofsandiego.com/CLAUDE.md file mixed strategic guidance (Layer 0), operational procedures (Layer 1), business rules (Layer 2), and implementation details (Layer 3) into a single 6,563-token artifact that loaded entirely on every interaction—even when only drafting a single post outline.

Technical Architecture

The new structure implements a hierarchical, stage-gated context system:

workspaces/tech-blog/
├── CLAUDE.md                    # Layer 0: Map only (~80 tokens)
├── CONTEXT.md                   # Layer 1: Router & entry point
├── reference/
│   ├── voice.md                 # Tone, audience, brand guidelines
│   └── [other shared refs]
├── 01-topic/
│   └── CONTEXT.md               # Layer 2: Topic discovery rules
├── 02-research/
│   └── CONTEXT.md               # Layer 2: Research methodology
├── 03-draft/
│   └── CONTEXT.md               # Layer 2: Draft composition rules
└── 04-publish/
    └── CONTEXT.md               # Layer 2: Publishing & CI/CD

Why this structure:

  • Layer 0 (CLAUDE.md) — A 10-line map pointing to CONTEXT.md. This never changes and loads once per workspace initialization.
  • Layer 1 (CONTEXT.md) — The main entry point. Loads the current stage's Layer-2 context on demand and explains the workflow DAG (topic → research → draft → publish).
  • Layer 2 (per-stage CONTEXT.md) — Stage-specific rules loaded only when entering that stage. Topic discovery loads completely different instructions than draft composition.
  • Layer 3+ — Reference materials (voice.md, competitor analysis, deployment docs) stay in reference/ and are linked, not auto-loaded.

File Organization & Artifacts

Each stage directory holds both instructions and per-run artifacts:

# Stage 1: Topic selection
01-topic/
├── CONTEXT.md                   # Discovery workflow
├── 2026-06-topic-brainstorm.md  # Session output
└── 2026-06-selected.md          # Decision record

# Stage 2: Research gathering
02-research/
├── CONTEXT.md                   # Source evaluation rules
├── 2026-06-sources.md           # Collected references
└── 2026-06-outline.md           # Structured outline

# Stage 3: Writing & revision
03-draft/
├── CONTEXT.md                   # Composition & style rules
├── 2026-06-draft.md             # Working draft
└── 2026-06-feedback.md          # Review notes

# Stage 4: Publishing
04-publish/
├── CONTEXT.md                   # Deploy & CI/CD rules
├── 2026-06-final.md             # Approved version
└── 2026-06-deploy.log           # Build output

This layout creates a natural audit trail. Each stage's output becomes the next stage's input, and all decisions are recorded in place.

Infrastructure & Deployment Integration

The blog publishes to tech.queenofsandiego.com via:

  • GitHub Pages source repo: /repos/sites/queenofsandiego.com/
  • Posts directory: _posts/ (Jekyll convention, YAML frontmatter + Markdown)
  • Build trigger: Commit to main → GitHub Actions → Jekyll build → auto-publish
  • CDN distribution: CloudFront in front of the Pages endpoint (ID stored in deploy-safety.md, not hardcoded)
  • DNS: Route53 CNAME pointing to CloudFront distribution

The 04-publish/CONTEXT.md stage documents the exact Git workflow:

# Command sequence for publishing (from deploy-safety.md reference):
cd /repos/sites/queenofsandiego.com
git checkout -b publish/2026-06-topic-slug
cp draft-file _posts/YYYY-MM-DD-slug.md
git add _posts/
git commit -m "Publish: descriptive title"
git push origin publish/2026-06-topic-slug
# → Open PR, merge to main
# → GitHub Actions auto-triggers Jekyll build
# → Pages + CloudFront refresh completes in ~60 seconds

Context Sizing & Token Economics

Before (monolithic):

  • Root CLAUDE.md: 6,563 tokens
  • QoS global CLAUDE.md auto-load: 3,420 tokens
  • Generator script context: 942 tokens
  • Total per session: ~10,925 tokens (90% waste)

After (5-layer protocol):

  • Layer 0 map: ~80 tokens
  • Layer 1 router: ~140 tokens
  • Current stage's Layer-2: ~100–150 tokens (varies by stage)
  • Voice.md reference: ~50 tokens
  • Target total: ~370 tokens (30× reduction)

This is measured before any build. The actual post-build validation will confirm real token usage under actual Claude session conditions.

Key Design Decisions

1. Stage-gated architecture, not role-based
We chose workflow stages (topic → research → draft → publish) over role-based contexts (writer, editor, reviewer) because the blog pipeline is sequential and deterministic. A given session operates in exactly one stage; loading all role contexts would recreate the bloat we're solving for.

2. Per-run artifacts in stage directories
Timestamped files (e.g., 2026-06-topic-brainstorm.md) live alongside instructions rather than in a separate archive. This keeps the full context of a session (prompt + output + feedback) in one place, reducing context-switching when iterating.

3. Reference layer stays unloaded by default
Voice guidelines, competitor analysis, and deployment docs go in reference/ and are explicitly cited in CONTEXT.md, not auto-loaded. This lets a stage be concise while keeping authoritative sources a single retrieval away.

4. Git branch naming reflects stage + date
Branches like publish/2026-06-topic-slug make it trivial to correlate PR history, workspace files, and published posts. Future automation can parse branch names to trigger stage transitions.

What's