Use when a change may need a .changes note, the Release note gate fails, or deciding whether type: internal or no-release-note applies.
61
72%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Fix and improve this skill with Tessl
tessl review fix ./.claude/skills/release-notes/SKILL.mdEvery user-visible change gets one direct .changes/<area>-<slug>.md file. The
area matches the conventional-commit scope; the body is present tense, user
language, one to three sentences, and at most 400 characters.
---
type: fix
area: stalker
issues: [1234]
screenshot: optional-manifest-slug
---
Stalker series now resume the correct episode.type is breaking, feature, fix, perf, or internal. Omit optional
fields instead of inventing values. Never add a version or PR number.
internal records invisible maintenance. It stays collapsed in CHANGELOG.md
but is omitted from the blog and the authored public GitHub body. GitHub's
generated commit list may still mention the underlying commits.
The gate auto-exempts website, E2E and mock-server apps, *.spec.{js,ts},
*.e2e.{js,ts}, snapshots, any /testing/ path, and Markdown. Other test-only,
docs, CI, workflow, or pure-refactor PRs use no-release-note when the gate
would otherwise require a note. At least one newly added direct
.changes/*.md file satisfies the gate.
pnpm run release:notes:validateFull format: .changes/README.md. Gate policy:
tools/release/check-release-note-gate.mjs.
The .codex and .claude copies of this skill must remain byte-identical.
069b8b3
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.