A context-engineering framework that makes AI write like the founder, not like AI.
Live Explorer · System Contract · Architecture · Session Log
A working AI-writing system used in production at CushLabs to generate marketing assets, sales collateral, and instructional content with consistent voice and zero invented claims. The repo also serves as a portfolio piece demonstrating context engineering as an engineering discipline — structured constraints over ad-hoc prompting.
This is not a fork-and-deploy template. The truth files (voice, ICP, business profile, claims policy) live in a separate operating-system repo and reflect a specific brand. What this repo is useful for: studying the architecture, copying the patterns into your own system, or running the static Explorer UI to browse the design.
Generic AI writing fails for client work in three predictable ways:
- Voice drift — every chat session restarts from zero, and the model defaults to corporate filler within minutes
- Claim hallucination — fabricated metrics, invented testimonials, and unsupported guarantees that quietly damage credibility
- Format chaos — the same content type (e.g. a landing page) comes out structurally different every time
The fix isn't a longer prompt. It's a system of versioned, machine-readable constraints that the AI loads on every request.
Four JSON truth files describe the brand. Markdown skills describe how to write each content type. The two layers are kept strictly separate.
┌─────────────────────────────────────────────────────────────┐
│ TRUTH LAYER (lives in sibling operating-system repo) │
│ ───────────────────────────────────────────────────────── │
│ voice-dna.json → tone, cadence, phrases, never-dos │
│ icp.json → audience pains, language, framing │
│ business-profile.json → offers, positioning, deliverables │
│ claims-policy.json → what may and may not be claimed │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ SKILL LAYER (this repo, /skills/) │
│ ───────────────────────────────────────────────────────── │
│ One markdown file per content type: │
│ landing-page, cold-email, linkedin-post, sales-deck, │
│ ebc-lesson, proposal-document, case-study, … │
│ Each defines: required inputs, structure, QA checklist │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ KNOWLEDGE LAYER (this repo, /knowledge/) │
│ ───────────────────────────────────────────────────────── │
│ content/ → gold-standard published examples │
│ templates/ → reusable blocks (CTAs, proof, bios) │
│ drafts/ → work-in-progress (directional only) │
│ notes/ → raw thinking (verify before reuse) │
└─────────────────────────────────────────────────────────────┘
When the truth layer and a skill conflict, the truth layer wins. When the claims policy and anything else conflict, the claims policy wins. This hierarchy is enforced in CLAUDE.md.
The system handles two distinct writing jobs with separate context boundaries. Cross-contamination is prevented by routing rules in CLAUDE.md.
| Domain | Purpose | Audience | Skills |
|---|---|---|---|
| 1 — Marketing & Brand | LinkedIn posts, landing pages, cold email, sales decks, proposals, case studies, GitHub content | SMB founders and ops leaders in bilingual EN/ES environments | linkedin-post, landing-page, cold-email, sales-deck, proposal-document, case-study, … |
| 2 — Instructional | Executive Business Communication (EBC) lesson plans for one-on-one English coaching | Non-native English speakers in business roles | ebc-lesson (315 combinations: 9 modes × 5 structures × 7 interactions) |
Domain 2 does not load brand context — a coaching lesson should not sound like a sales asset.
# Clone
git clone https://github.com/RCushmaniii/context-writing-system.git
cd context-writing-system
# Install dev dependencies (lint, test, build)
npm install
# Run the static Explorer UI locally
npm run dev
# → http://localhost:3000
# Run the test suite
npm test
# Lint
npm run lintTo use the system with an AI tool: point it at CLAUDE.md as the system contract. It defines the routing rules, context-loading order, priority hierarchy, and QA passes.
context-writing-system/
├── CLAUDE.md # System contract — routing, priorities, QA rules
├── STRUCTURE.md # Authoritative folder map
├── SESSION_LOG.md # Running journal of work sessions
├── README.md # This file
│
├── skills/ # Content-type expertise (one folder per type)
│ ├── landing-page/
│ ├── linkedin-post/
│ ├── ebc-lesson/
│ └── …
│
├── knowledge/ # Examples, templates, drafts, notes
│ ├── content/ # Gold-standard published examples
│ ├── templates/ # Reusable blocks (CTAs, proof, bios)
│ ├── drafts/ # Work-in-progress
│ └── notes/ # Raw research and ideas
│
├── prompts/ # Profile-builder interview prompts
├── docs/ # System docs (How-it-works, QA, ROADMAP, …)
├── survey/ # Discovery survey definitions
├── archive/ # Versioned profile history
│
├── js/ css/ tests/ # Static Explorer UI source
├── public/ # Static assets
├── scripts/ # Build pipeline (terser + lightningcss)
└── .github/workflows/ # CI: install + lint + test on every PR
The four brand truth files (voice-dna.json, icp.json, business-profile.json, claims-policy.json) live in a sibling repo (operating-system/), not here. This separation prevents drift when multiple repos share the same brand.
A vanilla HTML/CSS/JS dashboard at the repo root that renders the entire system as a browsable knowledge base. Skills, knowledge files, prompts, and surveys are indexed with trust-level badges, file metadata, and live markdown rendering. No build step required to run it; production builds go through terser and lightningcss for minification.
Deployed to Vercel on push to main → context-writing-system.vercel.app.
| Command | What it does |
|---|---|
npm run dev |
Serve the Explorer UI on localhost:3000 |
npm test |
Run the vitest suite (62 tests across common.js + survey.js) |
npm run test:watch |
Vitest in watch mode |
npm run lint |
ESLint on js/ and tests/ |
npm run build |
Minify JS (terser) + CSS (lightningcss) into dist/ |
git push origin main |
Triggers Vercel production deploy |
Every PR runs install + lint + test in CI before merge. Dependabot opens weekly PRs for npm patch and minor updates.
| Layer | Tool | Why |
|---|---|---|
| Frontend | Vanilla HTML / CSS / JS | Zero build tooling for the runtime; nothing to break, nothing to update |
| Data | JSON + Markdown | Machine-readable, diff-friendly, human-editable |
| Tests | Vitest + jsdom | Fast, modern, zero-config DOM testing |
| Lint | ESLint (flat config) | Standard JS hygiene |
| Build (prod) | Terser + lightningcss | ~29% size reduction on minified assets |
| Hosting | Vercel | Git-integrated CD, preview deploys on every PR |
| Errors | Sentry | Production crash visibility |
| CI | GitHub Actions | Install + lint + test on every PR |
| Security | Dependabot, secret scanning, CSP/HSTS headers | Baseline hygiene, no compromises |
- All work goes through feature branches → PR → squash-merge to
main(no direct commits tomain). - Append a new entry at the top of
SESSION_LOG.mdat the end of any meaningful session. - The system contract in
CLAUDE.mdis the source of truth for how the AI is expected to behave inside the repo. Update it when reality changes. - Roadmap and design notes live in
docs/.
Proprietary. All rights reserved. See LICENSE.
The architecture and patterns are documented openly so others can learn from and adapt them. The brand-specific truth files (voice, ICP, business profile, claims policy) and published content examples are not licensed for reuse.
Robert Cushman III — Business Solution Architect & Full-Stack Developer Guadalajara, Mexico