write-conventional-commit
Write Conventional Commit
Inspect Git changes and return exactly one final commit message.
Workflow
- Run
git status --short. - If there are no staged or unstaged changes, reply exactly:
No staged or unstaged changes found. - Run
git diff --staged --no-ext-diff --stat. - Run
git diff --staged --no-ext-diff. - If the staged diff is empty but the working tree is dirty, use
git diff --no-ext-diff --statandgit diff --no-ext-diffas a fallback. - Infer the dominant intent from the diff and write one message only.
- Return exactly one final commit message and nothing else.
Commit Types
Use exactly one type from this list:
- feat: a new feature
- fix: a bug fix
- docs: documentation only changes
- style: changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- refactor: a code change that neither fixes a bug nor adds a feature
- perf: a code change that improves performance
- test: adding missing tests or correcting existing tests
- build: changes that affect the build system or external dependencies
- ci: changes to our CI configuration files and scripts
- chore: other changes that don't modify src or test files
Conventional Commit rules
- Choose the dominant intent. DO NOT combine types.
- DO NOT end the subject with a period.
- If the change is breaking, mark it with
!after the type or scope and include aBREAKING CHANGE:footer when additional migration detail is needed. - Keep the subject concise; aim for 50-72 characters.
- Never include markdown fences, bullets, analysis, or commentary.
- Prefer a longer commit body after the short description, providing additional contextual information about the code changes.
- Prefer lower-case after the colon unless a proper noun or acronym requires capitalization.
- Preserve useful trailer/footer information from the context when it is clearly present.
- Use an optional scope only when it is obvious and genuinely helpful.
- Write the subject in imperative mood.
More from liblaf/skills
write-root-readme
Write or rewrite the repo-root README.md.
36write-python-tests
Write or refresh tests for Python projects. Use when Codex needs to add coverage, replace stale tests, reorganize tests under `tests/`, or lock down Python behavior from source code in repos that use `nox`, `pytest`, and `mise`.
34rewrite-python-docs
Rewrite Python docs and docstrings from source code. Use when Codex needs to refresh the docs.
34sync-github-repo-metadata
Inspect a repository and propose or apply GitHub About metadata updates. Use when Codex needs to infer a concise repository description and topic set from source code, package metadata, docs config, or the current README, then preview and optionally run `gh repo edit`.
33automate-project-maintenance
Orchestrate repository maintenance. Use when Codex needs one entry point to refresh tests, docs, README, and GitHub metadata.
33