writing-commit-messages
This Claude Code skill generates commit messages that adhere to the project's styling conventions, which require a subsystem prefix, imperative mood summary, optional issue references, and a concise prose description of changes. Use it when committing code changes to ensure consistency with the repository's contribution guidelines.
git clone --depth 1 https://github.com/ogulcancelik/herdr /tmp/writing-commit-messages && cp -r /tmp/writing-commit-messages/vendor/libghostty-vt/.agents/skills/writing-commit-messages ~/.claude/skills/writing-commit-messagesSKILL.md
# Writing Commit Messages Write commit messages that follow commit style guidelines for the project. ## Format ``` <subsystem>: <summary> <reference issues/PRs/etc.> <long form description> ``` ## Rules ### Subject line - **Subsystem prefix**: Use a short, lowercase identifier for the area of code changed (e.g., `terminal`, `vt`, `lib`, `config`, `font`). Determine this from the file paths in the diff. If changes span the macOS app, use `macos`. For GTK, use `gtk`. For build system, use `build`. Use nested subsystems with `/` when helpful and exclusive (e.g., `terminal/osc`). - **Summary**: Lowercase start (not capitalized), imperative mood, no trailing period. Keep it concise—ideally under 60 characters total for the whole subject line. ### References - If the change relates to a GitHub issue, PR, or discussion, list the relevant numbers on their own lines after the subject, separated by a blank line. E.g. `#1234` - If there are no references, omit this section entirely (no blank line). ### Long form description - Describe **what changed**, **what the previous behavior was**, and **how the new behavior works** at a high level. - Use plain prose, not bullet points. Wrap lines at ~72 characters. - Focus on the _why_ and _how_ rather than restating the diff. - Keep the tone direct and technical without no filler phrases. - Don't exceed a handful of paragraphs; less is more. ## Workflow - If `.jj` is present, use `jj` instead of `git` for all commands. - Run a diff to see what changes are present since the last commit. - Identify the subsystem from the changed file paths. - Identify any referenced issues/PRs from the diff context or branch name. - Draft the commit message following the format above. - Apply the commit - Don't push the commit; leave that to the user.
Audit herdr release readiness by comparing commits since the base release against next-release changelog and docs. Use when asked to run or apply the repo's pre-release audit, validate docs/next before release, inspect issue refs that release CI will close, or finalize release docs for herdr.
Triage open herdr GitHub issues into a concise decision-first Markdown table. Use when the user says "triage", asks to triage open issues, asks which issues need attention, or wants issue priority/recommendation lights for herdr.
Control herdr from inside it. Manage workspaces and tabs, split panes, spawn agents, read output, and wait for state changes — all via CLI commands that talk to the running herdr instance over a local unix socket. Use when running inside herdr (HERDR_ENV=1).