Cursor prompts for changelog drafting

Use these prompts when drafting the monthly changelog from repo activity. They filter noise and produce structured output you can turn into the final MDX. Rule of thumb: Most commits are internal. Your job is to surface the ~10% that materially affect users (developers and solution architects). Answer “Why should I care?” not “What did engineers do?”.

Step 1 — Get commit or merge data

Obtain commit/merge data for the month from your repos (e.g. git log --since YYYY-MM-01 --until YYYY-MM-31 --format="%h|%ad|%s" or your GitHub PR list). Format as hash|date|subject if possible. Paste in chunks if the list is large (e.g. 100–200 lines per paste). Prefer merges if your PR titles are good.

Phase 1 — Classify by user impact

Paste the commit/merge list (one repo at a time) and run this prompt.

You are acting as a product release manager for a voice AI API and playground company.

Your job:
- Analyze the commit messages below (format: hash|date|subject).
- Infer user-facing impact for developers and solution architects.
- Ignore internal-only changes unless they affect reliability, performance, or security.
- Group related commits into a single product-level change where it makes sense.
- Identify: breaking changes, deprecated features, new features, major fixes, reliability/performance improvements.

Output valid JSON only, no commentary:

{
  "added": [ "one-line product-level description" ],
  "improved": [ "one-line product-level description" ],
  "fixed": [ "one-line product-level description" ],
  "deprecated": [ "one-line + migration note if obvious" ],
  "breaking": [ "one-line + migration note if obvious" ],
  "internal": [ "only if reliability/performance/security; otherwise omit" ]
}

Rules:
- Only include items that materially affect users. Be conservative.
- Do not hallucinate; only infer from the commit messages.
- Collapse small commits into coherent product-level changes.
- One entry per logical change, not per commit.

Repeat for each repo (product, bifrost, docs). Merge the JSON outputs mentally or in a doc so you have one combined classification for the month.

Phase 2 — Map to our sections and suggest title/description

We ship one changelog per month. Our section list is fixed. Use the classified items from Phase 1 and run:

Using the classified changes from Phase 1 (added / improved / fixed / deprecated / breaking):

1. Map each item to exactly one of our changelog sections:
   - Breaking / Deprecated
   - API
   - Playground / UI
   - Line / Agents
   - Models / Voices
   - Docs
   - Other

2. Suggest a short **title** for the month (e.g. "March 2026") and a one-line **description** for the frontmatter (e.g. "API improvements, Line SDK updates, and playground fixes").

3. For each section that has items, list the bullets we should include (developer-oriented, specific). Add a note when a doc link would help (e.g. [Docs: /line/sdk/agents]).

4. Put breaking/deprecated at the top. Omit empty sections.

Output in a clear structure (markdown or list) so we can copy into the MDX draft.

Phase 3 — Convert to MDX

We use MDX with a consistent structure. No emojis in headers. Sections are ### Section name.

Convert the sectioned list above into a new month section for the **year file** (e.g. `changelog/2026.mdx`).

Requirements:
- Add a top-level section: ## Month YYYY (e.g. ## March 2026).
- Start with an **Overview** paragraph (one short sentence summarizing what changed).
- Section headers: ### Breaking / Deprecated, ### API, ### Playground / UI, ### Line / Agents, ### Models / Voices, ### Docs, ### Other. Omit sections that are empty.
- Use clear, developer-oriented bullets. Be specific; avoid "various fixes" or "improvements."
- For breaking changes, add short migration guidance or link to docs where relevant.
- Tone: similar to Stripe or Cloudflare release notes — direct, scannable.
- Where we noted [Docs: path], add a link in the bullet.
- Use **bold** for endpoint names, model names, or feature names when they first appear.

Copy the output into the correct year file (e.g. for March 2026, edit changelog/2026.mdx and add a new ## March 2026 section with the overview and product-area sections). Fix any links or details. Cross-check the Reference section in _process.md for API versions and Line releases so dates and names are correct.

Phase 4 — Strategic layer (optional)

Use this when you want to emphasize certain changes for positioning (website, customer email, investor update).

Which of the changes in this month’s changelog are strategically important for positioning?

Mark or list:
- Enterprise credibility (compliance, security, scale)
- Performance / reliability (SLAs, benchmarks, uptime)
- Security upgrades
- API maturity (versioning, deprecation policy, new capabilities)

Suggest which 1–3 items should be emphasized in:
- The changelog description or “highlights”
- A customer email
- Investor or board update

Summary

Step	What you do
Before	Get commit or merge data for the month (e.g. git log or PR list).
Phase 1	Paste commits or merges (one repo at a time, in chunks). Get JSON: added / improved / fixed / deprecated / breaking.
Phase 2	Map to our sections; get title, description, and sectioned bullets.
Phase 3	Convert to MDX; add as new month section in `changelog/YYYY.mdx`.
Phase 4	Optionally flag strategic items for positioning.

Then run Review and Publish from _process.md.

​Cursor prompts for changelog drafting

​Step 1 — Get commit or merge data

​Phase 1 — Classify by user impact

​Phase 2 — Map to our sections and suggest title/description

​Phase 3 — Convert to MDX

​Phase 4 — Strategic layer (optional)

​Summary