$ man content-wiki/repo-content-system

Most content creators use Google Docs, Notion, or platform-native editors. These work. They do not scale. A git repository gives you version control (every draft, every edit, every published version is tracked), automation (scripts and agent skills can generate, format, and publish content), modularity (voice rules, platform playbooks, and content ops are separate files that compose), and portability (your entire content system moves with a single git clone). The shift is from content as documents to content as code. Documents are static files you edit manually. Code is a system with inputs, processing, and outputs. A content repo means your voice guide is loaded at generation time, your formatting rules are applied automatically, and your publishing pipeline is a skill invocation rather than a copy-paste workflow.

CODE

The content repo has a specific architecture: content/ is the content itself, organized by platform and status (drafts/, final/, substack/, tiktok/). skills/ is the voice and automation system (tier-1-voice-dna/, tier-2-context-playbooks/, tier-3-content-ops/). .cursor/skills/ contains the agent skills that automate content creation (final-copy, play-draft, skill-play, tiktok-script, substack-post, etc.). workflows/ tracks content pipelines, series indexes, and scheduling. data/ stores progression tracking, stats, and generated assets. Each directory has a specific purpose. Content and skills are separated because skills are the system and content is the output. The system generates and processes the output. Mixing them creates confusion about what is a rule and what is a deliverable.

PATTERN

Every piece of content follows the same lifecycle: (1) Capture — an idea gets recorded, either manually in a draft file or via the idea-bank skill. (2) Draft — the content is written as a markdown file in content/drafts/ with a date-prefixed filename. (3) Voice normalization — the final-copy or final-substack skill reads the draft, applies voice rules, strips AI slop, and produces platform-ready text. (4) Review — you read the normalized version, make final edits. (5) Publish — Typefully MCP or Substack MCP pushes the content to the platform. (6) Archive — the draft moves to content/final/ with publication metadata. This workflow is the same regardless of platform. LinkedIn, X, Substack, TikTok scripts — they all follow capture, draft, normalize, review, publish, archive. The skills handle the platform-specific formatting.

PRO TIP

Git diff on a content file shows you exactly what changed between drafts. This is powerful for voice calibration — you can see which phrases the AI suggested, which ones you edited, and which patterns keep appearing across posts. Commit messages on content files follow the same convention as code: add for new drafts, update for edits, finalize for publication-ready versions. The git log for a content file tells the story of how that piece evolved from first idea to published post. Branching is useful for experimental content. Want to try a different hook on the same post? Branch it. Write both versions. Merge the one that feels right. The other version is preserved in git history as a reference for future hook decisions.

PATTERN

The repo-based content system scales in three dimensions: (1) More platforms — add a new playbook to tier-2, a new skill for publishing, and the same workflow extends to a new platform. (2) More content types — add a new pillar definition to tier-3, a new series to the workflow index, and the system tracks it alongside everything else. (3) More automation — each manual step in the workflow is a candidate for a new skill. If you find yourself doing the same formatting task repeatedly, write a skill for it. The system also scales for teams. Multiple contributors can work on content in the same repo with standard git collaboration — branches, pull requests, reviews. The voice system ensures consistency regardless of who is writing because the rules are codified, not tribal knowledge.