How do I install the Markdown Post Frontmatter Validation skill?

Run npx skillmds@latest add aibot88/markdown-post-frontmatter-validation in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Markdown Post Frontmatter Validation safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Markdown Post Frontmatter Validation?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Markdown Post Frontmatter Validation free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under MIT.

Who published Markdown Post Frontmatter Validation?

aibot88 (@aibot88) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Markdown Post Frontmatter Validation by aibot88

Name: Markdown Post Frontmatter Validation
Rating: 4.5 (4 reviews)
Author: aibot88

Markdown Post Frontmatter Validation

Use when authoring or reviewing the frontmatter of a markdown post — checking required fields (title, date, slug, tags), validating against the content schema in `lib/content/schema.ts`, catching ambiguous date formats or tags not in the controlled vocabulary, and ensuring the slug matches the file path. Activate this skill whenever the task touches files under `content/posts/**/*.md`, the `parsePostFrontmatter()` helper, or any code path that reads YAML frontmatter from a content file. Do NOT use for general YAML schema design (use a generic schema-design skill) or for chasing a specific build-time validation failure (use debugging).

aibot88 Updated Sep 9, 2026 3 repo stars

File contents

Markdown Post Frontmatter Validation

Coverage

Required-field enforcement — every post must declare title, date, slug, and tags; missing fields fail the build at parse time
Date format discipline — ISO 8601 with explicit timezone (2026-05-06T12:00:00Z); ambiguous formats like 2026-05-06 or 5/6/26 are rejected
Slug-to-path consistency — the slug field must match the post's directory name; out-of-sync slugs cause silent route conflicts
Controlled-vocabulary tagging — every tag in the post's tags array must appear in lib/content/tag-vocabulary.ts; lowercase, hyphen-separated, no synonyms
Schema evolution — when lib/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
Reserved-field protection — fields like _id, _internal, or any underscore-prefixed key are reserved for the build pipeline and rejected in author-facing frontmatter

Philosophy

The 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.

Key Files

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

Verification

Before merging any change to a post's frontmatter or to the schema:

Every post has the four required fields: title, date, slug, tags
date 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 runtime
Every tag in tags is present in lib/content/tag-vocabulary.ts (run npm run check:tags to confirm)
No underscore-prefixed fields (_id, _internal, etc.) — those are reserved for the pipeline
Schema changes (lib/content/schema.ts) are paired with a npm run validate:posts pass against the entire content/posts/**/*.md set

Do NOT Use When

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

---name: markdown-post-frontmatter-validationdescription: Use when authoring or reviewing the frontmatter of a markdown post — checking required fields (title, date, slug, tags), validating against the content schema in `lib/content/schema.ts`, catching ambiguous date formats or tags not in the controlled vocabulary, and ensuring the slug matches the file path. Activate this skill whenever the task touches files under `content/posts/**/*.md`, the `parsePostFrontmatter()` helper, or any code path that reads YAML frontmatter from a content file. Do NOT use for general YAML schema design (use a generic schema-design skill) or for chasing a specific build-time validation failure (use debugging).license: MIT--- # Markdown Post Frontmatter Validation ## Coverage - Required-field enforcement — every post must declare `title`, `date`, `slug`, and `tags`; missing fields fail the build at parse time - Date format discipline — ISO 8601 with explicit timezone (`2026-05-06T12:00:00Z`); ambiguous formats like `2026-05-06` or `5/6/26` are rejected - Slug-to-path consistency — the `slug` field must match the post's directory name; out-of-sync slugs cause silent route conflicts - Controlled-vocabulary tagging — every tag in the post's `tags` array must appear in `lib/content/tag-vocabulary.ts`; lowercase, hyphen-separated, no synonyms - Schema evolution — when `lib/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 - Reserved-field protection — fields like `_id`, `_internal`, or any underscore-prefixed key are reserved for the build pipeline and rejected in author-facing frontmatter ## Philosophy The 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. ## Key Files | 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 | ## Verification Before merging any change to a post's frontmatter or to the schema: - [ ] Every post has the four required fields: `title`, `date`, `slug`, `tags` - [ ] `date` 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 runtime - [ ] Every tag in `tags` is present in `lib/content/tag-vocabulary.ts` (run `npm run check:tags` to confirm) - [ ] No underscore-prefixed fields (`_id`, `_internal`, etc.) — those are reserved for the pipeline - [ ] Schema changes (`lib/content/schema.ts`) are paired with a `npm run validate:posts` pass against the entire `content/posts/**/*.md` set ## Do NOT Use When | 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 |

Frequently asked questions

Markdown Post Frontmatter Validation

File contents

Markdown Post Frontmatter Validation

Coverage

Philosophy

Key Files

Verification

Do NOT Use When

Related skills

Frequently asked questions

How do I install the Markdown Post Frontmatter Validation skill?

What does the Markdown Post Frontmatter Validation skill do?

Is Markdown Post Frontmatter Validation safe to use?

Which AI agents work with Markdown Post Frontmatter Validation?

Is Markdown Post Frontmatter Validation free to use?

Who published Markdown Post Frontmatter Validation?