reachy_mini_conversation_app: Skill for OpenCode

Reachy Mini Conversation App Release Notes

Overview

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

The app is the real-time voice app that lets people talk to a Reachy Mini robot. Robots install it from a Hugging Face Space, so readers are robot owners first and contributors second: lead with what someone talking to the robot will notice.

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:

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

The doc_diffs field contains unified diffs for README.md and any .md files under docs/ changed in the PR. It 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 new thing the robot can do or answer, a noticeable change in how conversations feel, a new UI view, or a change to where user data is stored) even without the label.

Several PRs about the same theme go under one highlight (e.g., local VAD, warmup audio and transcription language all make listening better). Each highlight section follows this structure:

1. Emoji header: e.g., ## 👂 Faster listening
2. Prose summary: 2-5 sentences in flowing text. Say what was wrong or missing, what changed, and what the user gets. Use concrete numbers from the PR body when it reports measurements. Only use bullets if the content truly calls for a list (4+ distinct sub-features).
3. Code examples: only when the PR adds something a developer types (a JSON-RPC method, a profile or tool format, an env var). Cherry-pick from the doc diffs when available.
4. PR attribution lines: one bullet per PR that contributed to this highlight: - PR title by @author in #1234