Implementing a 5-Layer Model Workspace Protocol for Tech Blog Post Generation

```html

What Was Done

We refactored the tech.queenofsandiego.com blog workflow from a monolithic context structure into a 5-layer Model Workspace Protocol (MWP) architecture. This migration consolidates scattered documentation, eliminates redundant context loading, and reduces per-session token overhead from ~10,925 tokens to a projected ~370 tokens—a 30× improvement.

The implementation created a new workspace directory structure at /repos/workspaces/tech-blog/ with layered context files, stage-specific CONTEXT.md routers, and isolated artifact directories for each of the four blog post production stages.

Technical Details: Directory Structure and Layer Mapping

The 5-layer protocol maps to our workspace as follows:

Layer 0 (Map/Entrypoint): workspaces/tech-blog/CLAUDE.md (~80 tokens)—minimal routing file that loads stage-specific Layer 1 files on demand
Layer 1 (Stage Router): workspaces/tech-blog/CONTEXT.md—user-facing instruction that directs to the correct stage and references supporting docs
Layer 2 (Stage Context): Four stage-specific CONTEXT.md files:
- 01-topic/CONTEXT.md — topic ideation and vetting rules
- 02-research/CONTEXT.md — research methodology and source validation
- 03-draft/CONTEXT.md — markdown drafting and internal review gates
- 04-publish/CONTEXT.md — final review, formatting, and deploy steps
Layer 3 (Reference): reference/voice.md—brand voice guidelines, markdown conventions, and tone rules (extracted from the monolithic CLAUDE.md)
Layer 4 (Per-Run Artifacts): Stage-specific output directories holding drafts, research notes, and final HTML

Why This Structure Reduces Token Waste

The original workflow loaded a single 6,563-token tech_blog_generator.py reference plus a 3,420-token site-wide CLAUDE.md and 942-token repos-level CLAUDE.md on every session—totaling ~10,925 tokens regardless of which stage the user was in. A user at the topic-brainstorm stage had to load pricing rules, deployment safety checklists, and competitor analysis that weren't relevant until publish time.

The 5-layer structure loads only the Layer 0 entrypoint (~80 tokens) plus the single relevant Layer 2 CONTEXT.md for the active stage (~90–150 tokens each), plus Layer 3 reference docs on demand. This collapses redundant context and makes each stage's instructions explicit.

Implementation Details: File Creation and Migration

We created the following new files in the workspace:

workspaces/tech-blog/
├── CLAUDE.md                           # Layer 0: ~80 tokens, routing only
├── CONTEXT.md                          # Layer 1: stage selector and overview
├── reference/
│   └── voice.md                        # Layer 3: brand voice, markdown style
├── 01-topic/
│   └── CONTEXT.md                      # Layer 2: ideation rules
├── 02-research/
│   └── CONTEXT.md                      # Layer 2: research methodology
├── 03-draft/
│   └── CONTEXT.md                      # Layer 2: drafting gates and review
└── 04-publish/
    └── CONTEXT.md                      # Layer 2: final review and deploy

Each stage's CONTEXT.md specifies:

Input expectations (what files or prior stage artifacts to provide)
Process rules (e.g., research must cite at least three sources; draft review checklist)
Output format and artifact location (e.g., 04-publish/ outputs finalized HTML to the blog's _posts/ directory)
Success criteria for stage completion
References to relevant Layer 3 docs (e.g., voice.md for tone guidance)

Infrastructure: Integration with Existing Blog Stack

The blog runs on a static site generator (Jekyll) hosted on CloudFront backed by an S3 bucket. The refactored workflow doesn't change deployment infrastructure—it optimizes the pre-deployment documentation and context management.

Publishing flow remains:

Finalized markdown is written to _posts/YYYY-MM-DD-slug.md in the site repository
Jekyll builds the site during the pre-push CI hook
Git push triggers CodeBuild pipeline to invalidate CloudFront distribution cache
Distribution serves fresh content from S3 origin

The workspace structure integrates seamlessly: the 04-publish/CONTEXT.md` provides the exact git workflow and build commands without changing the underlying infrastructure.



Key Decisions: Why Layers Instead of a Single CONTEXT.md

Layer separation over monolithic design: A single large CONTEXT.md forces the model to load irrelevant rules. By splitting into stage-specific files, we ensure that a user starting a new post only loads the topic ideation rules, not deploy checklists or brand voice details (until referenced). This reduces noise and improves focus.

Explicit reference via Layer 3: Voice and style rules live in reference/voice.md rather than inline in each stage's CONTEXT.md. This allows every stage to reference the same authoritative source without duplication, and makes voice updates painless—change one file and all stages inherit the update.

Artifact isolation by stage: Each stage's output (ideation notes, research markdown, drafts, final HTML) lives in its own numbered directory. This makes it trivial to trace a post's evolution, run parallel drafts, and archive completed work without cluttering the workspace root.

Measured Token Savings (Baseline vs. Projected)

Before: ~10,925 tokens loaded per session across three levels of CLAUDE.md files and a large generator reference.

After (projected): ~370 tokens per session:
  ~80 (Layer 0 entrypoint)
  + ~90–150 (single stage CONTEXT.md)
  + ~100–140 (brand voice reference, loaded on demand)


Real-world measurement during the first full blog post cycle will confirm these projections and account for any Claude model optimizations in context merging.

What's Next


  Pilot validation: Run the first blog post through the refactored workflow from topic to publish. Measure wall-clock time and actual token usage at each stage.
  Breakage audit: Document any missing instructions or ambiguities discovered during pilot, and update Layer 2 CONTEXT.md files as needed.
  Generalization playbook: Once tech-blog is stable, apply the same 5-layer pattern to other documentation and workflow repositories (e.g., product blog, technical docs, ops runbooks).
  
    
      ← All posts