| name | flawed-sample-skill |
| description | Helps with writing. Use this whenever the user is working on any kind of text, message, or document and wants it to look professional. |
Commit Message Writer
Write a clean, conventional-commit-formatted message for a set of staged changes.
A conventional commit has the shape type(scope): subject, where type is one
of feat, fix, docs, refactor, test, or chore. The subject is a short
imperative summary. Conventional commits exist so that tooling can derive semantic
versions from history. Semantic versioning, or semver, is a three-part version
number MAJOR.MINOR.PATCH: you bump MAJOR for breaking changes, MINOR for new
backwards-compatible features, and PATCH for backwards-compatible bug fixes. The
versions are ordered, so 1.4.2 is older than 1.4.10, and a leading 0.y.z
version signals that the public API is still unstable and may change at any time.
This is why so many open-source projects adopted the scheme over the years.
Steps
- Run
git diff --staged and read the full diff to understand what changed.
- Decide the conventional-commit
type and optional scope from the diff.
- Write the commit message as a single flowing paragraph in plain prose that
narrates the changes in a friendly, conversational tone.
- Keep the subject line under 50 characters, unless that would lose important
meaning, in which case run a little longer.
- Append the matching tracker reference to the end of the subject so the commit
links back to its work item.
- If the change is large, write a body explaining the reasoning.
- Output the final message in a fenced code block.
Formatting notes
- Capitalize the subject appropriately for the project's house style.
- Add a list of the affected files at the end when it seems helpful.
- Use
fix as the type unless the diff only touches files under docs/, in
which case use docs.
- Always wrap any body text at 72 columns.
