hf-release-notes

# HF Release Notes ## Overview Generate release notes for huggingface_hub 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", "cli"], "url": "https://github.com/huggingface/huggingface_hub/pull/1234", "doc_diffs": [ { "filename": "docs/source/en/guides/cli.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., `## 🖥️ New CLI commands` 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 new commands or APIs, 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, commands, 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/en/guides/cli.md` → `https://huggingface.co/docs/huggingface_hub/main/en/guides/cli` **Fetch full doc pages when needed:** 1. Start by fetching the docs index page to discover the site structure: `https://huggingface.co/docs/huggingface_hub/main/en/index` 2. Based on the PR content (title, body, labels), identify which doc pages might be relevant. For example: - A CLI PR → check `https://huggingface.co/docs/huggingface_hub/main/en/guides/cli` - An Inference PR → check `https://huggingface.co/docs/huggingface_hub/main/en/guides/inference` - A new API class or method → check the corresponding reference 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/huggingface_hub/main/en/guides/...)` - In standard sections, append the doc link inline after the attribution when relevant: `- PR title by @author in #1234 — [docs](https://huggingface.co/docs/huggingface_hub/main/en/...)` - 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.8.0]` even when generating for `v1.8.0.rc0`) - One section per highlight with emoji header and narrative - Standard sections for remaining items (only include sections with items) ### 6. 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.3.8") - 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/huggingface_hub/main/en/index`