Elysia Tools
Navigation
Workflow Playbook
Review one release against its changelog, validate version syntax and Markdown references, then prepare consistent website, Slack, and PDF release notes.
Hubs
This workflow is for maintainers handing one software release to documentation reviewers and announcement owners. Start with an authoritative changelog and a specific version, not a pile of unrelated commit messages. Extract release sections, check their dates and categories, and compare the selected entries with approved change evidence. An empty section may mean the source format was not recognized, not that nothing changed. Never silently include everything under Unreleased.
Write what changed, who needs to act, and what migration or rollback guidance is actually approved. Syntax-valid SemVer does not prove that a minor bump is appropriate. Settle that judgment before publishing. Use the style checker for actionable formatting findings; safe fixes do not replace review of heading hierarchy, code examples, and missing explanations. Freeze a source revision so HTML, chat, and PDF do not drift during parallel edits.
Short notes rarely need a table of contents. For a longer document, finish the headings before generating one and run reference checks afterward. The generated anchors follow GitHub conventions; verify them in the actual website renderer. The link checker is static and cannot certify a download URL is reachable. Open required external destinations separately, including pages that need authentication.
Generate HTML for the website and Slack mrkdwn only for the destinations you need. A wide comparison table may belong in the full notes rather than chat. Rewrite unsupported tables, task lists, and image-dependent explanations into readable summaries, retaining the migration warning and full-release link. Conversion is not deployment or message delivery.
Export a PDF when reviewers or archives require it and inspect real pages for clipped tables, code overflow, and missing context across page breaks. Compare every required artifact against the master for version, date, critical instructions, and links. If one channel still contains a previous draft, regenerate it instead of fixing only the output. Record the approved revision and artifact names together. Use documentation authoring for assembling wider manuals, Markdown utilities for standalone edits, and API version review for deciding contract compatibility before these release notes are signed off.
Workflow playbook
Extract versions and categorized changes, select the intended release, compare it with approved evidence, and validate the version string without treating syntax as compatibility proof.
Fix formatting findings, review headings and code blocks manually, and complete user-facing change and migration explanations before conversion.
Generate a table of contents only when useful, then check internal anchors, link formats, and undefined references; test external URLs and renderer-specific anchors separately.
Convert the approved master to HTML and the selected announcement to Slack mrkdwn; inspect unsupported elements and compare critical facts before handing off, not automatically publishing.
SemVer validation checks syntax only. Decide compatibility and the required bump from actual changes; use the API version review workflow when contracts changed.
Skip it for a short announcement. For long notes, finalize headings first, generate navigation, and verify anchors in the destination renderer.
Keep detailed context in the website or PDF; shorten Slack copy without losing migration warnings and the canonical link. Rewrite unsupported tables and task lists explicitly.
Export a PDF with an appropriate theme, inspect page breaks and readability, and reconcile the required artifacts against the same approved source revision.