# Commit Pr

> How to name branches, writing commit titles/messages and sending PRs with correct format Use when this capability is needed.

- Skill: `tomevault-io/commit-pr` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/commit-pr`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/commit-pr/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/commit-pr

---


## Branch names

- All git branches should start with `$USER/` (see `whoami` if $USER env var not set)

## Commit messages/titles

- Keep commit titles short if possible (like Linux kernel patches)

- Do not make commits with just title+bug number; add a short explanation that
  is a summary of the PR description.

- Use conventionalcommits style when possible and pragmatic in commit titles
  (you can sometimes omit the component name)

- Do not be super specific in commit messages, don't mention stuff like method
  names, variable names etc. Focus on why we did this commit and what problem
  we are solving.

- If the repository remote has `linkedin` in it, and there's no JIRA ticket
  available in the context, use AskUserQuestion tool if there's a JIRA ticket
  we can attach to the end of the commit message, on a separate like, using syntax:

      BUG=FOO-1234[,BAR-1234,...]

## PR title/description

Try to preserve commit titles as PR titles as much as possible

Organize PR description as follows (keep h2 titles):

```
## Summary

<explain the changes, mostly the git commit message>

BUG=[...] (if available, otherwise omit)

## Testing Done

<explain how we'll validate this change, or mention if we've added tests,
keep it brief. if we're relying on existing test execution in the CI pipeline,
just mention that>
```

## Confirmation step for commit/PRs

Before sending a PR show me the title/description you're using in a nice way
and let me approve or edit in a prompt.

## PR stacks

If the PRs are stacked, make sure each PR has a section like this that marks
the current PR.

```
## PR Stack

1. <link to PR>
2. this PR
```

and if a PR is not ready to review, make sure a PR stays in Draft, and it has
a description that begins like the following until the PR is ready:

```
> [!WARNING]
> This PR is part of a stack, please review [previous PRs](link to previous pr) first.
```

---
> Source: [ahmetb/dotfiles](https://github.com/ahmetb/dotfiles) — distributed by [TomeVault](https://tomevault.io).
<!-- tomevault:4.0:skill_md:2026-06-18 -->