Content Source Router

Concept of the skill

What it is: The project-specific dispatch contract that decides which content source reads a requested page or post. Mental model: Treat each source as an adapter behind one explicit router; the router owns selection, not rendering. Why it exists: A static site with local markdown, MDX, and CMS-synced content needs one place where source precedence is visible and testable. What it is NOT: It is not the source-specific parser, the CMS sync job, or contributor-facing documentation. Adjacent concepts: Content source adapters, route matching, fallback policy, routing audit logs. One-line analogy: It is the switchboard that connects a content request to the right reader. Common misconception: A router can safely fall back to "markdown" when uncertain; unknown source selection should surface as a coverage gap.

Coverage

• File-extension dispatch — .md routes to the markdown source, .mdx routes to the MDX source, no extension or .cms.json routes to the CMS source
• Content-path prefix dispatch — content/posts/** routes to local sources; content/cms-synced/** routes to the CMS source even if the file extension is .md
• Explicit source hints — internal callers (preview tools, manual reconciliation) pass an explicit source parameter that bypasses inspection
• Coverage-gap surfacing — when no detection rule matches a request, the router returns a structured "unknown source" result; it never silently picks a default
• Adding a new source — the workflow for landing a fourth source (Notion API, Sanity, etc.) without breaking the existing three (registration, routing precedence, fixture test, end-to-end content-fetch sanity)