Skip to content
Recipes Ecosystem Source Code Docs

Write Consistent Commit Messages

A clean commit history makes code review, bisecting, and changelog generation dramatically easier. OpenCode reads your staged diff and produces messages that follow your team’s conventions.

When to use this recipe

  • You finished a feature and have a pile of unrelated changes staged together.
  • The team has a commit-message convention that’s tedious to follow by hand.
  • You want a clean history you can bisect or revert later.

Prerequisites

  • OpenCode installed in the repo.
  • A .gitmessage template or team convention (Conventional Commits, custom prefixes, etc.).
  • Changes ready in the working tree.

Steps

  1. Review what’s staged

    Confirm the staging area reflects what you intend to commit.

    git status
git diff --cached --stat

  2. Ask for a message suggestion

    Pass the diff to OpenCode and ask for a Conventional Commit message.

    Read my staged diff and suggest a Conventional Commit message. Use the format type(scope): subject. The subject should be imperative mood, under 72 characters. The body should explain why, not what.

  3. Unstage and regroup if needed

    If the diff contains multiple unrelated concerns, ask OpenCode to split it into logical commits.

    This diff mixes a bug fix with a refactor. Suggest how to split it into two commits. Tell me which files belong in which commit, and write a message for each.

  4. Commit each group

    Stage and commit each group separately, using OpenCode’s suggested message.

    git reset HEAD
git add <files-for-first-commit>
git commit -m "fix(parser): handle empty input without panic

Previously an empty input caused a nil deref in the lexer.
Added an early return and a unit test."

  5. Verify the history reads well

    Look at the last few commits to confirm they tell a coherent story.

    git log --oneline -10

Key prompt

Read my staged diff and propose a Conventional Commit message. Then look at it and tell me if it contains multiple unrelated concerns that should be split into separate commits. If yes, list which files belong in each commit and write a message for each.

Verify

  • git log --oneline reads as a clean narrative.
  • Each commit builds and tests independently.
  • Messages follow the team’s convention (e.g. type(scope): subject).

Common pitfalls

  • Mixing concerns: A “fix typo + new feature + reformat” commit is impossible to revert safely. Always regroup first.
  • Vague subjects: “fix stuff” or “update code” tell future-you nothing. Always require a concrete subject.
  • Forgetting body context: The why is rarely obvious from the diff. Make OpenCode write a 1-2 line body.

Next up