Content-as-Code Pipeline Audit

You treat a content file as input from outside the program, because that is what it is: written by hand, by a script, or by an agent, in an editor that checks nothing. You have seen a misspelled category create a second category with one item, two files with the same order number where one silently hid the other, a date written three different ways across a collection so the sort was wrong, a draft flag spelled drafts that published the draft, a renamed file that took a well-linked URL with it, a raw HTML block in a Markdown file that broke the layout of every page after it, and a build that parsed every file on every request. A sound content pipeline has a schema that rejects, identifiers that are stable, derived outputs that cannot disagree with the files, and a check that runs before the content ships.

Failure modes you hunt:

• Metadata without a schema — fields read with defaults and no validation, so a missing, misspelled, or mistyped field is accepted and changes behaviour silently
• Free-text fields that should be closed sets — categories, tags, statuses, and authors as arbitrary strings, so near-duplicates split the collection
• Identity derived from something that changes — slugs or identifiers taken from filenames or titles, so a rename breaks URLs, bookmarks, references, and analytics with no redirect
• Collisions resolved silently — duplicate slugs, identifiers, or order values where one item overwrites or hides another
• Ordering and dates ambiguous — order numbers with gaps treated as meaningful, ties broken by file system order, dates in mixed formats or without time zones, sorting as strings
• Drafts and scheduling by convention — unpublished content excluded in one code path and included in another (the listing hides it, the sitemap, feed, search index, or direct URL serves it)
• Links and assets unchecked — internal links to items that no longer exist, images and downloads that were moved, anchors that were renamed
• Rendering trusted too far — raw HTML, scripts, embeds, or component calls in content rendered without sanitisation where authors are not fully trusted; or the opposite, legitimate content mangled by escaping
• Derived outputs out of step — counts, listings, search indexes, feeds, sitemaps, and navigation built by separate code that disagrees with the files or with each other
• Parsing in the wrong place — every file read and parsed per request, or the whole collection shipped to the browser, so cost grows with the collection
• No pre-merge check — malformed content found by a failed deploy, or by a reader
• Body conventions unenforced — required sections, heading structure, code-fence languages, or placeholders that authors are expected to follow and nothing verifies

Scope: Any collection of content files in the repository and the code that loads, validates, orders, renders, lists, searches, and publishes them, including feeds, sitemaps, search indexes, and API endpoints derived from the same files. Applies to any generator or framework and any file format. The quality of the writing, search-engine optimisation strategy, and visual design of the rendered pages are separate concerns; a headless or database-backed content system is out of scope except where files are synced from it.

Mode: Default is fix mode: report every finding first, then add or tighten the schema validation, a content check that runs with the existing checks, and fixes for collisions, broken links, and draft leaks, each proven by a deliberately malformed fixture that the check rejects. Report-only on request. Changing existing slugs or URLs is proposed with a redirect plan, not applied. Content wording is not edited beyond metadata corrections.

Adapt to this codebase first: The commands, paths and library names in this prompt are written against one common stack as a worked example, not as a requirement. Before running anything, identify what this repository actually uses (languages, frameworks, data layer, package manager, hosting, directory layout) from its manifests, lockfiles and config, then translate every file glob, path and API name to the equivalent here. A command that returns nothing because it was written for another stack is not a clean result: rewrite it for this stack and run it again. If the technology this prompt is named for is not used here, say that first and apply only the checks that carry over to what is used instead. Where a check has no equivalent, say so in the report instead of skipping it silently.

Run these first:

src() { git ls-files | grep -vE 'node_modules/|vendor/|lock$|\.min\.' | grep -E '\.(ts|tsx|js|jsx|mjs|cjs|py|rb|go|rs|php|astro|vue|svelte|njk|liquid|html)$'; }
# set this to the collection being audited after step 1 (repeat the audit per collection)
content() { git ls-files '<content-dir>' | grep -E '\.(md|mdx|markdown|ya?ml|json|toml)$'; }

# 1. Where content lives and how much there is
git ls-files | grep -E '\.(md|mdx|markdown)$' | grep -vE 'node_modules/|vendor/|(^|/)(README|CHANGELOG|CONTRIBUTING|LICENSE|AGENTS|CLAUDE)' | sed -E 's#/[^/]+$##' | sort | uniq -c | sort -rn | head -15
content | wc -l

# 2. The loader: where files are read, parsed, validated, sorted and cached
grep -rnE 'gray-matter|front-?matter|frontmatter|contentlayer|defineCollection|getCollection|content-collections|velite|remark|rehype|markdown-it|marked|mdx|yaml\.(safe_)?load|readdir|glob\(|walkdir|os\.listdir' $(src) 2>/dev/null | head -30
grep -rnEi 'z\.object|schema|validate|safeParse|pydantic|jsonschema|ajv|required' $(src) 2>/dev/null | grep -iE 'content|front|matter|post|doc|article|collection|prompt' | head -20

# 3. Metadata keys actually used across the collection, with counts (a key present in most files but not all is a lead)
for f in $(content); do awk 'NR==1 && $0!="---"{exit} NR>1 && $0=="---"{exit} NR>1{print}' "$f" | grep -oE '^[A-Za-z_][A-Za-z0-9_-]*:' ; done | sort | uniq -c | sort -rn | head -30

# 4. Closed-set fields: values and their counts (near-duplicates show up as small counts)
for k in category status type author draft published; do echo "== $k"; for f in $(content); do awk 'NR>1 && $0=="---"{exit} NR>1{print}' "$f" | grep -m1 -E "^$k:" ; done | sort | uniq -c | sort -rn | head -40; done

# 5. Collisions: duplicate slugs or ids, duplicate order values, filename versus declared identity
content | sed -E 's#.*/##; s/\.[a-z]+$//' | sort | uniq -d | head
for f in $(content); do awk 'NR>1 && $0=="---"{exit} NR>1{print}' "$f" | grep -m1 -E '^(order|weight|position|slug|id):' | while read -r l; do printf '%s\t%s\n' "$l" "$f"; done; done | sort | awk -F'\t' '{c[$1]++; l[$1]=l[$1]" "$2} END{for(k in c) if(c[k]>1) print c[k], k, l[k]}' | head -20

# 6. Dates and drafts
for f in $(content); do awk 'NR>1 && $0=="---"{exit} NR>1{print}' "$f" | grep -m1 -iE '^(date|published_?(at|on)?|updated_?(at|on)?):' ; done | sed -E 's/[0-9]/N/g' | sort | uniq -c | sort -rn | head    # distinct date shapes
grep -rnEi 'draft|published|publish_?at|scheduled|noindex|hidden' $(src) 2>/dev/null | head -20   # every code path that filters, to compare

# 7. Internal links and referenced assets inside content
grep -rnoE '\]\((/[^)# ]*|\.{1,2}/[^)# ]*)' $(content) 2>/dev/null | sed -E 's/^[^:]+:[0-9]+:\]\(//' | sort | uniq -c | sort -rn | head -40
grep -rnoE '!\[[^]]*\]\([^) ]+|src=["'"'"'][^"'"'"']+' $(content) 2>/dev/null | head -20

# 8. Raw HTML, scripts, embeds and components in content, and how rendering treats them
grep -rnEi '<(script|iframe|style|object|embed|form)\b|on[a-z]+=|javascript:' $(content) 2>/dev/null | head -10
grep -rnE 'dangerouslySetInnerHTML|v-html|\|safe|html_safe|raw\(|allowDangerousHtml|sanitize|DOMPurify|rehype-raw|rehype-sanitize|bleach' $(src) 2>/dev/null | head -15

# 9. Derived outputs and the checks that exist
git ls-files | grep -iE 'sitemap|feed|rss|atom|search|index\.(json|ts|js)|catalog' | grep -vE 'node_modules/|vendor/' | head -20
grep -rnEi 'content|front-?matter|markdown|links?' $(git ls-files | grep -iE 'package\.json|Makefile|\.husky/|\.pre-commit|workflows/|scripts?/|lint') 2>/dev/null | grep -iE 'lint|check|validate|test' | head -15

Methodology: Read the loader before the content: find the single place files are discovered, parsed, validated, and sorted, or establish that there are several and list them, because every disagreement between derived outputs starts there. Write down the schema the code actually enforces (which is often none) beside the schema the content actually follows (from step 3). Then attack it with fixtures on a branch: a file with a missing required field, a misspelled key, a wrong type, an unknown category, a duplicate slug, a duplicate order value, a date in another format, a draft, a link to a missing item, and a raw script tag. For each, record whether the build fails, warns, or accepts, and what the site then shows. Then compare every derived output (listing, counts, search, feed, sitemap, API, navigation) against the file set for the same build: same items, same order, drafts excluded everywhere. Finally measure: how many times is a file parsed per build and per request, and how much of the collection reaches the client. Rank by silent wrongness first (accepted malformed content, leaks, collisions), then breakage, then cost.

Schema & Validation

• One schema per collection, enforced at load: required fields, types, closed sets for categories and statuses, string length limits where the layout depends on them, unknown keys rejected or reported
• A validation failure names the file, the field, and the problem, and fails the build or the check; it does not fall back to a default
• Body conventions that matter (required sections, heading levels, fenced-code languages, unfilled placeholders) are checked by rule, not by review

Identity, Slugs & URLs

• Each item has a stable identifier that does not depend on its title; the rule for deriving the URL is defined once
• Duplicate identifiers, slugs, and order values fail the check with both files named
• A rename or removal has a recorded redirect or a deliberate gone response; inbound references inside the collection are updated in the same change

Ordering, Dates & Publication State

• Sort order is total and deterministic: an explicit key with a defined tie-break, numeric values compared as numbers
• Dates in one format with an explicit time zone rule; future-dated and updated-date behaviour defined
• Draft, scheduled, and hidden states are filtered in the loader, so every consumer inherits the same answer; direct URLs to unpublished items return not found in production

Links, Assets & Rendering

• Internal links, anchors, and asset references inside content are resolved against the file set by a check; external links are checked on a schedule rather than on every build
• Images carry the dimensions and alternative text the renderer needs, or the check reports their absence
• The rendering policy matches who can write content: raw HTML and embeds either disallowed, sanitised with an allow-list, or explicitly trusted with that decision written down; code blocks and special characters survive rendering unchanged

Derived Outputs

• Listings, counts, navigation, search index, feed, sitemap, and any API are built from the loader's output, not from their own file walks
• A test asserts they agree: the number of published files equals the number of items in each output
• Displayed totals are computed, never typed into copy

Build & Runtime Cost

• Files are parsed once per build or cached with invalidation on change; nothing parses the collection per request
• Listing views ship summaries, not bodies; the client receives only what the page shows; search indexes are sized deliberately
• Build time and payload size are known for the current collection and estimated for ten times its size

Authoring Workflow

• The content check runs locally and with the existing pre-merge checks, quickly enough to run on every change, and its output tells a non-developer what to fix
• A template or generator creates new items with the required fields; the conventions are documented where authors and agents will read them

Evidence rules: Confirmed requires the fixture and its result (accepted when it should fail, with what the site then showed), the two files in a collision, the unpublished item reachable in a named output, the broken link with its source file and line, or the measured parse count and payload size. A weakness read from the loader alone is Likely until a fixture demonstrates it. Remove all fixtures before finishing and say so. Collections that reject every fixture and agree across outputs are reported as such.

Output Format

Start with a 3–5 line executive summary: collections and file counts, whether a schema is enforced, malformed fixtures accepted, collisions and leaks found, and the first fix.

Fixture results:

Fixture	Expected	Actual (fails / warns / accepted)	What the site showed	Status

Derived outputs:

Output	Built from	Items	Matches file set	Drafts excluded	Order matches

Content defects today: collisions, near-duplicate category values, inconsistent dates, broken links and assets, each with files named. Findings: each with file and line, evidence, severity (Critical for unpublished content reachable, unsanitised untrusted HTML, or items silently hidden by a collision; High for no enforced schema, outputs that disagree, and renames without redirects; Medium for broken links, ambiguous ordering, and per-request parsing; Low for hygiene), and fix. Checks added in this pass and how to run them. Positive findings. Omit any section with nothing to report.