changelog-voice
npx machina-cli add skill Dragoon0x/Product-Skills/changelog-voice --openclawFiles (1)
SKILL.md
1.5 KB
Changelog Voice
Ship updates people actually want to read.
How to use
/changelog-voiceApply changelog constraints to this conversation.
Constraints
Entry Structure
- What changed (specific, concrete, no marketing language)
- Why it matters (what the user can now do that they couldn't before)
- How to use it (link or brief instruction)
Rules
- MUST lead with the user benefit, not the technical change
- MUST categorize: New, Improved, Fixed, Removed
- SHOULD include a visual (screenshot, gif, video) for UI changes
- NEVER say "various bug fixes" without specifics
- NEVER announce something as "new" that was previously broken and is now working
- SHOULD mention breaking changes prominently with migration steps
Tone
- Direct, not corporate ("You can now..." not "We are pleased to announce...")
- Honest about what's still missing or in progress
- Brief. Respect the reader's time.
- SHOULD acknowledge when a change was user-requested ("You asked, we built it")
Anti-Patterns
- Changelogs that read like marketing emails
- Burying breaking changes in a long list of improvements
- Announcing features that aren't actually available yet
- Using changelogs as a growth channel (no "invite a friend" CTAs in release notes)
- Updates without dates
Source
git clone https://github.com/Dragoon0x/Product-Skills/blob/main/skills/communication/changelog-voice/SKILL.mdView on GitHub Overview
Changelog Voice guides you to write release notes that prioritize user benefit while clearly describing what changed, why it matters, and how to use it. It enforces entry structure, category tagging, and visuals for UI updates, helping readers understand impact quickly. This makes updates less marketingy and more actionable.
How This Skill Works
Apply the Entry Structure to every item: What changed (concrete, no marketing language), Why it matters (user impact), and How to use it (instructions or links). Categorize each entry as New, Improved, Fixed, or Removed, and add a visual for UI changes when available. Surface breaking changes prominently and include migration steps and timing.
When to Use It
- When drafting public release notes for users
- When you need to explain the impact of changes beyond features
- When categorizing updates under New, Improved, Fixed, or Removed
- When presenting UI changes, including a visual
- When there are breaking changes and migration steps are needed
Quick Start
- Step 1: Outline each update with What changed, Why it matters, and How to use it
- Step 2: Decide the category (New, Improved, Fixed, Removed) and attach a visual if UI changed
- Step 3: Write concisely, lead with user benefit, add migration notes for breaking changes, and publish with a date
Best Practices
- Lead with the user benefit before technical details
- Categorize each entry as New, Improved, Fixed, or Removed
- Describe what changed, why it matters, and how to use it
- Include a visual (screenshot, GIF, video) for UI updates
- Highlight breaking changes prominently with migration steps and timing
Example Use Cases
- What changed: Added in-app search with filters. Why it matters: You can find items faster. How to use it: Open the search bar and apply filters.
- What changed: Faster checkout flow. Why it matters: Reduces cart abandonment. How to use it: Add items to cart and proceed with the streamlined checkout.
- What changed: Fixed crash when exporting reports under heavy load. Why it matters: Your data exports will not fail unexpectedly. How to use it: Try exporting again; if issue persists contact support.
- What changed: Removed the legacy analytics endpoint. Why it matters: Simplifies data access and improves performance. How to use it: Migrate to the v2 endpoint using the new API docs.
- What changed: UI labels updated for clarity (eg, Sign in instead of Log in). Why it matters: Reduces user confusion. How to use it: Look for the new labels across screens and refresh.
Frequently Asked Questions
Add this skill to your agents