القائمة
Update crate CHANGELOG.md files in yash-rs. Use for adding unreleased entries, deciding changelog categories, and keeping changelogs aligned with crate and workspace version changes.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Apply the yash-rs versioning rules: bump affected crate versions, sync the root Cargo.toml, and add Unreleased changelog headings, per the PR template. Documentation updates are out of scope (see the update-docs skill).
Update the mdBook user documentation under docs/src in yash-rs. Use when a behavior or feature change needs corresponding documentation edits, or when adding, revising, or correcting existing documentation pages.
Draft informative commit messages from repository changes. Use when writing a git commit message, summarizing staged edits, or turning a diff into a clear subject and body.
استنادا إلى تصنيف SOC المهني
| name | update-changelog |
| description | Update crate CHANGELOG.md files in yash-rs. Use for adding unreleased entries, deciding changelog categories, and keeping changelogs aligned with crate and workspace version changes. |
| argument-hint | Which crate(s) changed and what behavior changed? |
Use this skill to update changelog entries for one or more crates in this workspace.
CHANGELOG.md entryProduce changelog updates that:
[x.y.z] - Unreleased section for each affected crateCargo.tomlIdentify affected crates. Use the diff to find which crates changed. Treat each crate independently.
Confirm target version for each crate.
Read <crate>/Cargo.toml and capture the current forecast version.
Do not bump versions again if already bumped for unreleased work.
If the version does not look like the next semver release for the current changes,
stop and ask the user how to resolve the mismatch before editing changelogs.
Open <crate>/CHANGELOG.md.
Find an existing [x.y.z] - Unreleased section matching the crate version.
If missing, create it near the top using repository conventions.
When creating a new unreleased section, also add a link definition near the end of
the changelog that points to the corresponding release page.
Classify each change. Map each change to exactly one primary category:
Write concise, user-meaningful bullets.
State what changed and why it matters. Avoid internal-only jargon unless the crate is developer-facing.
For yash-cli/CHANGELOG.md, keep entries focused on user-visible behavior and
avoid implementation details aimed at crate developers.
Order bullets by importance first, then by relatedness within a category.
Represent net release state, not commit history. Before adding a new bullet, scan the existing Unreleased section for bullets that cover the same feature or area. If a prior bullet already describes behavior that the current change replaces or refines, update or replace that bullet to reflect the final outcome. The Unreleased section must read as if describing the next release in full, not as a running log of intermediate commits. For example, if "feature A was added" is already in Unreleased and the current change renames A to B, replace the bullet with "Added B" rather than appending "Renamed A to B".
Handle cross-crate behavior.
If shell-observable behavior changed, also update yash-cli/CHANGELOG.md even when implementation lives in another crate.
Keep scope clean. Only add entries for changes in the current work. Do not rewrite historical sections.
Validate consistency. Ensure each edited changelog version matches the corresponding crate version and wording is factual.
If change is not user-visible but affects crate users (library API or semantics): add an entry to that crate changelog.
If change is observable in shell behavior:
add or update entry in yash-cli/CHANGELOG.md.
If Cargo.toml version does not appear semver-appropriate for the pending changes:
ask the user whether to adjust the version, scope, or changelog framing.
If the current change modifies behavior already documented in the Unreleased section (i.e., something added or changed since the last release): update or replace the existing bullet to describe the final outcome. Do not append a second bullet that contradicts or supersedes an earlier one.
If a change could fit multiple categories: choose the category users will search first, then keep the bullet focused.
If no relevant changelog section exists for the target unreleased version:
create [x.y.z] - Unreleased before adding bullets.
yash-cli/CHANGELOG.md, bullets stay user-facing and avoid deep internal details.yash-cli changelog is updated when user-visible shell behavior changed.When reporting back to the user: