sk-create-frontmatter

create-frontmatter

create-frontmatter is the frontmatter workflow packet of the sk-doc family. It owns the contract every other mode writes against: which fields a document class carries, what each field may contain, and how the 4-part version field is derived and inserted.

Six sibling modes emit frontmatter. None of them decides what a frontmatter block is. This mode does, and they cite it.

This mode owns rules, not enforcement. The validators and the versioning engine live in the hub's shared tier because a post-edit hook outside this hub resolves them by path. This mode is where you find out what the validators are checking for and why.

1. WHEN TO USE

Activation Triggers

• A document needs a frontmatter block and you do not know which fields its class carries.
• A validator rejected a frontmatter block and the message names a field rather than a fix.
• A description is over budget and needs trimming without losing its routing signal.
• A version field needs deriving, inserting or reconciling against a changelog anchor.
• Someone asks what trigger_phrases, importance_tier or contextType are for.
• A document class is being added and needs a frontmatter rule of its own.

Keyword triggers: yaml frontmatter, frontmatter block, frontmatter template, frontmatter field, frontmatter fields, trigger_phrases, trigger phrases, importance_tier, contextType, description budget, 4-part version, X.Y.Z.W, frontmatter versioning, frontmatter version, version field, frontmatter validation, missing frontmatter, frontmatter contract, yaml header, goes at the top of the file, version number at the top, importance tier, versioning pass, stopped showing up in suggestions, validator says my file is missing, description too long, edit count, field the validator wants.