markdown-post-frontmatter-validation — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited markdown-post-frontmatter-validation (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
What it is: The project-specific validation discipline for the YAML frontmatter on markdown posts. Mental model: Frontmatter is a typed interface between content files and the site runtime. Why it exists: Routing, indexes, tags, dates, and previews all depend on frontmatter being complete and unambiguous. What it is NOT: It is not general YAML schema design, parser performance work, or debugging a specific failed build. Adjacent concepts: Content schemas, slug derivation, controlled vocabularies, date normalization. One-line analogy: It is the checklist that makes every post safe for the build to consume. Common misconception: If the markdown renders, the frontmatter is good enough; metadata can break listing pages even when body content renders.
title, date, slug, and tags; missing fields fail the build at parse time2026-05-06T12:00:00Z); ambiguous formats like 2026-05-06 or 5/6/26 are rejectedslug field must match the post's directory name; out-of-sync slugs cause silent route conflictstags array must appear in lib/content/tag-vocabulary.ts; lowercase, hyphen-separated, no synonymslib/content/schema.ts changes, every post's frontmatter is re-validated; existing posts that violate the new schema are flagged before the next build runs_id, _internal, or any underscore-prefixed key are reserved for the build pipeline and rejected in author-facing frontmatterThe frontmatter block is the contract every post makes with the site's index, the router, and the renderer. If that contract is loose — if posts can omit fields, use ambiguous dates, or invent ad-hoc tags — the index drifts, routes silently overlap, and the search surface degrades. The cost of catching frontmatter bugs at build time is one re-run; the cost of catching them in production is a broken page or a missing entry in the archive. The rule is: validate at parse time, fail loud, and keep the schema small enough that authors can hold it in their head.
| File | Purpose |
|---|---|
content/posts/_template.md | The canonical template every new post copies — its frontmatter is the worked example of every required field |
lib/content/schema.ts | The TypeScript schema (Zod or equivalent) that runtime validation calls |
lib/content/parse-frontmatter.ts | The thin wrapper that reads the YAML block and runs schema.parse() — the failure surface for build-time errors |
Before merging any change to a post's frontmatter or to the schema:
title, date, slug, tagsdate is ISO 8601 with timezone (no naked YYYY-MM-DD, no locale-formatted dates)slug matches the post's directory name exactly — not derived from title at runtimetags is present in lib/content/tag-vocabulary.ts (run npm run check:tags to confirm)_id, _internal, etc.) — those are reserved for the pipelinelib/content/schema.ts) are paired with a npm run validate:posts pass against the entire content/posts/**/*.md set| Use instead | When |
|---|---|
| (a generic schema-design skill) | The task is designing a new YAML schema for an unrelated domain |
debugging | A specific build is failing and you need to reproduce the validation error from logs |
documentation | The task is writing a runbook or contributor doc about the frontmatter format |
refactor | The task is restructuring parse-frontmatter.ts without changing the validation contract |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.