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."