A commit message after a small agent session
A coding agent has finished a small change. The tests pass, you have reviewed the files, and Git is waiting for a commit message. It is tempting to ask the agent to “write something suitable” and accept the first sentence. A little more direction usually produces a message that will still make sense when you return to the project later.
A commit records a snapshot of your project in Git. Its message explains the purpose of that snapshot. An agent can draft that explanation from the changes, but you still need to check that it describes the work accurately.
§ Start with the changes you intend to save
Before asking for a message, decide which changes belong in the commit. A folder might contain a finished bug fix, an unfinished experiment, and a formatting change. Those do not necessarily belong together.
Git calls the changes selected for the next commit staged changes. Run git status to see which files are staged, then git diff --cached to inspect the staged difference. For a first commit containing entirely new files, that difference will show the added content.
Ask the agent to work from that staged difference. Otherwise, it may describe edits elsewhere in your working folder that the commit will not contain. This matters particularly after a long session with several attempts at the same problem.
§ Give the agent a small, explicit request
You do not need a complicated prompt. Give the agent a source to inspect, a style to follow, and a boundary around its actions. For example:
“Read the staged changes and draft a Git commit message. Use a short subject line beginning with an action verb. Add a brief body only if the reason for the change needs explanation. Describe only what the staged changes support. Do not stage files or create the commit.”
If your repository has a documented message format, ask the agent to follow it. Some teams use prefixes such as fix: or feat:. These are conventions used by people and automation; Git itself does not require them. For a personal project, a clear sentence is a reasonable starting point.
The agent may also need context that the code cannot reveal. If you changed a timeout because a particular upstream service routinely takes longer to respond, say so. Ask it to leave out any reason it cannot establish from your explanation or the available evidence.
§ Read the draft against the actual change
Suppose your change prevents an empty search box from sending a request. “Improve search functionality” is too broad to be useful. “Skip search requests for empty queries” names the behavior directly.
Check the draft with three questions:
- Does the subject describe the main change in this commit?
- Does every factual claim match the staged code or context you supplied?
- Would someone understand the message without reading the agent conversation?
Watch for claims about testing. An agent might write “verify all search cases” when it only added one test, or say tests passed without having run them. A commit message should not imply broader verification than actually happened.
If the draft needs several unrelated sentences to explain the work, inspect the commit’s scope again. You may have several changes that would be easier to review separately.
§ Keep the drafting step easy to repeat
You can use this workflow in coding tools such as Claude Code or Codex. Vana API works with both, providing access through one endpoint with usage billed per real token and no monthly fee. The drafting habit stays the same: select the changes, request a message, and review the result. If you want to try it with your coding tool, create a Vana API account.
Once the wording is accurate, create the commit yourself or explicitly ask the agent to do so. If you edit the staged changes afterward, check the message again before committing. Even a good draft can become inaccurate when the code changes underneath it.