> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cartesia.ai/llms.txt
> Use this file to discover all available pages before exploring further.

#  cursor prompts

# 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`.