메뉴
Create or fix Tempo changelog entries with .chloggen. Use when a PR needs a changelog, CHANGELOG.md was edited directly, or the user asks to add/update/amend release notes.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | changelog-entry |
| description | Create or fix Tempo changelog entries with .chloggen. Use when a PR needs a changelog, CHANGELOG.md was edited directly, or the user asks to add/update/amend release notes. |
| allowed-tools | Bash Read Grep Edit |
Use this skill when adding, replacing, or fixing a Tempo changelog entry for a PR.
Do not edit CHANGELOG.md directly for unreleased PR changes. Tempo manages CHANGELOG.md with .chloggen; every PR adds a small YAML file under .chloggen/ instead.
Always read .chloggen/README.md before making changes if you have not already read it in the current session.
Before editing, inspect the current state:
git status --short --branch
git diff --name-status
If there are unrelated user changes, leave them untouched. If they directly conflict with the changelog work, ask the user how to proceed.
Collect or infer:
change_type: one of breaking, change, feature, enhancement, bug_fix, securitycomponent: must be listed in .chloggen/config.yamlnote: short user-facing description without the component prefixissues: PR number(s), for example [7288]; leave as [] only when auto-fill at release is appropriateuser: GitHub handle without @subtext: optional extra detail; leave blank when not neededUse the change itself, PR metadata, or the old CHANGELOG.md line to infer these fields. Ask one short question only if the required fields cannot be inferred safely.
Prefer the repo helper:
make chlog-new
If the current branch name is not suitable, or if on main, master, or a detached HEAD, pass an explicit filename:
make chlog-new FILENAME=<short-change-name>
Then fill the generated file. Minimal example:
change_type: bug_fix
component: distributor
note: bound per-trace slice preallocation during rebatching.
issues: [7288]
subtext:
user: carles-grafana
Keep note concise. The rendered changelog prefixes the component, so write note: bound ..., not note: distributor: bound ....
If the branch edited CHANGELOG.md directly for an unreleased entry, remove that direct edit and keep the .chloggen/*.yaml entry instead.
Do not discard unrelated CHANGELOG.md changes unless they are clearly generated unreleased entries being replaced by .chloggen files. Inspect the diff first:
git diff -- CHANGELOG.md
For branches where CHANGELOG.md should match the base branch, restore only that file from the base after confirming the diff is only unreleased changelog content:
git restore --source origin/main -- CHANGELOG.md
Always validate the entry:
make chlog-validate
If useful, preview the rendered output:
make chlog-preview
chlog-preview can fail when issues: [] and the PR number cannot be inferred yet. In that case, either set issues explicitly or report the limitation.
Before committing or amending, inspect the staged and unstaged changes:
git status --short --branch
git diff --stat
git diff -- .chloggen CHANGELOG.md
git log --oneline -10
Stage only the intended files:
git add .chloggen/<entry>.yaml
git add CHANGELOG.md # only if removing a direct changelog edit
If the user asked to amend the PR commit:
git diff --cached --check
git commit --amend --no-edit
If the user asked for a new commit, use a concise message such as:
git commit -m "chore: add changelog entry"
Never push unless the user explicitly asks.
Report:
.chloggen file created or updatedCHANGELOG.md direct edits were removedAssess documentation status for PRs — classify gaps, identify existing docs that need updating, and flag UI changes that may affect screenshots. Use when the user asks to check docs coverage for PRs, triage documentation needs, audit PRs for missing docs, assess whether a set of changes needs documentation, or check what recently merged PRs need docs.
Write or update product documentation for user-facing PR changes. Use when the user asks to write docs for a PR, document a PR, update existing docs based on a code change, process PRs flagged by docs-pr-check, or provides PR numbers or links and wants the corresponding documentation created or updated — even if they say "document these changes" without mentioning PRs explicitly. This skill writes and updates docs only; it does not triage PRs (use docs-pr-check), review existing docs (use docs-review), or generate release notes.
Review documentation changes for style, accuracy, and completeness. Use when docs have been written or updated and need a quality check before submission, when the user asks to review docs, proofread, check style compliance, or verify technical accuracy of documentation.
End-to-end workflow for PR documentation — check, write, review, and optionally validate screenshots. Use when the user wants to document one or more PRs from start to finish, run the full docs pipeline, or asks for a complete documentation pass on PRs.
Use this skill to assess whether documentation content fits its intended audience. Identifies the target persona (Learner, Practitioner, Expert, Operator), use case, and entry state, then flags mismatches between the content and what that audience needs. Use when the user asks to check persona fit, review audience alignment, asks "who is this page for?", questions whether content is at the right level of detail, or mentions /persona-check. Also use when reviewing a PR where content seems too advanced, too basic, or aimed at the wrong reader. This is not for style guide, grammar, or link checking — use docs-review for those.
Resolve vendor/ conflicts during a merge, rebase, or dependency upgrade on main or release branches