release-notes-generator

name	release-notes-generator
description	Generate user-facing release notes from a plain-language sprint summary file — no git required. Produces 4 ready-to-use formats: changelog, email, in-app push, and social post. Triggers: 'generate release notes', 'write release notes', 'create release notes from', 'turn sprint results into release notes', 'сгенерируй release notes', 'напиши release notes', 'создай релизные заметки', 'оформи итоги спринта'.
version	1.0.0

Release Notes Generator

This skill transforms a plain-language sprint summary or product update file into polished, user-facing release notes for 4 communication channels — without git, CLI, or developer tooling. Designed for non-technical PMs, product owners, and team leads who write sprint results in plain text and need to distribute them across multiple channels.

Input:

• One local file (.md or .txt) with sprint results or product update notes
• Optional: product name, version / sprint number, audience type (users | customers | internal)

Output:

• Changelog entry — markdown-formatted, ready to paste into CHANGELOG.md
• Email announcement — subject line + body (2–4 paragraphs)
• In-app / push notification — 1–2 sentences, max 160 characters
• Social post — LinkedIn / X version, conversational tone

---

Language Detection

Detect the language of the input file:

• If the file content is in Russian: generate all 4 output formats in Russian
• If the file content is in English: generate all 4 formats in English
• If mixed-language content: default to English; add note "Mixed-language input detected — generated in English. Say 'по-русски' to switch."
• If the user's trigger phrase is in Russian but the file is in English: use English for outputs (follow the file)

---

Instructions

Step 1: Find and Read the Input File

1. Look for the file the user mentioned by name
   • If no filename given: scan the Cowork workspace for .md and .txt files; if exactly one such file exists, use it; if multiple exist, list them and ask which one to use
2. Read the file
3. Validate:
   • If no file found: stop — "No input file found. Please place your sprint summary or product update notes (.md or .txt) in the Cowork workspace and try again."
   • If the file is empty or contains fewer than 3 meaningful lines: stop — "The file is too short to generate release notes from. Add at least a few bullet points describing what was released."
   • If file is .docx or .pdf: stop — "release-notes-generator works with .md and .txt files. Please export your document to text format and try again."

Step 2: Extract Context

1. Scan the first 5–10 lines for:

   • Product name
   • Version number or sprint number (e.g., v1.4.2, Sprint 23, Release 2026-05)
   • Date (release date or sprint end date)
   • Audience type (look for signals: "for customers", "internal only", "user-facing")

2. If product name, version, or date cannot be inferred:

   • Ask in one consolidated question: "A few quick details: What's the product name? What version or sprint number is this? What's the release date? (Feel free to skip any you don't need.)"
   • Do not ask multiple separate questions

3. Set audience type:

   • Default: users
   • Override if the file explicitly states internal or customers

Step 3: Filter for User-Facing Content

1. Read all update items in the file

2. Classify each item:

   • Include — New: new features or capabilities (user-visible)
   • Include — Improved: enhancements to existing features, performance gains users notice, UI/UX changes
   • Include — Fixed: bug fixes that affected users
   • Exclude: internal refactors, technical debt cleanup, infrastructure changes, developer tooling updates, CI/CD changes, database migrations, dependency upgrades with no user impact

3. Do NOT silently drop excluded items — collect them for the "Internal Changes" note at the end of output

4. If all items are technical/internal:

   • Stop and ask: "All items appear to be internal technical changes (refactors, infrastructure). These are typically not suitable for user-facing release notes. Should I write internal-team notes instead, or do you have user-facing changes to add?"

5. Group user-facing items into 3 categories: New, Improved, Fixed

   • Omit any category with zero items (do not print empty sections)

Step 4: Generate All 4 Formats

Generate formats in this order. Use clearly delimited sections with emoji labels.

Format 1 — Changelog Entry

• Markdown code block, valid CHANGELOG.md format
• Version header with date: ## [version] — YYYY-MM-DD
• Grouped by: ### New, ### Improved, ### Fixed
• Each item: - [Feature/fix name]: [one-line plain-language description of the user benefit]
• No technical jargon; no commit hashes; no dev abbreviations

Format 2 — Email Announcement

• Subject line: specific, benefit-first (e.g., "Sprint 23 updates: new report filters, faster exports")
  • Do NOT use: "Newsletter", "Update", "Announcement", "We are pleased to announce"
• Body structure:
  • Opening sentence: lead with the biggest user benefit ("Starting today, you can...")
  • Paragraph 1: highlight 2–3 top improvements in plain language
  • Paragraph 2: list remaining changes briefly
  • Closing: 1 sentence CTA or "thank you" — keep it short
• Tone: professional but direct; no corporate fluff

Format 3 — In-App / Push Notification

• Exactly 1–2 sentences
• Maximum 160 characters (count carefully)
• Structure: verb-first + specific benefit + optional CTA
• Example shape: "[Feature] is now live — [what users can do]. [CTA]"
• If character limit is hard to hit with multiple items: pick the single most impactful update

Format 4 — Social Post (LinkedIn / X)

• 3–5 sentences
• Conversational tone — not a press release
• Opens with a hook (a question, a surprising stat, or a direct statement of value)
• Names 2–3 highlights by name
• Ends with one CTA or question
• No emojis unless user specifically requested them

After generating all 4 formats:

• List excluded technical items under ### Internal Changes (not in user-facing notes)
• If list is empty: omit this section

Step 5: Offer Blog Intro

After the 4 formats, add a single line:

"Want me to add a blog intro paragraph? Just say so."

Do not generate it unless requested.

---

Negative Cases

• File not found: Stop — "No input file found. Please place your sprint summary (.md or .txt) in the Cowork workspace and try again."
• File too short: Stop — "The file is too short to generate release notes from. Add at least a few bullet points describing what was released."
• All items are internal/technical: Stop and ask — "All items appear to be internal technical changes. Should I write internal-team notes instead, or do you have user-facing changes to add?"
• No version or sprint number found: Ask once (consolidated with other missing fields in Step 2).
• Hotfix / patch release: Detected from keywords (hotfix, patch, urgent fix) in the filename or the first 3 lines of the file — adjust email tone to reassurance-first: "We've just pushed a fix for [issue]. Everything is back to normal."
• File is .docx or .pdf: Stop — "release-notes-generator works with .md and .txt files. Please export your document to text format and try again."
• User asks for a format not in the list (e.g., Slack message): After generating the 4 standard formats, offer: "I can also write a Slack announcement — want me to add it?"

---

Output Format

## Release Notes — [Product Name] [Version] · [Date]

---

### 📋 Changelog Entry

[markdown code block]

---

### 📧 Email Announcement

**Subject:** [Subject line]

[Email body]

---

### 📱 In-App / Push Notification

[1–2 sentences, ≤ 160 characters]

---

### 🔗 Social Post (LinkedIn / X)

[3–5 sentences]

---

### Internal Changes (not in user-facing notes)
- [List of excluded technical items — omit section if empty]

---

Edge Cases

• Single-item release: Generate all 4 formats even for one feature — scale length proportionally
• Hotfix release: Detected from keywords (hotfix, patch, urgent fix) in the filename or the first 3 lines of the file — reassurance-first tone; email opens with "We've resolved [issue]"; push says "Fixed: [issue] — all systems normal"
• Major release (many items, "major" keyword): Add a note after outputs: "This looks like a major release — a dedicated blog post might be worth the effort. Want me to draft an intro?"
• Mixed EN/RU file: Default to English; note "Mixed-language input detected — generated in English. Say 'по-русски' to switch."