القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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.
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.
| name | commit-message |
| description | 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. |
| argument-hint | What changed, or which diff should be summarized? |
Use this skill when the goal is to produce a commit message that explains both what changed and why it matters.
Produce:
Inspect the intended commit scope. Decide whether to describe staged changes, unstaged changes, or a specific set of files. If the scope is unclear, first ask the user for clarification. If no response is provided, explicitly state the assumed scope as either staged changes, unstaged changes, or all files, and explain why this assumption was made.
Identify the core change. Reduce the diff to one primary action such as fixing a bug, adding behavior, refactoring an internal path, updating docs, or adjusting tests.
Separate what changed from why. Extract the concrete edits first, then identify the reason, regression, invariant, or user-facing effect. If the reason is not visible in the diff, say so instead of guessing.
Choose the message shape. Use a subject-only message for small self-explanatory changes. Add a body when the change affects behavior, touches multiple areas, has follow-up constraints, or needs context for reviewers.
Write the subject line.
Prefer the imperative mood. Keep it specific and compact. Target 50 characters or fewer when possible, and keep the subject at 72 characters or fewer.
Do not start the subject with a marker prefix such as fix:, feat:, or fix(scope):. Unless the user explicitly requests that convention, write a plain sentence-style subject (for example, Preserve redirection order in subshell execution).
Write the body if needed. Explain the motivation, notable implementation detail, and observable impact in short paragraphs or flat bullets. Mention tests only when they add meaning.
Validate against the diff.
Check that every claim is supported by the changes. Remove filler words, avoid generic verbs like "add", "fix", "update" or "improve", and make sure unrelated edits are not bundled into the description.
If the provided diff is incomplete or irrelevant, inform the user and request clarification or a valid diff.
Confirm the subject does not match marker patterns like ^[a-z]+(\([^\)]*\))?!?:.
Wrap the message.
Always use an external tool like fmt -w 72 or par w72 to wrap lines at 72 characters. If and only if no such tool is available, wrap lines manually at 72 characters.
type: or type(scope):.Unless the user asks for a different convention, always present the primary suggested commit message in a fenced text code block so it can be pasted directly into a commit editor.
Use this structure:
<subject>
<optional body>
Keep the subject concise and under 72 characters. Wrap body lines at 72 characters.
If useful, also provide 2 to 3 alternative subject lines with different emphasis, such as user-visible behavior, subsystem, or bug fix framing. The alternatives can be outside the code block.