# Reachy Mini Release Notes

> Generate Reachy Mini (reachy_mini) release notes from cached PR JSON files. Use when asked to draft release notes from PR files.

- Skill: `pollen-robotics/reachy-mini-release-notes` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add pollen-robotics/reachy-mini-release-notes`
- Raw SKILL.md: https://api.skillmd.com/api/skills/pollen-robotics/reachy-mini-release-notes/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: pollen-robotics (https://skillmd.com/u/pollen-robotics)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/pollen-robotics/reachy-mini-release-notes

---


# Reachy Mini Release Notes

## Overview

Generate release notes for reachy_mini from cached PR JSON files. This skill reads PR metadata, categorizes entries, and produces a formatted markdown release notes document.

**Output directory:** The prompt will specify the output directory as `<output_dir>`. All paths below use this placeholder.

## Workflow

### 1. Read PR data

Read all PR JSON files from `<output_dir>/tmp/pr_*.json`. Each file contains:

```json
{
  "number": 1234,
  "title": "...",
  "author": "username",
  "merged_at": "2026-01-15T10:30:00Z",
  "body": "...",
  "labels": ["highlight", "sdk"],
  "url": "https://github.com/pollen-robotics/reachy_mini/pull/1234",
  "doc_diffs": [
    {
      "filename": "docs/source/examples/head_tracking.md",
      "status": "modified",
      "patch": "@@ -10,6 +10,10 @@ ..."
    }
  ]
}
```

The `doc_diffs` field contains unified diffs for any `.md` files under `docs/` that were
changed in the PR. This is empty (`[]`) for PRs with no documentation changes.

### 2. Identify highlights

A PR should be highlighted if:
- It has the `"highlight"` label on GitHub, **or**
- You judge it significant enough to deserve a detailed section (e.g., a major new
  feature, a meaningful UX improvement, or a notable breaking change) even without the label.

Use your judgment — not every feature PR needs a highlight, but don't limit highlights
to only labeled PRs. Each highlight section follows this structure:

1. **Emoji header** — e.g., `## 🎥 Camera JPEG streaming`
2. **Prose summary** — 2-5 sentences describing the user-visible change in flowing text.
   Avoid bullet points here; write natural sentences. Only use bullets if the content
   truly calls for a list (e.g., enumerating 4+ distinct sub-features).
3. **Code examples** — if the PR introduces a new SDK API, daemon route, or CLI, include
   a fenced code block with a concrete usage example (cherry-pick from doc diffs when available).
4. **PR attribution lines** — one bullet per PR that contributed to this highlight:
   `- PR title by @author in #1234`

### 3. Classify standard items

For non-highlight PRs, classify into sections using `references/sections.md` heuristics based on:
- PR labels
- PR title keywords
- PR body content

### 4. Use doc diffs and fetch relevant documentation

For highlighted PRs and other PRs that introduce new features or APIs:

**Use doc diffs first:**
- Check the `doc_diffs` field in the PR JSON. If present, these contain the actual
  documentation changes made in the PR (unified diff format).
- Use these diffs to understand what was documented, extract code examples, and write
  more accurate summaries. The diffs show exactly what the PR author wrote in the docs.
- The `filename` field maps to a docs page URL. For example,
  `docs/source/examples/head_tracking.md` → `https://huggingface.co/docs/reachy_mini/examples/head_tracking`

**Fetch full doc pages when needed:**
1. Start by fetching the docs index page to discover the site structure:
   `https://huggingface.co/docs/reachy_mini/index`
2. Based on the PR content (title, body, labels), identify which doc pages might be
   relevant (e.g. an SDK PR → an examples/tutorial page; a troubleshooting fix → a
   troubleshooting page).
3. Fetch the candidate doc page to confirm it covers the feature from the PR.
4. Only include a doc link if the page genuinely documents the feature.

**How to reference:**
- In highlight sections, add a line like:
  `📚 **Documentation:** [Guide name](https://huggingface.co/docs/reachy_mini/...)`
- In standard sections, append the doc link inline after the attribution when relevant:
  `- PR title by @author in #1234 — [docs](https://huggingface.co/docs/reachy_mini/...)`
- Do NOT add doc links for internal/CI/test PRs or PRs that don't have user-facing docs.
- Do NOT fabricate doc URLs — only link to pages you have actually fetched and verified.

### 5. Generate release notes

Output to `<output_dir>/RELEASE_NOTES_<version>.md` using the structure from `references/release-notes-template.md`:

- Title: `# [vX.Y.Z] <tagline>` (derive tagline from main highlights; always use the base version without prerelease suffix, e.g. `[v1.10.0]` even when generating for `v1.10.0rc1`)
- One section per highlight with emoji header and narrative
- Standard sections for remaining items (only include sections with items)

### 6. Bullet style (apply to EVERY bullet, in highlights and standard sections)

The text before `by @author in #1234` is a summary you write — **do not paste the raw
PR/branch/commit title verbatim**. Rewrite it into a short, human-readable phrase:

- **Always start with a capital letter.**
- **Never start with a number.** Drop any leading PR/issue number (it's already in the
  trailing `#1234`), e.g. `928 improve physical ci` → `Improve physical CI`.
- **Strip conventional-commit / branch prefixes**: `feat:`, `feat(x):`, `fix:`, `docs:`,
  `chore:`, `feat/…`, `docs/…`, etc. E.g. `feat/bluetooth/wifi scan and connect` →
  `Bluetooth/Wi-Fi scan and connect`; `docs(animation): two-phase proposal` →
  `Two-phase animation proposal`.
- **Don't restate the section**: inside `🐛 Bug and typo fixes` don't begin with
  "Fix"/"Bug"; inside `📖 Documentation` don't begin with "docs"/"Add docs" — the
  category already says it.
- Keep phrasing concise and consistent in mood across the whole release.

### 7. Quality checks

Before finishing:
- Verify every PR from `<output_dir>/tmp/` appears exactly once
- **Do NOT include any PR that does not have a corresponding file in `<output_dir>/tmp/`** — those PRs belong to a different release and must not appear in these notes
- No empty sections
- Consistent emoji headings
- Every item ends with attribution: `by @author in #1234`
- Doc links point to real, verified pages

## Input

- Version string (e.g., "v1.10.0")
- PR JSON files in `<output_dir>/tmp/`

## Output

- Release notes markdown at `<output_dir>/RELEASE_NOTES_<version>.md`

## Resources

- `references/release-notes-template.md`: Skeleton structure for release notes
- `references/sections.md`: Keyword-based section mapping and guidance
- Documentation site: `https://huggingface.co/docs/reachy_mini/index`