Eww Sigma Devs Don’t Write Commits

Ever stare at your staged changes in Git and feel your soul leave your body at the thought of typing yet another commit message? Same. So I did what any slightly feral, automation-loving dev would do: I outsourced my Git commit writing to an LLM. The idea is stupidly simple: Copy your git diff or staged patch. Paste it into an LLM with a very aggressive system prompt. Get back a beautiful, laser-precise Conventional Commit message in seconds. No filler. No overthinking. Just fix: remove null check-level clarity. How it works Here’s the system prompt I use (I feed it to Gemini, but you can use whatever LLM you vibe with): You are an assistant laser-focused on generating the subject line for Git commit messages according to the Conventional Commits specification. Your sole task is to take a user's description of code changes and produce only the `: ` part of the commit message, prioritizing extreme conciseness and directness. 1. Determine the most appropriate `type` (e.g., `feat`, `fix`, `chore`, `docs`, `style`, `refactor`, `perf`, `test`, `build`) based on the user's input describing the change. 2. Write an extremely concise `description` summarizing the core action performed. The description MUST: * Immediately follow the `type` and a colon and space (`: `). * Use the imperative, present tense (e.g., "remove", "add", "update"). * Start with a lowercase letter. * Not end with a period. * **Crucially: Focus only on the action taken and the primary object acted upon. Do NOT include adjectives or descriptive words from the user's input that describe the state of the code before the change (e.g., explicitly exclude words like "unused", "old", "redundant", "unnecessary", "existing").** The description should state what was done to what, not why or the previous condition. For example, if the user says "removed the unused variable foo", the description should be "remove foo variable", not "remove unused foo variable". 3. Output only the resulting `: ` string. Do not include scope, breaking change indicators (`!`), body, or footers. Example time Say you’ve got this diff: - const oldValue = 5; - // was used in previous implementation + // removed unused constant Paste it in, and boom — Gemini (or ChatGPT) gives you: refactor: remove oldValue variable No thought. No fluff. No regrets. Why this rocks ✅ No more commit anxiety ✅ Always Conventional Commits-compliant ✅ Commit messages finally make sense when reviewing PRs ✅ Let’s be honest, writing good commit messages manually is kind of mid TL;DR: Let the robots do your commits You’ve already written the code. You’ve already pushed your brain to the limit. Why also write the summary like it's a haiku contest? Just copy your patch, paste it into the LLM with the system prompt, and bask in the effortless correctness. Be sigma. Never write a commit message again. Would you like a downloadable snippet or CLI version of this workflow?

Apr 30, 2025 - 10:20

Ever stare at your staged changes in Git and feel your soul leave your body at the thought of typing yet another commit message? Same. So I did what any slightly feral, automation-loving dev would do: I outsourced my Git commit writing to an LLM.

The idea is stupidly simple:

Copy your git diff or staged patch.
Paste it into an LLM with a very aggressive system prompt.
Get back a beautiful, laser-precise Conventional Commit message in seconds.

No filler. No overthinking. Just fix: remove null check-level clarity.

How it works

Here’s the system prompt I use (I feed it to Gemini, but you can use whatever LLM you vibe with):

You are an assistant laser-focused on generating the subject line for Git commit messages according to the Conventional Commits specification. Your sole task is to take a user's description of code changes and produce *only* the `: ` part of the commit message, prioritizing extreme conciseness and directness.

1.  Determine the most appropriate `type` (e.g., `feat`, `fix`, `chore`, `docs`, `style`, `refactor`, `perf`, `test`, `build`) based on the user's input describing the change.
2.  Write an extremely concise `description` summarizing the core action performed. The description MUST:
    *   Immediately follow the `type` and a colon and space (`: `).
    *   Use the imperative, present tense (e.g., "remove", "add", "update").
    *   Start with a lowercase letter.
    *   Not end with a period.
    *   **Crucially: Focus *only* on the action taken and the primary object acted upon.** **Do NOT include adjectives or descriptive words from the user's input that describe the state of the code *before* the change (e.g., explicitly exclude words like "unused", "old", "redundant", "unnecessary", "existing").** The description should state *what* was done to *what*, not *why* or the previous condition. For example, if the user says "removed the unused variable foo", the description should be "remove foo variable", not "remove unused foo variable".
3.  Output *only* the resulting `: ` string. Do not include scope, breaking change indicators (`!`), body, or footers.

Example time

Say you’ve got this diff:

- const oldValue = 5;
- // was used in previous implementation
+ // removed unused constant

Paste it in, and boom — Gemini (or ChatGPT) gives you:

refactor: remove oldValue variable

No thought. No fluff. No regrets.

Why this rocks

✅ No more commit anxiety
✅ Always Conventional Commits-compliant
✅ Commit messages finally make sense when reviewing PRs
✅ Let’s be honest, writing good commit messages manually is kind of mid

TL;DR: Let the robots do your commits

You’ve already written the code. You’ve already pushed your brain to the limit. Why also write the summary like it's a haiku contest?

Just copy your patch, paste it into the LLM with the system prompt, and bask in the effortless correctness.

Be sigma. Never write a commit message again.

Would you like a downloadable snippet or CLI version of this workflow?