New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

StarRocks Release Notes

by StarRocks in StarRocks/starrocks

Drafts English release notes for a StarRocks patch release from the PRs merged into its release branch, then opens a documentation PR and hands translation to /translate.

Apache-2.0Auto-check: notesDevelopment

Install StarRocks Release Notes

skills CLI
$ npx skills add StarRocks/starrocks --skill release-notes -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install StarRocks/starrocks release-notes --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/StarRocks/starrocks.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/release-notes .claude/skills/release-notes && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
release-notes
GitHub stars
12k
Token cost
~1.9k tokens
SKILL.md length
904 words
Files
4 (incl. scripts, references)
Skills in repo
2
Repo updated
First seen
Licence
Apache-2.0

At a glance

Drafts English release notes for a StarRocks patch release from the PRs merged into its release branch, then opens a documentation PR and hands translation to /translate.

  • Works in 8 steps: Collect the changes → Mirror the existing format → Categorize and rewrite → …
  • A new StarRocks patch release has been tagged and its notes are missing
  • SKILL.md covers Inputs, Workflow and Notes and limits
  • Runs Shell scripts from its folder; calls git, gh and bash

What it does

Given a new patch version such as 3.5.19, the agent derives the minor version, the release branch (`branch-3.5`), the notes file under `docs/en/release_notes/` and the previous tag from the newest section already in that file. A bundled script, `scripts/collect-prs.sh`, takes the two tags and returns JSON listing every PR backported between them, each already traced back to its original main PR. If no PRs come back, the agent stops and reports, since the tags probably do not exist yet.

It reads `references/format.md` and `references/categorization.md`, copies the layout, heading style and PR-link style of the newest existing section, and sorts each PR into Behavior Changes, Improvements or Bug fixes, rewriting titles for readers. PRs whose backport chain does not lead to main get a quality warning, and uncertain items are flagged rather than guessed, because the PR is the human review gate. The agent edits English only and never touches the Chinese or Japanese docs; translation goes to the existing `/translate` workflow.

When your agent uses it

  • A new StarRocks patch release has been tagged and its notes are missing
  • Sorting backported PRs into behavior changes, improvements and bug fixes
  • Opening a docs PR that is ready for the translation workflow

Example prompts

  • “Write the release notes for StarRocks 3.5.19.”
  • “Draft the English notes for the patch we just tagged and open the docs PR.”
  • “Collect the PRs between 3.5.18 and 3.5.19 and flag any that did not come from main.”

Requirements

  • Bash and the `gh` CLI, used by the PR collector script and tag lookups
  • A StarRocks checkout with the release branch and release notes files
  • Pre-approved tools (allowed-tools): Read, Edit, Grep, Glob, Bash, Agent

Workflow steps

8 steps, taken from the step headings in SKILL.md.

  1. Collect the changes
  2. Mirror the existing format
  3. Categorize and rewrite
  4. Write the section
  5. Lint (required so the translation comment appears)
  6. Open the PR
  7. Flag PR-quality issues (when unresolved_count > 0)
  8. Hand off translation

What it can do on your machine

Read from SKILL.md and the folder at commit 616669c. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Read
    • Edit
    • Grep
    • Glob
    • Bash
    • Agent

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Ships 1 file in scripts/ (Shell), which the agent can run.

    Shell commands in SKILL.md call:

    • git
    • gh
    • bash

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git and gh, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

StarRocks Release Notes loads about 1.9k tokens when it runs, and up to ~4.2k if it reads all its reference files. Until then it costs about 76 tokens; SKILL.md has 904 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~76
When it runs · the whole SKILL.md, loaded when a task matches
~1.9k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~4.2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NotePre-approves every shell command (allowed-tools: Bash)SKILL.md
    allowed-tools: Read, Edit, Grep, Glob, Bash, Agent

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from StarRocks/starrocks at commit 616669c, republished under its Apache-2.0 licence (© StarRocks). 904 words, ~1,950 tokens.

Download SKILL.mdSave it as .claude/skills/release-notes/SKILL.md (or your agent's skills folder). This skill also uses 3 other files; get the full folder from GitHub.
name
release-notes
description
Draft StarRocks release notes for a patch version from the PRs merged into its release branch, then open a [Doc] PR that hands off to the /translate workflow for Chinese and Japanese. Use when a new patch release (e.g. 3.5.19) has been tagged and English release notes are not yet written.
allowed-tools
Read, Edit, Grep, Glob, Bash, Agent
argument-hint
[version] e.g. 3.5.19

StarRocks Release Notes

Generate the English release-notes section for a tagged StarRocks patch release, open a [Doc] PR for it, and hand off Chinese/Japanese translation to the existing /translate workflow. English only — never edit docs/zh/** or docs/ja/**.

Read references/format.md (exact output format) and references/categorization.md (how to map and rewrite PRs) before drafting. The PR is the human review gate, so favor a complete, accurate draft with uncertain items flagged over silent guessing.

Inputs

  • $ARGUMENTS = the new patch version, e.g. 3.5.19. If absent, ask for it.
  • Derive once and reuse (examples shown for 3.5.19):
    • minor = <MAJOR>.<MINOR> (e.g. 3.5), branch = branch-<minor> (e.g. branch-3.5)
    • file = docs/en/release_notes/release-<minor>.md (e.g. docs/en/release_notes/release-3.5.md)
    • prev tag = the previous patch (e.g. 3.5.18) — the newest ## X.Y.Z already in file; read it to confirm rather than assuming.

Use the derived file path everywhere below — do not hardcode release-3.5.md.

Workflow

1. Collect the changes

Run the collector and capture its JSON:

bash
bash .claude/skills/release-notes/scripts/collect-prs.sh <prev_tag> <new_tag>
# e.g. collect-prs.sh 3.5.18 3.5.19

It returns { release_date_raw, pr_count, prs: [{number,title,url,base,resolved_to_main,labels,body_excerpt}], unresolved_count, unresolved: [...] } for every PR backported between the two tags. If pr_count is 0, stop and report — the tags likely don't exist yet or the order is wrong (gh api repos/StarRocks/starrocks/tags).

Each PR's number is already resolved to the original main PR (release notes always cite the main PR). release_date_raw is only a suggestion (the tag/commit date) — see step 4 for the actual release date.

unresolved lists any PR whose backport chain did not trace back to main (resolved_to_main: false, e.g. a fix authored directly against a release branch). These need a PR-quality warning — see step 7.

2. Mirror the existing format

Read the top of the target file — the frontmatter, the :::warning block, and the current newest ## X.Y.Z section. Match its heading casing, the The following issues have been fixed: line, and the PR-link style. Do not change frontmatter.

3. Categorize and rewrite

Apply references/categorization.md:

  • Map each PR to Behavior Changes / Improvements / Bug fixes; exclude [Doc]/[UT]/[Tool] and behavior-neutral [Refactor].
  • Rewrite each title into a user-facing sentence (strip prefixes/scope, backtick identifiers), grouping closely related PRs with space-separated links.
  • Build a "Needs reviewer confirmation" list for uncertain section choices, terse titles, or possible upgrade/downgrade-warning items. This list goes in the PR body, not the release notes.
  • Release date — always ask the user. The official release date is set by QA and product management and is not necessarily the tag/commit date. Prompt the user: "What is the official release date for <new_tag>?", offering the detected release_date_raw (formatted Month D, YYYY) only as a suggested default. Use the user's answer for the Release date: line. Do not proceed to write the section until the date is confirmed.
4. Write the section

Insert the new ## X.Y.Z section into file per references/format.md: directly below the closing ::: of the :::warning block and above the current newest patch section. Omit empty subsections. English file only.

5. Lint (required so the translation comment appears)

The Translation Status Check workflow only posts the language checkboxes after markdownlint passes, so the diff must be clean. Lint the derived file, and note the Vale config lives at docs/.vale.ini and resolves its styles relative to docs/ — run Vale from the docs/ directory:

bash
# from the docs/ directory, using the version-derived file (e.g. release-3.5.md)
cd docs && vale --config=.vale.ini en/release_notes/release-<minor>.md

Also run the repo's markdownlint (docs/.markdownlint.json) if available. Fix any issues. Re-confirm frontmatter/description is unchanged.

Show full SKILL.md (375 more words)Show less
6. Open the PR
bash
git checkout -b release-notes-<new_tag>           # e.g. release-notes-3.5.19
git add docs/en/release_notes/release-<minor>.md  # the derived file, e.g. release-3.5.md
git commit -s -m "[Doc] Add release notes for StarRocks v<new_tag>"
git push -u origin release-notes-<new_tag>
gh pr create --title "[Doc] Add release notes for StarRocks v<new_tag>" --body-file <body>

Fill .github/PULL_REQUEST_TEMPLATE.md for the body:

  • What type of PR: check - [x] Doc.
  • Change in behavior: check - [x] No (the notes themselves don't change product behavior).
  • Checklist: this PR is the user documentation; leave test-case boxes unchecked.
  • Bugfix cherry-pick branch check: this is a docs PR, not a code backport — leave the version boxes (4.1/4.0/3.5) unchecked unless the user says otherwise.
  • Append the "Needs reviewer confirmation" list under "What I'm doing" so reviewers verify the flagged entries.
7. Flag PR-quality issues (when unresolved_count > 0)

If the collector reported any unresolved PRs (backport chain that never reached main), post a single warning comment on the release-note PR so reviewers can act on it. Do not silently drop it — these often indicate a fix that skipped main and may be missing from main/future releases (a regression risk), not just a citation quirk.

bash
gh pr comment <pr-number> --repo StarRocks/starrocks --body-file <warning>

For each unresolved PR, state in the comment: the number cited in the notes and its base branch (not main), that no main PR was found, and the two impacts — (1) the citation is inconsistent with the other entries, and (2) verify the fix exists on main; forward-port if missing. Ask the author to confirm the correct PR number to cite. (Skip this step entirely when unresolved_count is 0.)

8. Hand off translation

Stop and tell the user:

  • Only the derived English file (e.g. docs/en/release_notes/release-3.5.md) changed.
  • Once CI DOC Checker → markdownlint passes on the PR, the "🌎 Translation Required?" comment will auto-post with zh and ja checkboxes.
  • A docs-maintainer checks the desired boxes and replies /translate; the Translation Runner workflow (StarRocks/doc-translator v1.0.1) then commits the Chinese and Japanese versions into the same PR.

Notes and limits

  • Whole-file translation: /translate re-translates the entire file, not just the new section. This is the existing established behavior — rely on it; do not change the pipeline or pre-edit zh/ja.
  • Behavior changes are detected heuristically; the "Needs reviewer confirmation" list plus PR review is the safety net (docs/CLAUDE.md: never assert unverified technical facts).
  • Portability: the only release-specific values are version, branch, file path, and repo. The same skill structure serves other StarRocks lines (e.g. a commercial product) by swapping those constants — author original content, do not copy notes across products.
  • Commits must use git commit -s (DCO sign-off).

© StarRocks, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 3 other files (scripts, references) in .claude/skills/release-notes of StarRocks/starrocks.

  • SKILL.md
  • references/categorization.md
  • references/format.md
  • scripts/collect-prs.sh

Open the folder on GitHubat commit 616669c

Compare with similar skills

StarRocks Release Notes next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

StarRocks Release Notes compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
StarRocks Release Notes this skillStarRocks/starrocks12k—~1.9kAutomated safety check: NotesApache-2.0
Opik Documentation Patternscomet-ml/opik22k—~1.3kAutomated safety check: PassApache-2.0
Change Documentation Writerjsmastery-pro/skills1.4k—~2.4kAutomated safety check: NotesMIT
Technical Writingfrappe/skills146—~1.1kAutomated safety check: PassNone
Avoid AI Writingwshobson/agents40k—~1.9kAutomated safety check: PassMIT
Pull Requestcloudposse/atmos1.4k—~3.5kAutomated safety check: PassApache-2.0

Similar skills

  • Opik Documentation Patterns

    comet-ml/opik

    Rules for writing PR descriptions, changelog entries and feature documentation in the Opik repository, including the exact headings that CI requires.

    22k GitHub stars~1.3k tokensUpdated today
    DevelopmentAuto-check passed

  • Change Documentation Writer

    jsmastery-pro/skills

    Writes PR descriptions, changelog entries, release notes and postmortems from the actual commits and diff, and saves each one in the right place.

    1.4k GitHub stars~2.4k tokensUpdated 1 mo ago
    DevelopmentAuto-check: notes

  • Technical Writing

    frappe/skills

    Write prose in "Simplified Technical English". An agent skill from frappe/skills.

    146 GitHub stars~1.1k tokensUpdated 7 days ago
    DevelopmentAuto-check passed

  • Avoid AI Writing

    wshobson/agents

    Audit and rewrite prose so it stops reading as machine-generated.

    40k GitHub stars~1.9k tokensUpdated 3 days ago
    DevelopmentAuto-check passed

  • Pull Request

    cloudposse/atmos

    PR workflow: pick the right semver label (no-release / patch / minor / major), decide when to add a changelog blog post, when to update the roadmap, and how to do each correctly.

    1.4k GitHub stars~3.5k tokensUpdated today
    DevelopmentAuto-check passed

  • Levyra Humanizer

    LUC4N3X/Levyra-deepsound

    Apply a compact final prose pass to Levyra pull request descriptions, release notes, and owner-facing writing so it sounds natural without changing facts, evidence, structure, or validation state.

    543 GitHub stars~719 tokensUpdated today
    DevelopmentAuto-check passed

More from StarRocks/starrocks

  • StarRocks SQL Doc Auto-Fix

    StarRocks/starrocks

    Proposes verified fixes for failing SQL examples in StarRocks docs across three languages and several versions, then opens draft pull requests and never merges.

    12k GitHub stars~7.6k tokensUpdated today
    Auto-check: notes

Categories

Questions about StarRocks Release Notes

What does StarRocks Release Notes do?

Drafts English release notes for a StarRocks patch release from the PRs merged into its release branch, then opens a documentation PR and hands translation to /translate. 5`), the notes file under `docs/en/release_notes/` and the previous tag from the newest section already in that file.sh`, takes the two tags and returns JSON listing every PR backported between them, each already traced back to its original main PR.

When should I use StarRocks Release Notes?

StarRocks Release Notes fits situations like: A new StarRocks patch release has been tagged and its notes are missing; sorting backported PRs into behavior changes, improvements and bug fixes; opening a docs PR that is ready for the translation workflow.

How do I install StarRocks Release Notes in Claude Code?

Run `npx skills add StarRocks/starrocks --skill release-notes -a claude-code`. Or copy the skill folder (.claude/skills/release-notes in StarRocks/starrocks) into .claude/skills/release-notes in your project. Claude Code loads it when a task matches its description.

How do I install StarRocks Release Notes in Codex?

Run `npx skills add StarRocks/starrocks --skill release-notes -a codex`. Or copy the skill folder (.claude/skills/release-notes in StarRocks/starrocks) into .agents/skills/release-notes in your project. Codex loads it when a task matches its description.

Can I use StarRocks Release Notes in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add StarRocks/starrocks --skill release-notes -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/release-notes, .gemini/skills/release-notes, .github/skills/release-notes and .opencode/skills/release-notes in your project.

What does StarRocks Release Notes need to run?

Going by SKILL.md and its folder, StarRocks Release Notes needs a shell for the scripts in its folder and the command-line tools its instructions call (git, gh and bash). Our summary lists: Bash and the `gh` CLI, used by the PR collector script and tag lookups; A StarRocks checkout with the release branch and release notes files. Its frontmatter pre-approves these tools: Read, Edit, Grep, Glob, Bash, Agent.

Does StarRocks Release Notes access the network?

SKILL.md contains no URLs. Its commands use git and gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is StarRocks Release Notes safe to install?

Our automated static check of SKILL.md found notes only (pre-approves every shell command (allowed-tools: bash)), nothing it rates as a warning. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does StarRocks Release Notes use?

StarRocks Release Notes is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does StarRocks Release Notes use?

About 1.9k tokens (SKILL.md is roughly 7.8k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 2.2k tokens, read only when the agent opens those files.

What are the alternatives to StarRocks Release Notes?

Skills that share tags, products or a category with StarRocks Release Notes: Opik Documentation Patterns (comet-ml/opik, 22k stars), Change Documentation Writer (jsmastery-pro/skills, 1.4k stars), Technical Writing (frappe/skills, 146 stars) and Avoid AI Writing (wshobson/agents, 40k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains StarRocks Release Notes?

StarRocks (a GitHub organization) maintains it in StarRocks/starrocks, which has 12,158 GitHub stars. The repository holds 2 skills in this directory. The repository was last updated on October 7, 2026.

Source: StarRocks/starrocks on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.