$ man geo/typescript-content-system-for-geo

Most content systems store articles in a CMS or as Markdown files with frontmatter. This works, but it creates a disconnect between your content and the code that renders it. A TypeScript-first content system stores content as typed data arrays in .ts files. Each entry has a strict interface - title, description, keywords, sections, related entries - enforced by the TypeScript compiler. If you forget a required field, the build fails. If you reference a related entry that does not exist, you can catch it at compile time. This approach eliminates an entire category of content bugs that CMS-based systems suffer from: broken links to deleted pages, missing meta descriptions, malformed schema markup, and inconsistent field formatting. The ShawnOS.ai wiki system uses this pattern. Each wiki - Clay, Content, GEO, How-To - is a single TypeScript file exporting a typed array of entries. The wiki page component reads from these arrays, and every GEO signal - schema, RSS, llms.txt, sitemap entries - is generated from the same typed source data.

PATTERN

The core of a TypeScript content system is the entry interface. Define an interface that captures every field your content needs: an id for URL slugs and cross-references, title and subtitle for display, category for filtering and grouping, description for SEO meta tags, keywords for search targeting, a sections array of typed section objects, a related array of other entry IDs for cross-referencing, and a difficulty level for filtering. Each section has a heading, content string, and a type that determines how it renders - prose for standard content, pattern for structured frameworks, code for technical implementations, anti-pattern for what not to do, pro-tip for actionable advice, and formula for step-by-step processes. This section typing means your rendering layer can style each section type differently while your content layer remains pure data. The type system ensures every section declares its intent, and the rendering layer translates that intent into visual design.

CODE

Once your content lives in typed arrays, generating GEO signals becomes a build-time operation. Schema markup: loop through entries, generate Article JSON-LD for each entry with the title as headline, description as description, and dateModified set to the build timestamp. RSS feed: loop through entries, generate an RSS item for each with the entry title, description, URL, and build date. llms.txt: loop through entries grouped by category, output a Markdown list with titles and URLs. Sitemap: loop through entries, generate a URL entry for each with the current date as lastmod. All four signals come from the same source data. When you add a new entry to the array, all four signals update automatically at the next build. When you update an entry, all signals reflect the change. There is no manual step where someone forgets to update the RSS feed or the sitemap. The system handles it because the data flows from one typed source to every output format.

PRO TIP

TypeScript gives you compile-time validation that no CMS can match. Add a helper that checks related entry references - iterate through all entries and verify that every ID in the related array exists as an entry ID somewhere in the array. Run this at build time. If an entry references a related entry that was deleted or renamed, the build fails with a clear error. Similarly, validate that descriptions are under 155 characters for SEO compliance, that every entry has at least three keywords, and that section content is not empty. These validations prevent content quality regressions automatically. You can also add custom linting rules - for example, checking that no section content uses banned words from your anti-slop list, or that every entry in the advanced difficulty tier has at least four sections. The TypeScript content system turns content quality into a CI check, not a manual review process.