$ man how-to/repo-context-engine

Most people think of a repo as code storage. Files go in. Version control tracks changes. That is half the story. A repo is also the primary context source for every AI agent that touches your project. When Claude starts a session, it reads your repo. When you reference a file with @, it loads that file into the context window. When a skill runs, it reads files from the repo. The repo IS the context engine. How you organize it determines how well AI works for you. A messy repo produces messy AI output. A structured repo produces structured AI output. The repo structure is context engineering.

PATTERN

Every folder should have a clear purpose. Every file should have a predictable name. When Claude needs partner research, it looks in partners/{name}/research/. When it needs a skill, it looks in .cursor/skills/{name}/SKILL.md. When it needs a content draft, it looks in content/drafts/. Use date prefixes for content: 2026-02-18_topic-name.md. This sorts chronologically and tells Claude when something was written. Use lowercase slugs for folders: partners/acme/, skills/deploy/. Use SKILL.md (uppercase) for skill files so they stand out in directory listings. The taxonomy is not about aesthetics. It is about predictability. Predictable structure means Claude spends zero time searching and zero time guessing file paths. It goes directly to the file it needs because the structure is always the same.

FORMULA

CLAUDE.md in the root: environment defaults, language preferences, code style. Under 50 lines. .cursor/skills/ or skills/: one SKILL.md per workflow. Deploy, tracker, content publishing, partner onboarding. .cursor/rules/: file-specific patterns. Blog formatting rules, TypeScript conventions, voice enforcement. content/: everything you produce. Drafts, published posts, images, indexes. partners/ or clients/: per-entity folders with research, prompts, workflows, resources. workflows/: content indexes, pipeline tracking, editorial calendars. data/: generated assets, stats, exports. Usually gitignored for sensitive data. scripts/: Python automation, batch processing, data transformations. Usually gitignored. This is not the only valid structure. But whatever structure you choose, be consistent. One structure across every partner, every content type, every workflow. Consistency is what makes the context engine work.

PRO TIP

A context repo compounds. Every file you add makes future AI sessions better. A voice guide you wrote in month one makes every content piece from month two onward sound like you. A partner research folder you created for client A becomes the template for clients B through Z. A skill you wrote for deploying one site evolves into a skill that deploys three sites with error handling and verification. My repo started with a CLAUDE.md and three skills. Six months later it has 40+ skills, a full voice system, partner workflows, an RPG progression system, and automated dashboards. I did not set aside time to build the context engine. I built it by doing the work and capturing the patterns. Every day the repo gets better. Every day AI works better with it. That is the compounding effect.