research-frontmatter
Research Frontmatter Standard
Ensure all research files in docs/research/ have standard YAML frontmatter so GitHub renders metadata as a table and readers can judge staleness.
Required Frontmatter
Every research file MUST have these 5 fields at the top of the YAML block:
---
title: "Human-readable title"
version: "1.0.0"
status: Published # Published | Draft | Living Document
created: YYYY-MM-DD
last_updated: YYYY-MM-DD
---
Additional fields (slug, tags, aliases, promoted_at, last_refreshed, sources) MAY follow the standard fields.
Field Definitions
| Field | Required | Format | Description |
|---|---|---|---|
title |
Yes | Quoted string | Human-readable document title |
version |
Yes | Semver string | Content maturity version |
status |
Yes | Enum | Published, Draft, or Living Document |
created |
Yes | YYYY-MM-DD |
Date first authored (from git or inline) |
last_updated |
Yes | YYYY-MM-DD |
Date of last substantive content change |
When to Increment Version
- Patch (1.0.0 -> 1.0.1): Typo fixes, formatting, minor clarifications
- Minor (1.0.0 -> 1.1.0): New sections added, examples updated
- Major (1.0.0 -> 2.0.0): Complete rewrite, fundamental scope change
README Index
The docs/research/README.md table MUST use these columns:
| Topic | Version | Status | Created | Last Updated |
When adding a new entry, append a row matching this format.
Template
New research files should follow docs/research/TEMPLATE.md.
Validation Checklist
When triggered, verify:
- File has YAML frontmatter (starts with
---) - All 5 required fields are present
statusis one of the 3 allowed values- Dates use ISO 8601 format (
YYYY-MM-DD) - Standard fields appear before any extra fields
- README.md entry exists and columns match
More from joaquimscosta/arkhe-claude-plugins
skill-validator
Validate skills against Anthropic best practices for frontmatter, structure, content, file organization, hooks, MCP, and security (62 rules in 8 categories). Use when creating new skills, updating existing skills, before publishing skills, reviewing skill quality, or when user mentions "validate skill", "check skill", "skill best practices", "skill review", or "lint skill".
30domain-driven-design
Expert guidance for Domain-Driven Design architecture and implementation. Use when designing complex business systems, defining bounded contexts, structuring domain models, choosing between modular monolith vs microservices, implementing aggregates/entities/value objects, or when users mention "DDD", "domain-driven design", "bounded context", "aggregate", "domain model", "ubiquitous language", "event storming", "context mapping", "domain events", "anemic domain model", strategic design, tactical patterns, or domain modeling. Helps make architectural decisions, identify subdomains, design aggregates, and avoid common DDD pitfalls.
26code-explanation
Explains complex code through clear narratives, visual diagrams, and step-by-step breakdowns. Use when user asks to explain code, understand algorithms, analyze design patterns, wants code walkthroughs, or mentions "explain this code", "how does this work", "code breakdown", or "understand this function".
22generating-changelog
Analyzes git commit history and generates professional changelogs with semantic versioning, conventional commit support, and multiple output formats (Keep a Changelog, Conventional, GitHub). Use when editing CHANGELOG.md, CHANGELOG.txt, or HISTORY.md files, preparing release notes, creating releases, bumping versions, updating changelog, documenting changes, writing release notes, tracking changes, version bump, tag release, or when user mentions "changelog", "release notes", "version history", "release", "semantic versioning", or "conventional commits".
21workflow-orchestration
>
19generating-stitch-screens
>
19