git clone --depth 1 https://github.com/herdrdev/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.
Create and control a disposable named Herdr session from inside an existing Herdr session. Use for isolated Herdr runtime, pane, terminal, process, API, persistence, or agent reproductions that should be driven through the CLI/API without touching the default session.
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, a terminal multiplexer for coding agents. Use only when the user explicitly mentions Herdr or asks to use Herdr to inspect or control panes, tabs, workspaces, commands, or another agent. Do not use merely because a task could benefit from a background terminal, delegation, or parallel work. Requires HERDR_ENV=1.