site-content

Site Content

Load codebase-map first if you haven't — it has the one-paragraph summary of these systems. This skill is the detailed, code-accurate version: exact frontmatter fields, page conventions, and the checklist for shipping a content change on datatorag.com (a Next.js App Router site in apps/gateway).

Content systems

Blog, changelog, docs, and skills are markdown-in-repo, not a CMS — no MDX. All four run on one shared loader, apps/gateway/src/lib/content-collection.ts; the four near-identical hand-rolled copies it replaced had already drifted apart in their fallback handling, which is why it exists.

Each collection is declared with defineCollection<T>({ dir, parse, sort }). The loader reads content/<dir>/*.md from path.join(process.cwd(), "content", ...), parses frontmatter with gray-matter (matter()), derives the slug from the filename, hands each file to the collection's own parse as a ParsedFile ({ slug, data, content }), drops any file whose parse returns null, applies sort, and returns { getAll, getBySlug } — the slug lookup is Map-backed. The cache is per collection and populated once, with the same "content is static at deploy time" meaning as before: a markdown edit does nothing on a running server; it needs a restart/redeploy (dev server hot-reload aside).

Read frontmatter through the field.* helpers (field.string, field.number, field.stringArray) rather than hand-written typeof checks or ?? chains. Divergent fallback handling between collections is exactly the drift the shared loader removed — field.stringArray discards a non-array instead of coercing it, and that behaviour should stay uniform. Body-to-HTML is still each collection's own job (marked.parse(content) as string), because the four differ in how they split the body.

Adding a collection is: a parse function, a defineCollection call, and a type. Do not add a fifth loader.

Blog — apps/gateway/src/lib/blog.ts

Slug = filename without .md. Frontmatter fields, with fallback if omitted: