# Release Notes

> Use this skill when the user asks to "generate release notes", "write release notes", or "what changed" for a new version of this package.

- Skill: `tomevault-io/release-notes-15` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/release-notes-15`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/release-notes-15/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/release-notes-15

---


# Generate Release Notes: eslint-plugin-chai-friendly

Generates release notes for a new version, consistent with the repo's established style.

## Style Guide

Releases use a flat bullet list — no section headers like "Features" or "Bug Fixes". Each bullet is one concise sentence describing a user-visible change. Internal refactors, test additions, and doc updates are omitted unless they affect users directly.

Past releases for reference:
- "Added support for optional chaining"
- "Added `enforceForJSX` option"
- "Fixed TypeScript typing issue for `configs.recommendedFlat` and `configs.recommended`"
- "Added ESLint v9 compatibility"

## Process

### Step 1 — Determine the version range

Read `package.json` to get the current version. The release notes cover everything since that version was tagged. If the user specifies a version (e.g. "1.2.0"), use that as the new version number.

### Step 2 — Collect commits since the last release tag

Run:
```bash
git log $(git describe --tags --abbrev=0)..HEAD --oneline
```

If no tag exists yet for the previous version, ask the user which commit or tag to diff from.

### Step 3 — Read changed files

For each commit, identify what changed. Focus on:
- `lib/rules/no-unused-expressions.js` — rule behavior changes
- `lib/index.js` — plugin config changes
- `index.d.ts` / type files — TypeScript definition changes
- `package.json` — dependency or engine changes

Read the relevant files to understand the user-visible impact of each change. Do not rely solely on commit messages.

### Step 4 — Fetch existing release titles from GitHub

Fetch `https://github.com/ihordiachenko/eslint-plugin-chai-friendly/releases` and note the existing release titles/styles for consistency.

### Step 5 — Draft release notes

Output as raw markdown (do not wrap the result in a code block). Use this format:

Changes:

- {change 1}
- {change 2}
- {change 3}

Rules:
- Do not include a version header.
- Use the plain text `Changes:` as the list title (not a markdown heading).
- Lead each bullet with a verb: "Added", "Fixed", "Improved", "Removed"
- Mention option names in backticks (e.g. `ignoreDirectives`)
- Mention node type names in backticks (e.g. `TSAsExpression`)
- For bug fixes, briefly describe the incorrect behavior that was fixed
- Omit internal changes (refactors, test additions, CI, docs) unless they have a user-visible effect
- Keep the total list to 5 bullets or fewer; combine related changes into one bullet if needed

---
> Source: [ihordiachenko/eslint-plugin-chai-friendly](https://github.com/ihordiachenko/eslint-plugin-chai-friendly) — distributed by [TomeVault](https://tomevault.io).
<!-- tomevault:4.0:skill_md:2026-06-21 -->