massgen-release-documenter

The release-documenter skill is an essential tool for developers and maintainers of the MassGen project to ensure high-quality, consistent, and audit-ready release documentation. It provides a structured, phase-by-phase framework that aligns with the authoritative release checklist located in docs/dev_notes/release_checklist.md. By automating the mental overhead of the release process, this skill ensures that no critical steps—from updating CHANGELOG.md to syncing README_PYPI.md—are overlooked. It acts as an orchestrator for the documentation pipeline, requiring strict adherence to a specific order of operations to maintain integrity across project milestones. Target users include project maintainers, release managers, and contributors responsible for maintaining the project's codebase, documentation, and roadmap.

• Orchestrates the full release lifecycle: CHANGELOG updates, Sphinx documentation builds, config documentation, case studies, README.md refreshes, and roadmap synchronization.

• Integrates validation checks for pre-commit hooks to ensure auto-synced files like README_PYPI.md remain consistent with primary documentation.

• Enforces strict quality control by mandating Sphinx documentation builds and link checks (make html, make linkcheck) prior to final releases.

• Streamlines the transition between development branches and main, providing standardized commit message templates for clarity and traceability.

• Supports the creation of detailed, template-driven case studies for new features and capabilities using the provided docs/source/examples/case_studies/ structure.

• Always treat docs/dev_notes/release_checklist.md as the primary source of truth; this skill is a facilitator for that checklist.

• Follow the mandatory sequence: CHANGELOG first, followed by Sphinx docs, config READMEs, case studies, project READMEs, and finally the ROADMAP.

• Utilize built-in automation hooks where possible; the skill identifies when pre-commit hooks have already performed synchronization.

• Keep documentation sources clean by using Markdown for general content and reStructuredText for complex Sphinx directives.

• Requires consistent usage of version naming conventions (e.g., v0.1.X) to maintain automated roadmap progression and changelog accuracy.