Agent skill

Chat Release Notes

by epam in epam/ai-dial-chat

A skill your agent uses when the user asks to enhance, refine, polish, or "look at" the release notes for a tag — typically a fresh CI-generated pre-release (e.g.

Apache-2.0Auto-check passedDevelopment

Install Chat Release Notes

skills CLI
$ npx skills add epam/ai-dial-chat --skill chat-release-notes -a claude-code

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

GitHub CLI
$ gh skill install epam/ai-dial-chat chat-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/epam/ai-dial-chat.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/release-notes .claude/skills/chat-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
chat-release-notes
GitHub stars
504
Token cost
~5.7k tokens
SKILL.md length
2,365 words
Files
1
Skills in repo
18
Repo updated
First seen
Licence
Apache-2.0

At a glance

A skill your agent uses when the user asks to enhance, refine, polish, or "look at" the release notes for a tag — typically a fresh CI-generated pre-release (e.g.

  • Works in 9 steps: Resolve target and reference styles → Pull source context for each bullet → Cross-check config-registry.constants.ts… → …
  • The user asks to enhance
  • SKILL.md covers When to use, Inputs, Workflow and Output format, plus 3 more sections
  • Calls gh and git

What it does

Chat Release Notes is an agent skill from epam/ai-dial-chat. Use when the user asks to enhance, refine, polish, or "look at" the release notes for a tag — typically a fresh CI-generated pre-release (e.g. 0.45.0-rc.55) or a stable cut. Reads the auto-generated notes off the GitHub release, classifies and rewrites each bullet in this project's editorial voice, builds the Deployment Changes section from apps/chat-api's config registry / env-var source / PR bodies, and saves a draft to claude/release-notes/. Never edits GitHub directly.

Its SKILL.md is about 5.7k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Changelog and release notes. It works with GitHub. The repository describes itself as: A default UI for AI DIAL. The licence is Apache-2.0.

When your agent uses it

  • The user asks to enhance
  • Look at the release notes for a tag — typically a fresh CI-generated pre-release (e.g

Example prompts

  • “look at”
  • “/chat-release-notes”

Requirements

  • Pre-approved tools (allowed-tools): Read, Grep, Glob, LSP, Bash(gh release view:*), Bash(gh release list:*), Bash(gh pr view:*), Bash(gh pr list:*), Bash(gh pr diff:*), Bash(git log:*), Bash(git show:*), Bash(git diff:*), Bash(git tag:*), Bash(git rev-parse:*), Bash(date:*), Write(claude/release-notes/*), Bash(mkdir -p claude/release-notes)

Workflow steps

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

  1. Resolve target and reference styles
  2. Pull source context for each bullet
  3. Cross-check config-registry.constants.ts / source for deployment changes
  4. Classify each bullet (move things between sections, drop the noise)
  5. Rewrite each kept bullet
  6. Build the Deployment Changes section
  7. Pre-release / delta handling
  8. Save the draft (and optional editorial companion)
  9. Verify nothing was pushed to GitHub

What it can do on your machine

Read from SKILL.md and the folder at commit 933c12c. 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
    • Grep
    • Glob
    • LSP
    • Bash(gh release view:*)
    • Bash(gh release list:*)
    • Bash(gh pr view:*)
    • Bash(gh pr list:*)
    • Bash(gh pr diff:*)
    • Bash(git log:*)

    …and 7 more on the same allowed-tools line.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • gh
    • git

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

  • Network

    No URLs in SKILL.md. Its commands use gh and git, 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

Chat Release Notes loads about 5.7k tokens when it runs. Until then it costs about 126 tokens; SKILL.md has 2,365 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~126
When it runs · the whole SKILL.md, loaded when a task matches
~5.7k

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 passed

The automated check found no risky patterns in SKILL.md.

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); files beside SKILL.md are not scanned.

SKILL.md

The full file from epam/ai-dial-chat at commit 933c12c, republished under its Apache-2.0 licence (© epam). 2,365 words, ~5,712 tokens.

Download SKILL.mdSave it as .claude/skills/chat-release-notes/SKILL.md (or your agent's skills folder).
name
chat-release-notes
description
Use when the user asks to enhance, refine, polish, or "look at" the release notes for a tag — typically a fresh CI-generated pre-release (e.g. `0.45.0-rc.55`) or a stable cut. Reads the auto-generated notes off the GitHub release, classifies and rewrites each bullet in this project's editorial voice, builds the `Deployment Changes` section from `apps/chat-api`'s config registry / env-var source / PR bodies, and saves a draft to `claude/release-notes/`. Never edits GitHub directly.
allowed-tools
Read, Grep, Glob, LSP, Bash(gh release view:*), Bash(gh release list:*), Bash(gh pr view:*), Bash(gh pr list:*), Bash(gh pr diff:*), Bash(git log:*), Bash(git show:*), Bash(git diff:*), Bash(git tag:*), Bash(git rev-parse:*), Bash(date:*), Write(claude/release-notes/*), Bash(mkdir -p claude/release-notes)
disable-model-invocation
true
argument-hint
[tag]
arguments
tag
model
opus
effort
xhigh
context
fork
agent
general-purpose

DIAL Chat release-notes enhancer

The CI publishes a release for every tag with bullets that are just the PR titles. Those bullets carry a lot of dirt — conventional-commit prefixes (feat(chat):, fix(chat):, feat(chat-e2e):, fix(overlay):), branch-style phrasing inherited from the PR title, duplicate entries when the same issue was patched twice (e.g. two (Issue #4696) (#6135) / (#6430) bullets in 0.45.0), Revert "..." lines that were never reconciled with their original entry, and a ## Other section that mixes maintainer-relevant bumps with pure tooling churn. The releases visible at https://github.com/epam/ai-dial-chat/releases from 0.43.x through 0.45.1 are what those raw notes look like after a human editorial pass. This skill reproduces that pass.

You are running in a forked, isolated context. Read and research freely — only the final summary you return reaches the main conversation. All file writes happen in this fork; the draft lands at claude/release-notes/<tag>-draft.md.

When to use

  • "Enhance the release notes for 0.45.0-rc.55"
  • "Look at the latest pre-release notes and refine them"
  • "Help me adjust release notes for the current rc"
  • "The CI just published <tag>, make it readable"

Do not trigger on requests like "what changed in 0.45.0?" — that is a recall question, not a notes-editing task.

Inputs

tag = $tag — the GitHub release tag to enhance (e.g. 0.45.0-rc.55, 0.46.0). If empty, pick the most recent tag from gh release list --limit 5 and confirm with the user before editing.

Workflow

1. Resolve target and reference styles
  1. gh release view <tag> --json body,name,tagName — capture the raw CI notes.
  2. gh release list --limit 10 — locate the previous tag of the same kind (last stable for a stable release, the predecessor rc for a delta rc.N+1).
  3. gh release view <prev-stable-tag> --json body and gh release view <prev-rc-tag> --json body (when relevant) — these are the style anchors. The user has repeatedly insisted "keep the same format as the latest stable release" and "your notes are too verbose" — match the terseness of those notes, not your own instincts. One line per bullet.
  4. git tag --list | sort -V + git log <prev-tag>..<tag> --oneline — full commit list for the range, so you can spot hotfix commits the CI dropped because they had no PR.
2. Pull source context for each bullet

For every bullet in the raw notes:

  1. Parse out the trailing #<issue> (#<PR>) or (#<PR>). If only a PR number is present, that's the canonical reference; if both, keep #<issue> (#<PR>) order.
  2. gh pr view <PR> --json title,body,labels — read the PR body, not just the title. The body is where the why and the what-it-replaces live; the title is usually too compressed.
  3. For bullets without a PR number, find the commit with git log <prev-tag>..<tag> --oneline | grep -i <keywords> and git show <hash> — usually a hotfix commit that should fold into a related entry.
  4. If a PR body references a doc under docs/, apps/chat-api/README.md, or libs/chat-overlay/README.md, skim it for the headline framing. Use the dial-docs skill to resolve which doc under docs/ is authoritative rather than guessing a filename.
3. Cross-check config-registry.constants.ts / source for deployment changes

The frontend (apps/chat) does not read env vars directly — all runtime config and feature flags are resolved server-side by apps/chat-api and served to the client through AppConfigContext. The Deployment Changes section is built from primary sources, not PR titles:

  • git diff <prev-tag>..<tag> -- apps/chat-api/src/app-config/config-registry/config-registry.constants.ts — this CONFIG_DEFINITIONS array is the canonical registry for both operator-facing config values and feature flags. Each entry has key, type ('config' or 'feature'), valueType, visibility, defaultValue, description, owner, and optionally envVar / allowedRolesEnvVar. Additions/removals/changed defaultValue here are deployment-relevant.
  • git diff <prev-tag>..<tag> -- apps/chat-api/src/config/environment.config.ts — the EnvironmentVariables class validated at boot; this is the source of truth for raw env var names, whether they're required, and their type/validation. Code wins over docs when a name conflicts.
  • git diff <prev-tag>..<tag> -- apps/chat-api/README.md — curated, human-readable env var tables (grouped by concern: auth, DIAL Core, themes, file transfer/archives, deployments/catalog, voice/ASR, utility model). Use these for the description/default columns, but verify the canonical name against environment.config.ts or the envVar field in config-registry.constants.ts — past releases have caught doc typos this way.
  • Confirm defaults by reading the defaultValue field in config-registry.constants.ts, or the access-site fallback in environment.config.ts when the var isn't in the registry.
  • Entries in CONFIG_DEFINITIONS with type: 'feature' are the feature flags (see apps/chat-api/src/app-config/feature-flags/feature-key.enum.ts for the FeatureKey enum backing them). A removed entry means the flag no longer has any effect. The registry's description field is the source of truth for what the flag does — same "code wins" rule as env vars. Flags are resolved dynamically (env var + optional allowedRolesEnvVar role restriction) via FeatureFlagsService, not through a single ENABLED_FEATURES blob — do not describe them as such.
4. Classify each bullet (move things between sections, drop the noise)

The raw notes' ## Features / ## Fixes / ## Other partition is unreliable because CI keys it off the conventional-commit prefix in the PR title. Reclassify by the change's actual user impact:

Where CI put itWhere it belongsRule
Other starting with feat(...)FeaturesA feat that lost its slot to a scope prefix.
Other starting with fix(...)FixesSame, for fix.
Features / Fixes for a pre-release-only regressionFixes with note "(affects pre-release users of <feature> only)"Don't surface a transient bug as a feature.
Other for a security CVE bumpFixesSecurity items are user-relevant.
Multiple PRs / hotfix commits on one featureone folded entry under the appropriate sectionCite the commit hashes or PR numbers in parens.

Drop these from the notes entirely — they have no consumer-visible effect:

  • All feat(chat-e2e): / fix(chat-e2e): / chore(chat-e2e): items unless the PR also touches apps/chat/src in a behavior-changing way (verify via gh pr view --json files).
  • Pure refactors / formatting / lint / tsconfig / nx.json / project.json / Nx project-graph shuffles (chore(chat): refactor utils, chore: bump nx).
  • CI / workflow changes (.github/workflows/**) unless a maintainer needs to know — then keep under Other with a one-line rationale.
  • Pure dependency bumps with no CVE / no behavior delta (chore: bump types/node).
  • Merge remote-tracking branch … commits.
  • Claude Code agent setup / docs / skill scaffolding.

Keep in Other — items maintainers, embedders, or themers care about even if they're not features:

  • Security-adjacent dependency bumps (bump axios, bump next).
  • dial-ui-kit (visible default styles).
  • Forwarded-headers / auth-handling checks.
  • Issue templates, contributor docs (visible to contributors).

If you find yourself unsure whether to drop a bullet, ask: would a customer reading these notes care that this happened? If no, drop it.

5. Rewrite each kept bullet

The raw form is * <conventional-prefix(scope)>: <PR title> (Issue #<N>) (#<PR>). Rewrite to:

* <Active-voice description of what changed> — <brief why-it-matters or what-it-replaces> (Issue #<N>) (#<PR>)

Rules in order of importance:

  1. One line per bullet. No multi-paragraph descriptions. The user has explicitly flagged "too verbose" in prior runs. If you need more detail, save it to the companion editorial-notes file (see §8), not the main draft.
  2. Drop the conventional prefix (feat(chat):, fix(chat):, feat(overlay):, fix(i18n):). Replace with prose.
  3. Drop branch-style phrasing. add prop to hide item name in path → Hide the item name segment in breadcrumb paths via a new prop. The PR title is the prompt, not the output.
  4. Use a — em-dash for the "why" clause, not a hyphen or colon — that's the consistent house style across 0.43.x–0.45.x.
  5. Backticks for code identifiers: env vars (THEMES_CONFIG_HOST, LIVE_CHAT_INTERACTION_ENABLED), feature-flag keys (features.asrEnabled), file paths, prop names, type names, overlay-API method names.
  6. Preserve issue + PR refs at the end in (Issue #<N>) (#<PR>) parenthesised form, or (#<PR>) when there is no issue. Don't strip them — these notes ship as the GitHub release body where the numbers auto-link.
  7. Prefix with [Preview] for preview-gated features.
  8. Flag regressions explicitly: (regression fix) for items restoring previously-working behavior.
  9. Quote CVE IDs verbatim for security upgrades: Upgrade axios to 1.7.9 to address CVE-2024-39338.
Example transformations

Each pair is raw CI → enhanced. Backticks in the enhanced form denote code identifiers in the actual output.

# Dropping `feat(chat):`, naming the concrete prop and surface:
- * feat(chat): add prop to hide item name in path (Issue #6210) (#6292)
+ * Hide the item name segment in breadcrumb paths via a new `hideItemNameInPath` prop on path-rendering components (Issue #6210) (#6292)

# Removing `fix(chat):` and naming the precise gap, marking regression:
- * fix(chat): fix quick app review flow when orchestrator does not support temperature (Issue #6637) (#6688)
+ * Fix Quick App review flow when the orchestrator deployment does not advertise `temperature` support (regression fix) (Issue #6637) (#6688)

# Folding two PRs that patched the same issue into one bullet:
- * fix(chat): publication request scrolling (Issue #4696) (#6135)
- * fix(chat): publication request scrolling follow-up (Issue #4696) (#6430)
+ * Fix scrolling inside the publication-request panel when the list overflows the viewport (Issue #4696) (#6135, #6430)

# Reverts whose original is in the same range — drop both:
- * feat(chat): introduce experimental thread-grouping (#6401)
- * Revert "feat(chat): introduce experimental thread-grouping" (#6488)
+ (drop both — net zero in the range)

# Revert whose original shipped earlier — keep, rephrase as roll-back:
- * Revert "feat(chat): aggressive prefetch of conversation history" (#6404)
+ * Roll back the aggressive prefetch of conversation history shipped in `0.44.0` — restores prior load-on-demand behavior (#6404)

# Dropping `feat(chat-e2e):` entirely (test-only):
- * feat(chat-e2e): updated tests with expand/collapse attachment feature (#6541)
+ (drop)

# Reclassified (raw had it in Other because of `feat(overlay):` prefix), prefixed [Overlay]:
- * feat(overlay): expose subscribeToEvents for prompt-selection (#6364)
+ * [Overlay] Expose `subscribeToEvents('promptSelected', …)` on `ChatOverlay` for embedders to react to in-chat prompt selection (#6364)

# Security bump → Fixes, phrased as user impact:
- * chore: bump axios to 1.7.9 (#6512)
+ * Upgrade `axios` to `1.7.9` to address CVE-2024-39338 (server-side request forgery in absolute-URL handling) (#6512)

# Theme-contract change → Other with [Theme] prefix:
- * chore(chat): bump dial-ui-kit to 0.20.0 (#6337)
+ * [Theme] Bump `@epam/ai-dial-shared` UI-kit to `0.20.0` — default button radii and disabled-state opacities shift; downstream themes overriding `--button-*` tokens may need a visual review (#6337)

# Folded orphan hotfix commits into a related fix entry:
- * publication URL escaping        (orphan commit, no PR)
- * fix tests                        (orphan commit, no PR)
+ * Escape `%` and `#` in publication URLs before they reach the router — fixes 404s on conversations with reserved characters in the title (`a1b2c3d`, `e4f5a6b`)
6. Build the Deployment Changes section

Add this section only when the range introduces at least one env-var, behavioral, or schema change. Pick subsections — include only the ones with entries:

markdown
## Deployment Changes

### New environment variables

<table: Variable | Default | Description>

### Deprecated environment variables

> [!CAUTION]
> Still works, but will be removed in future versions.
> <table: Variable | Replacement | Description>

### Removed environment variables

<table: Variable | Reason>

### New feature flags

<table: Flag | Description>

### Removed feature flags

<table: Flag | Reason / replacement>

### Behavioral changes

> [!NOTE]
> <one-line explaining the behavioral shift, e.g. preview→GA graduations>

- **<Feature>** — <field / module> (#<PR>)
Show full SKILL.md (1,060 more words)Show less
Which subsection: telling Behavioral and Schema deprecations apart

These two look adjacent but answer different operator questions:

  • Behavioral changes — "How does the deployed Chat app behave differently at runtime once I redeploy this image?" Default flag flips (e.g. a CONFIG_DEFINITIONS feature entry's defaultValue flipping to true), prefetch policy changes, default theme shifts, default model selection, error-handling shifts. Operator does nothing; the change is automatic on upgrade. Uses > [!NOTE].
  • Schema deprecations — "What keys in my settings JSON or overlay options payload are being renamed?" Inside-repo schema evolution where the parser still accepts legacy keys via aliases. Uses > [!CAUTION] and a table.

If a change requires the operator to touch a config file outside this repo (DIAL Core's aidial.config.json, helm values.yaml, an external IDP config, an ai-dial-chat-themes deployment), it belongs in DIAL Configuration changes with a concrete remove/add migration list, never in Behavioral changes.

Crucial — what does not belong here: per-conversation settings, per-app overlay options the embedder passes at runtime, in-chat user preferences. Those changes belong in the Features bullet body where they're introduced. Deployment Changes is for operator-facing concerns: env vars, default-on/off behavioral shifts, schema-level deprecations.

For the env-var tables, the description column comes from apps/chat-api/README.md when the row exists there; otherwise from the description field of the matching CONFIG_DEFINITIONS entry, or the surrounding code in environment.config.ts. Cite default values verbatim from the doc table's "Default" column or the defaultValue field in config-registry.constants.ts.

For the feature-flag tables, the entries are the CONFIG_DEFINITIONS entries with type: 'feature' added or removed in the range (from the §3 config-registry.constants.ts diff), backed by the FeatureKey enum in apps/chat-api/src/app-config/feature-flags/feature-key.enum.ts. The Flag column uses the registry entry's key in backticks (e.g. `features.asrEnabled`, `features.liveChatInteraction`), not a separate kebab-case name — consistent with the §5 rule #5 that backticks feature-flag keys. The description comes from the entry's description field; if the entry has an envVar (e.g. LIVE_CHAT_INTERACTION_ENABLED) or allowedRolesEnvVar, mention it since operators toggle the flag through that variable, not through a single combined flags env var.

7. Pre-release / delta handling

If the target is <X.Y.Z>-rc.N with N ≥ 1:

  • The release covers only what changed since the previous rc — do not consolidate or rewrite the predecessor's notes. Each pre-release tag has its own GitHub release page; the consolidation happens at the stable cut. (Note: ai-dial-chat rc trains can be very long — 0.45.0 shipped at rc.55 — so resist the urge to "summarise the whole train" on rc.N.)
  • Drop sections that have no entries in the delta (e.g. no Deployment Changes if no env vars or behavioral shifts landed in this rc).
  • Do not prepend a "Delta since <prev-rc>" pointer at the top. The CI doesn't emit one, the previously-shipped rc notes don't carry one, and the -rc.N version suffix already signals what the release is. Adding a header just creates editorial noise the user has to clean up.
8. Save the draft (and optional editorial companion)

Create claude/release-notes/ if missing, then write:

  • claude/release-notes/<tag>-draft.md — the final notes, ready to paste into the GitHub release body. No preamble, no commentary — just the headings and bullets.
  • claude/release-notes/<tag>-editorial-notes.md (optional) — only when there are non-obvious calls worth surfacing to the user:
    • Rename mapping (raw bullet → enhanced bullet) for items where the rewrite is non-trivial.
    • List of items dropped, with one-line reason per item.
    • Open questions for the user (e.g. "Should #6488 overlay-API addition stay under Other ? It's only useful to embedders.").
    • Any place the source-of-truth diverged from the PR body (e.g. canonical env-var name).
9. Verify nothing was pushed to GitHub

This skill never runs gh release edit, gh release create, or any write operation against the repo. The user explicitly directed: "Everything should be drafted in local files. Don't push anything or change anything in GitHub." Draft files are the only output. If the user later asks you to apply, that is a separate, explicit request.

Output format

The file saved to claude/release-notes/<tag>-draft.md follows this shape exactly:

markdown
## Features

- <one bullet per change>

## Fixes

- <one bullet per change>

## Other

- <only consumer-, embedder-, theme-, or maintainer-relevant items>

## Deployment Changes

### New environment variables

<table>

### Deprecated environment variables

> [!CAUTION]
> …

<table>

### New feature flags

<table>

### Removed feature flags

<table>

### Behavioral changes

> [!NOTE]
> …

- <item>

Section order: Features → Fixes → Other → Deployment Changes. Subsections inside Deployment Changes appear in the order: New env vars → Deprecated env vars → Removed env vars → New feature flags → Removed feature flags → Behavioral changes.

A delta rc release uses the same shape — no preamble paragraph, no header pointing at the previous rc.

Return to the main conversation

Return a short summary — five lines or fewer. Include:

  • The draft path (claude/release-notes/<tag>-draft.md).
  • Counts of bullets per section after enhancement.
  • Reclassifications that happened (e.g. "moved 2 from Other → Features, 1 from Other → Fixes, dropped 11 chat-e2e items").
  • Items dropped (count, with one example).
  • Whether a Deployment Changes section was added and which subsections.
  • Any open questions for the user (env-var name disagreement between the migration guide/README and environment.config.ts/config-registry.constants.ts, ambiguous [Overlay] vs Features categorization, config-registry type: 'config' vs 'feature' classification of a new entry).

Example:

Drafted claude/release-notes/0.45.0-rc.55-draft.md. 4 Features, 6 Fixes, 2 Other (both [Overlay]). Reclassified 1 from Other → Features (feat(overlay) exposing subscribeToEvents) and dropped 14 chat-e2e items, 1 Storybook bump, and a revert+original pair on #6401. Folded 2 PRs (#6135, #6430) into one bullet on Issue #4696. Added Deployment Changes with New env vars (THEMES_CONFIG_HOST default changed) + Behavioral changes (aggressive history prefetch rolled back). One open: README says NEXT_PUBLIC_USE_MD_SIDEBAR_OVERLAY_BREAKPOINT, code reads process.env.NEXT_PUBLIC_USE_MD_SIDEBAR_BREAKPOINT — used the code name; flagged in editorial notes.

Safety rails

  • Never edit GitHub. No gh release edit, no gh release create. Drafts only.
  • Never invent items. Every kept bullet maps to a PR or a commit hash in the range.
  • Never silently rename or drop a PR reference. The bullet ends with the canonical (Issue #<N>) (#<PR>) so links resolve on the release page.
  • Verify canonical names from source, not from PR bodies or docs. Past PR descriptions and doc tables have used pre-rename names; environment.config.ts / config-registry.constants.ts in apps/chat-api/src/** is the source of truth (the frontend does not read env vars directly).
  • Don't consolidate pre-release notes into the stable's notes unless the user explicitly asks — each rc tag has its own page.
  • Match the terseness of the predecessor's notes. If they're one-liners, your bullets are one-liners. The user has flagged verbose drafts twice; defer to the established style.

Maintenance

Conventions drift as the project grows. If you notice a pattern in the raw CI notes that this skill doesn't handle (a new section the CI emits, a new conventional-commit scope that misroutes items, a recurring rewrite the user keeps asking for), surface it in your return summary and offer to update this SKILL.md. The user can confirm before any edit lands.

© epam, 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

Just SKILL.md in .claude/skills/release-notes of epam/ai-dial-chat.

Open the folder on GitHubat commit 933c12c

Compare with similar skills

Chat 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.

Chat Release Notes compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Chat Release Notes this skillepam/ai-dial-chat504—~5.7kAutomated safety check: PassApache-2.0
Cutting A ReleaseTriliumNext/Trilium38k—~3.2kAutomated safety check: PassAGPL-3.0
Mole CLI Release Flowtw93/Mole69k—~2.5kAutomated safety check: PassGPL-3.0
Draft Release Notesjamiepine/voicebox57k—~941Automated safety check: PassMIT
Mole Release Notes Publishertw93/Mole69k—~1.9kAutomated safety check: PassGPL-3.0
Release Bumpjamiepine/voicebox57k—~1.1kAutomated safety check: PassMIT

Similar skills

  • Cutting A Release

    TriliumNext/Trilium

    A skill your agent uses when cutting, preparing, or debugging a Trilium release — bumping the monorepo version, tagging, or diagnosing a failed "Release" workflow run.

    38k GitHub stars~3.2k tokensUpdated today
    DevelopmentAuto-check passed
  • Runbook for assessing and executing a Mole CLI release: distribution channels, pre-flight checks, capital-V tags, build artifacts and the handoff to curated release notes.

    69k GitHub stars~2.5k tokensUpdated today
    DevelopmentAuto-check passed
  • Draft Release Notes

    jamiepine/voicebox

    Writes or refreshes the Unreleased section of CHANGELOG.md as a themed narrative built from the commits, PRs and diff since the last version tag.

    57k GitHub stars~941 tokensUpdated today
    DevelopmentAuto-check passed
  • Publishes curated, bilingual release notes for an existing Mole version tag with gh release edit, including contributor thanks and reactions, after the release workflow finishes.

    69k GitHub stars~1.9k tokensUpdated today
    DevelopmentAuto-check passed
  • Release Bump

    jamiepine/voicebox

    Ends a release cycle by moving the Unreleased changelog notes under a dated version heading, bumping version files with bumpversion and tagging the commit.

    57k GitHub stars~1.1k tokensUpdated today
    DevelopmentAuto-check passed
  • Cut Release

    jfernandez/bpftop

    Cut a new versioned release of bpftop — pick the version, open a version-bump PR, sign-tag the merge commit on main, and draft GitHub release notes in the project's established format.

    2.7k GitHub stars~2k tokensUpdated 1 mo ago
    DevelopmentAuto-check passed

More from epam/ai-dial-chat

All 18 skills in this repo
  • Refactoring Audit

    epam/ai-dial-chat

    Deep codebase refactoring audit for AI DIAL Chat. An agent skill from epam/ai-dial-chat.

    504 GitHub stars~4.3k tokensUpdated today
    Auto-check passed
  • Read unresolved GitHub code review threads for the pull request associated with the current branch, classify each comment, and implement and verify required code fixes.

    504 GitHub stars~1.7k tokensUpdated today
    Auto-check passed
  • Create Ticket

    epam/ai-dial-chat

    Interactively create OR update GitHub issues (Bug, Feature, Task) for the current repository.

    504 GitHub stars~4.6k tokensUpdated today
    Auto-check passed
  • Dep Scan

    epam/ai-dial-chat

    Runs Trivy filesystem scan against the repo root and emits structured vulnerability findings (CVE, package, versions) in the SDLC reviewer schema.

    504 GitHub stars~1.2k tokensUpdated today
    Auto-check passed
  • Figma

    epam/ai-dial-chat

    Design-to-code workflow for Figma designs. An agent skill from epam/ai-dial-chat.

    504 GitHub stars~997 tokensUpdated today
    Auto-check passed
  • Git Ship

    epam/ai-dial-chat

    A skill your agent uses whenever the user wants to commit, push, or ship changes in a git repository.

    504 GitHub stars~1.2k tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about Chat Release Notes

What does Chat Release Notes do?

A skill your agent uses when the user asks to enhance, refine, polish, or "look at" the release notes for a tag — typically a fresh CI-generated pre-release (e.g. Chat Release Notes is an agent skill from epam/ai-dial-chat.g.

When should I use Chat Release Notes?

Chat Release Notes fits situations like: the user asks to enhance; look at the release notes for a tag — typically a fresh CI-generated pre-release (e.g.

How do I install Chat Release Notes in Claude Code?

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

How do I install Chat Release Notes in Codex?

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

Can I use Chat 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 epam/ai-dial-chat --skill chat-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/chat-release-notes, .gemini/skills/chat-release-notes, .github/skills/chat-release-notes and .opencode/skills/chat-release-notes in your project.

What does Chat Release Notes need to run?

Going by SKILL.md and its folder, Chat Release Notes needs the command-line tools its instructions call (gh and git). Its frontmatter pre-approves these tools: Read, Grep, Glob, LSP, Bash(gh release view:*), Bash(gh release list:*), Bash(gh pr view:*), Bash(gh pr list:*), Bash(gh pr diff:*), Bash(git log:*), Bash(git show:*), Bash(git diff:*), Bash(git tag:*), Bash(git rev-parse:*), Bash(date:*), Write(claude/release-notes/*), Bash(mkdir -p claude/release-notes).

Does Chat Release Notes access the network?

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

Is Chat Release Notes safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Chat Release Notes use?

Chat 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 Chat Release Notes use?

About 5.7k tokens (SKILL.md is roughly 23k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Chat Release Notes?

Skills that share tags, products or a category with Chat Release Notes: Cutting A Release (TriliumNext/Trilium, 38k stars), Mole CLI Release Flow (tw93/Mole, 69k stars), Draft Release Notes (jamiepine/voicebox, 57k stars) and Mole Release Notes Publisher (tw93/Mole, 69k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Chat Release Notes?

epam (a GitHub organization) maintains it in epam/ai-dial-chat, which has 504 GitHub stars. The repository holds 18 skills in this directory. The repository was last updated on October 7, 2026.

Source: epam/ai-dial-chat on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.