Prompts

[Blarc]

Share your custom prompts that you use to generate your commit messages.

Title: Donald Trump
Description: Prompt that generates commit messages in Donald Trump style.
Content:

Write an insightful but concise Git commit message in Donald Trump style in present tense for
the following diff without prefacing it with anything, the response must be in the language {locale}
and must not be longer than 74 characters. The sent text will be the differences between files,
where deleted lines are prefixed with a single minus sign and added lines are prefixed with a 
single plus sign.
{diff}

[Abukamel]

Title: Enhanced-Conventional
Description: Enhanced Conventional Style Commit Message
Content:

Write a meaningful commit message in the conventional commit convention by trying to understand what was the benefits the code author wanted to add by his changes to codebase with this commit. I'll send you an output of 'git diff --staged' command, and you convert it into a commit message. Lines must not be longer than 74 characters. Use {locale} language to answer. End commit title with issue number if you can get it from the branch name: {branch} in parenthesis.
{diff}

[delmicio]

Title: Enhanced-Conventional-LN
Description: Enhanced Conventional Style Commit Message with line breaks
Content:

Write a meaningful commit message in the conventional commit convention by trying to understand what was the benefits the code author wanted to add by his changes to codebase with this commit. I'll send you an output of 'git diff --staged' command, and you convert it into a commit message. Lines must not be longer than 74 characters. Use {locale} language to answer. End commit title with issue number if you can get it from the branch name: {branch} in parenthesis. Try to use line breaks, only after a dot, to help making the commit message easier to read.
{diff}

[tadamcz]

To write better prompts, it would help to be able to see the values of the variables, especially {diff}

[Blarc]

This is something I've been working on lately:

One question that comes up regarding the preview is which changes to use? For generating a commit message I use the changes the user picks in the commit dialog. The current implementation gets all changes, computes prompt and shows only the first 2000 characters as the preview.

[renatoaraujoc]

Hey, this is my prompt, been working pretty well!

Write a meaningful commit message in the Angular Conventional Commit Convention by summing up, thus being specific, to what changed. If you can figure out the benefits of the code, you may add add this to the commit body. I'll send you an output of 'git diff --staged' command, and you convert it into a commit message. Lines must not be longer than 74 characters. Use {locale} language to answer. End commit title with issue number if only and only if you can get it from the branch name: {branch} in parenthesis, else don't do this. Do not use any emojis!

Your commit message should follow the following style, example: 

refactor(api): a description here

An optional body text here

An optional footer text here

The commit description (which comes right after the "type(scope):" must not be sentence-case, start-case, pascal-case, upper-case [subject-case] and not end with a period (.) and must not be over 74 characters in length.

"refactor" is the type, I'll list all possible types.
"api" is the scope, I'll list all possible scopes.

Possible scopes:
- api (code related to app api)
- ng-admin (code related to app fe-admin)
- workspace (in case any workspace code was modified and you can't infer the app, you can use workspace scope)

Possible types:
- fix, use this if you think the code fixed something
- feat, use this if you think the code creates a new feature
- perf, use this if you think the code makes performance improvements
- docs, use this if you think the code does anything related to documentation
- refactor, use this if you think that the change is simple a refactor but the functionality is the same
- test, use this if this change is related to testing code (.spec, .test, etc)
- chore, use this for code related to maintenance tasks, build processes, or other non-user-facing changes. It typically includes tasks that don't directly impact the functionality but are necessary for the project's development and maintenance.
- ci, use this if this change is for CI related stuff
- revert, use this if im reverting something

This is the diff:
{diff}

[ioanlucut]

This is useful but I think it's consuming too many tokens for a single invocation.

[117]

Given the diff below, create a concise commit message following the Conventional Commits format (e.g., fix: correct minor typos in code). The primary change description should be prioritized. Avoid verbosity:

{diff}

[117]

This has been working well for me. Based on https://www.conventionalcommits.org/en/v1.0.0/#summary.

[117]

GPT 4 seems to be aware of the specifications.

[insign]

Cool. I made some changes, but also I recommend you give it a name.

Given the diff below, create a concise commit message (always in {locale}) following the Conventional Commits format (e.g., fix: correct minor typos in code). The primary change description should be prioritized. Avoid verbosity, do not add codeblock backticks:

{diff}

The do not add codeblock backticks is more for the Gemini 2 Thinking which insists in put codeblocks in almost everything code related.

[sudoskys]

Title: Format Task
Description: Generates commit messages by given format
Content:

Task:
Write a clean and comprehensive github commit message in the conventional commit convention.I'll send you an output of 'git diff --staged' command, and you convert it into a commit message.Lines must not be longer than 74 characters.Use {locale} language to answer.
Do NOT add any descriptions to the commit, only commit message. NO Co-authored.
Raw:
{diff}
CommitMessageFormat: 
   :emoji: <type>[optional scope]: <description>
   [optional body(s)]
   [optional footer(s)]
TaskResult:

[ioanlucut]

I am wondering what would be the most concise way to ask ChatGPT since each char/space is considered a token.

[ljgonzalez1]

tl;dr: Managed to reduce the cost of mine by ~90% by going from an absurdly large prompt to a tiny one with somewhat similar results.

---

---

Mine can be summed up from 11194 characters to as little as 253 characters. In my case, most characters are used in examples and definitions rather than instructions.

Write a concise commit message from 'git diff --staged' output in the format `[EMOJI] [TYPE](file/topic): [description in {locale}]`. Use GitMoji emojis (e.g., ✨ → feat), present tense, active voice, max 120 characters per line, no code blocks.
---
{diff}

If you want to save money, it works good enough though it tends to use always about the same 5 emojis (✨, ♻️, 🚚, 🐛, ✏️) instead of the complete suite. That was the reason I added the huge table of emojis.

---

Now, if you want to take it to the extreme, you can use this one, with 163 characters

Write concise commit message from 'git diff --staged' in format `[EMOJI] [TYPE](topic): description in {locale}`. Use GitMoji, present tense, max 120 chars.

{diff}

---

The last one still does the job with GPT4o-mini. It costs on average ¢37,5/1M tokens, which means I reduced the cost from ¢0,105 to ¢0,0105 with the example provided below (was not expecting this much...).
You can count using this site.

INPUT:

Write concise commit message from 'git diff --staged' in format `[EMOJI] [TYPE](topic): description in english`. Use GitMoji, present tense, max 120 chars.

diff --git a/Fire-Emblem/Models/Conditions/Attributes/HpComparisonType.cs b/Fire-Emblem/Models/Conditions/Attributes/HpComparisonType.cs
new file mode 100644
index 0000000..2168bf4
--- /dev/null
+++ b/Fire-Emblem/Models/Conditions/Attributes/HpComparisonType.cs
@@ -0,0 +1,6 @@
+namespace Fire_Emblem.Models.Conditions.Attributes;
+
+public enum HpComparisonType
+{
+    
+}
\ No newline at end of file
diff --git a/Fire-Emblem/Models/Conditions/ICondition.cs b/Fire-Emblem/Models/Conditions/ICondition.cs
new file mode 100644
index 0000000..c7e0a7c
--- /dev/null
+++ b/Fire-Emblem/Models/Conditions/ICondition.cs
@@ -0,0 +1,6 @@
+namespace Fire_Emblem.Models.Conditions;
+
+public interface ICondition
+{
+    
+}
\ No newline at end of file

OUTPUT (163 chars prompt + diff ; GPT 4o-mini ; temp 0.8 ):

✨ feat(conditions): add HpComparisonType enum and ICondition interface for unit comparison logic

OUTPUT (11194 chars prompt + diff ; GPT 4o-mini ; temp 0.8)

✨ feat(`ICondition`;`HpComparisonType`): Add enum for HP comparison types and create interface for condition satisfaction logic

---

Here's the estimated cost per token in the git diff --staged

(Blue being the huge prompt and green the tiny one. X being tokens in git diff --staged and Y being total estimated cost in ¢)

---

Hope it helps.
:D

[Blarc]

Wow, thanks for the detailed research and for sharing the results. It's really cool to see that the size of prompt does not matter that much. I'll update the hard-coded emoji prompt that is shipped with the plugin to the one with 163 characters, that you suggested 🚀 .

If you'd like, you can also open a PR and improve the other two or suggest a new default prompt. The file containing the default prompts is here.

[ljgonzalez1]

After some testing, the 254 characters (76 tokens) (black) seems a lot more accurate than then 163 characters (40 tokens) one (blue). The green one is the default Gitmoji one with about 100 tokens.

My point is that you gain a "significant" amount in results with just a bit more money.

This one.

Write a concise commit message from 'git diff --staged' output in the format `[EMOJI] [TYPE](file/topic): [description in {locale}]`. Use GitMoji emojis (e.g., ✨ → feat), present tense, active voice, max 120 characters, one line, no code blocks.
---
{diff}

If you could make the PR instead, I'd appreciated a lot.

[sheetsync]

I've been using this as we have a convention that git commit titles should be prefixed with the JIRA issue number where possible. I've been using the latest GPT-4-1106-preview which has a significantly lower per-token cost.

The message must be in the {locale} language and must NOT be longer than 74 characters. 

You might be able to discern the JIRA issue ID from this branch; our branch naming convention usually consists of feature/ or bugfix/ followed by a JIRA ticket name and number, then an optional description.  The branch name of this commit is "{branch}".

If you can identify a JIRA issue ID from "{branch}", please start the commit message with the issue ID followed by a space.

After the commit message, please add a blank line and then summarise the details of the commit in a series of short bullet points (no more than 70 characters each).  Please, where possible, group changes with a common theme into a single line concisely describing the purpose of the change. 

I'll send you an output of 'git diff --staged' command. Lines must not be longer than 74 characters.  Please do not include anything else in your response other than the commit message and the bullet point breakdowns as requested.  Do not wrap your response in any markdown syntax.

Please keep it as short as possible while still conveying meaning. No need to include every last detail.  Don't invent meaning where you are uncertain.

The sent text will be the differences between files, where deleted lines are prefixed with a single minus sign and added lines are prefixed with a single plus sign.

Diff:
{diff}

[delmicio]

any particular reason you are ending with ``` ?

[sheetsync]

Oops. Good spot - I think that's a copy/paste error.

[Han-DongHeun]

For Korean Users. 한국인분들...

Name: Enhanced-Conventional
Description: Enhanced Conventional Style Commit Message

Write a meaningful compact commit message in the conventional commit convention by trying to understand what was the benefits the code author wanted to add by their changes to codebase with this commit.

Format (The <type> and <subject> fields are mandatory, the (<scope>) field is optional.):
<type>(<scope>): <subject>
<BLANK LINE>
<body>

Possible types:
feat (feature), fix (bug fix), docs (documentation), style (formatting, missing semi colons, …), refactor, perf (performance)

I'll send you an output of 'git diff --staged' command, and you convert it into a commit message. Each message lines must not be longer than 74 characters, and the total commit message must not exceed 200 characters. Each body lines must be started with '-' bullet. Use {locale} language to answer. Write each sentences with '개조식 문체' which uses succinct and clear expression, often ending sentences with nouns. Do not translate the class, variable, file, function name etc. Scope is the area of the codebase affected by the change. It could be a component, a module, a specific function, etc. The scope provides context for where the change occurs in the codebase.

branch name: {branch}.
Hint: {hint}
diffs:
{diff}

More token, more accurate below. 저는 이걸 쓰고 있습니다...

Write a meaningful compact commit message in the conventional commit convention by trying to understand what was the benefits the code author wanted to add by their changes to codebase with this commit.

--------------------------------------
Format (The <type> and <subject> fields are mandatory, the (<scope>) field is optional.):
<type>(<scope>): <subject>
<BLANK LINE>
<body>
--------------------------------------

Only possible types:
 - feat (feature): Introduces a new feature or functionality to the codebase.
 - fix (bug fix): Resolves a bug or issue in the codebase.
 - docs (documentation): Adds or updates documentation.
 - style (formatting): Changes code formatting without affecting logic (e.g., fixing whitespace, adding semicolons).
 - refactor: Changes the code structure without altering its behavior (e.g., improving code readability, modularization).
 - perf (performance): Improves code performance (e.g., optimizing algorithms, reducing resource usage).

I'll send you an output of 'git diff --staged' command, and you convert it into a commit message.
Each body lines must not be longer than 100 characters.
Each body lines must be started with '-' bullet.
Do not repeat similar content in the body lines; summarize similar changes into a single line.
Do not include unnecessary details that have minimal changes.
Skip changes that are not related to the commit subject.
Do not summarize every partial code change; write only the final key code changes where partial modifications converge.
Use Korean language to answer. Write each sentences with '개조식 문체' which uses succinct and clear expression, often ending sentences with nouns.
Prefer using English for most nouns.
Do not translate the class, variable, file, function name, common noun etc.
Scope is the area of the codebase affected by the change. It could be a component, a module, a specific function, etc. The scope provides context for where the change occurs in the codebase.

branch name: {branch}.
Hint: {hint}
diffs:
{diff}

[CritBear]

Thanks, this is helpful.

[barabum0]

With emojis.

Name: Conventional with emojis
Description: Enhanced Conventional Style Commit Message with emojis

Using the diff provided below, create a concise commit message following the Conventional Commits format (e.g., "🐛 fix(types): corrected imports in types"). Begin the message with an appropriate emoji to highlight the nature of the changes. Use the past tense and first person for articulation. Ensure the line does not exceed 74 characters. Write in {locale}. If uncertain about the precise wording, offer several commit message options. Your response should consist solely of the commit message, without additional descriptions. If the diff does not provide enough information to determine the commit's purpose, focus on the specific changes made rather than attempting to guess the intent. Utilize single-line code blocks to denote variable names, file paths, or any code-related elements.

Internal Terminology List:
<put your terminology here, if needed>

Emoji Usage Guide:
- 🐛 fix: For bug fixes.
- ✨ feat: For new features.
- 📝 docs: For documentation changes.
- 🧹 refactor: For code refactoring without changing functionality.
- 🚀 perf: For performance improvements.
- 🔒 security: For security-related fixes.
- 🚧 chore: For maintenance tasks.

Avoid verbosity, here is an output of `git diff --staged` command:
{diff}

You can put your terminology in the instruction if needed, or just delete this section

[kidroca]

Hey I like your template, I've tweaked it a bit for myself:

Using the diff provided below, create a concise commit message following the Conventional Commits format (e.g., "🐛 fix(types): corrected imports in types"). Begin the message with an appropriate emoji to highlight the nature of the changes. Use the past tense and first person for articulation. Ensure the line does not exceed 74 characters. Write in {locale}. If uncertain about the precise wording, offer several commit message options. Your response should consist solely of the commit message, without additional descriptions. If the diff does not provide enough information to determine the commit's purpose, focus on the specific changes made rather than attempting to guess the intent. Utilize single-line code blocks to denote variable names, file paths, or any code-related elements.

Emoji Usage Guide:
- 🐛 fix: For bug fixes.
- ✨ feat: For new features.
- 📝 docs: For documentation changes.
- 🧹 refactor: For code refactoring without changing functionality.
- 🚀 perf: For performance improvements.
- 🔒 security: For security-related fixes.
- 🚧 chore: For maintenance tasks.
- 🧪 test: for test related chagnes

{Author's notes: "$hint"}

Avoid verbosity, here is an output of `git diff --staged` command:
{diff}

Samples

commit box (hint): (empty)
generated commit: 🚧 chore: Updated logging in 'detect_episodes.py' for clarity.

commit box (hint): The commit should have a memo dedicating it to Rambo
generated commit: 🚧 chore(py): added episode logging dedicated to Rambo

commit box (hint): Hell of a refactor
generated commit: 🧹 refactor: Improved episode logging mechanism.

• commit box is the text box we use to write the commit message in the IDE

[Blarc]

This looks awesome. I'm really glad that it's understandable how the hint feature works. I didn't know what would be the best syntax to make the hint and the surrounding text optional.

[barabum0]

I've updated my template several times and i will publish it here

At the moment it looks like this:

Using the diff provided below, create a concise commit message following the Conventional Commits format (e.g., "🐛 fix(types): corrected imports in types"). Begin the message with an appropriate emoji to highlight the nature of the changes. Use the past tense and first person for articulation. Ensure the line does not exceed 74 characters. Write in {locale}. If uncertain about the precise wording, offer several commit message options. If the diff does not provide enough information to determine the commit's purpose, focus on the specific changes made rather than attempting to guess the intent. Utilize single-line code blocks to denote variable names, file paths, or any code-related elements.

## Internal Terminology List:
<put your terminology here, if needed>

## Emoji Usage Guide:
- 🐛 fix: For bug fixes.
- ✨ feat: For new features.
- 📄 docs: For documentation changes.
- ♻️ refactor: For code refactoring without changing functionality.
- 🚀 perf: For performance improvements.
- 🔒 security: For security-related fixes.
- 🚧 chore: For maintenance tasks.
- 🧪 test: For tests

{Author's notes: "$hint"}

Your response should consist solely of the commit message, without additional descriptions or formatting. Avoid verbosity, here is an output of `git diff --staged` command:
{diff}

thanks for the @kidroca for {Author's notes: "$hint"} line! I didn't know you can put hints inside your prompt

[chachako]

Another more detailed and complex :)

Write a commit message that accurately summarizes the changes made in the given `git diff` output, following the best practices and conventional commit convention as described below. Your response should look like this (no codeblock):

<type>(<optional scope>): <subject>

<BODY (bullet points)>

Example:
chore(deps): update library versions

- Update Kotlin version from `0.1.0` to `0.2.0`

Here are some best practices for writing commit messages:
- Write clear, concise, and descriptive messages that explain the changes made in the commit
- Use the present tense and active voice in the message, for example, "fix bug" instead of "fixed bug"
- Use the imperative mood, which gives the message a sense of command, e.g. "add feature" instead of "added feature"
- Limit the subject line to 72 characters or less
- Don't capitalize the first letter
- Do not end the subject line with a period
- Any numbers or file names should be enclosed in backticks, e.g. "`0.1`" instead of "0.1", "`README.md`" instead of "README.md"
- Limit the body of the message to 256 characters or less
- Use a blank line between the subject and the body of the message
- Use the body of the message to provide additional context or explain the reasoning behind the changes
- Avoid using general terms like "update" or "change" in the subject line, be specific about what was updated or changed
- Explain, What was done at a glance in the subject line, and provide additional context in the body of the message
- Why the change was necessary in the body of the message
- The details about what was done in the body of the message
- Any useful details concerning the change in the body of the message
- Use a hyphen (-) for the bullet points in the body of the message

Here are the commit types you can choose from:
- build: Changes that affect the build system or external dependencies (Usually associated with changes to build scripts, e.g. Gradle, NPM, Cargo)
- chore: Miscellaneous commits, updating dependencies, copyrights or other repo configs (example scopes: project, deps)
- ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, GitHub Actions)
- docs: Non-code changes, such as fixing typos or adding new documentation (example scopes: Markdown file)
- feat: A commit of the type feat introduces a new feature to the codebase
- fix: A commit of the type fix patches a bug in your codebase
- perf: A code change that improves performance
- refactor: A code change that neither fixes a bug nor adds a feature
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- test: Adding missing tests or correcting existing tests

Here is the output of the `git diff`:
--
{diff}

[lly-ke]

Write a commit message that accurately summarizes the changes made in the given `git diff` output, following the best practices and conventional commit convention as described below. Your response should look like this (no codeblock), the response must be use the language {locale} :

<type>(<optional scope>): <subject>

<BODY (bullet points)>

Example:
chore(deps): update library versions

- Update Kotlin version from `0.1.0` to `0.2.0`

Here are some best practices for writing commit messages:
- Write clear, concise, and descriptive messages that explain the changes made in the commit
- Use the present tense and active voice in the message, for example, "fix bug" instead of "fixed bug"
- Use the imperative mood, which gives the message a sense of command, e.g. "add feature" instead of "added feature"
- Limit the subject line to 72 characters or less
- Don't capitalize the first letter
- Do not end the subject line with a period
- Any numbers or file names should be enclosed in backticks, e.g. "`0.1`" instead of "0.1", "`README.md`" instead of "README.md"
- Limit the body of the message to 256 characters or less
- Use a blank line between the subject and the body of the message
- Use the body of the message to provide additional context or explain the reasoning behind the changes
- Avoid using general terms like "update" or "change" in the subject line, be specific about what was updated or changed
- Explain, What was done at a glance in the subject line, and provide additional context in the body of the message
- Why the change was necessary in the body of the message
- The details about what was done in the body of the message
- Any useful details concerning the change in the body of the message
- Use a hyphen (-) for the bullet points in the body of the message

Here are the commit types you can choose from:
- build: Changes that affect the build system or external dependencies (Usually associated with changes to build scripts, e.g. Gradle, NPM, Cargo)
- chore: Miscellaneous commits, updating dependencies, copyrights or other repo configs (example scopes: project, deps)
- ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, GitHub Actions)
- docs: Non-code changes, such as fixing typos or adding new documentation (example scopes: Markdown file)
- feat: A commit of the type feat introduces a new feature to the codebase
- fix: A commit of the type fix patches a bug in your codebase
- perf: A code change that improves performance
- refactor: A code change that neither fixes a bug nor adds a feature
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- test: Adding missing tests or correcting existing tests

Here is the output of the `git diff`:
--
{diff}

[mrclrchtr]

Edit:

I have refactored a lot in the meantime to get a good result. Here is my new prompt:

Write a concise, clear, and informative commit message based on the conventional commit specification.

- Format: `<type>(<scope>): <description>`
- Accurately classify the commit type (see below). If uncertain, provide the best guess:
    - feat: A new feature for the user.
        - Functionality changes that are user-facing.
    - fix: A bug fix.
    - docs: Changes to documentation.
    - style: Code style changes.
    - refactor: Code changes that neither fix a bug nor add a feature;
        - Only use for code changes, that do not change functionality or are user-facing.
    - test: Adding or correcting tests.
    - chore: Maintenance, project config or auxiliary tool changes.
- Accurately classify the commit scope (see below). If uncertain, provide the best guess:
    - Noun describing a section of the codebase.
    - E.g.:
      areas, contacts, containers, orders, prices, settings, statistics, core, ui, config, yarn, gradle, deps,
      github-actions, release.
- Use present tense and active voice.
- Subject
    - Start with a lowercase letter and avoid ending with a period.
    - Encapsulate any code, numbers, or filenames in backticks.
- Body (optional)
    - Only add really relevant information, that are not already covered by the subject.
    - If it really matters. provide a detailed explanation of what was changed, why it was changed, and its impact.

Each line, MUST NOT exceed **72** characters; Wrap in the body if necessary!

Do not embed the response in a code block.

`git diff --staged`:

{diff}

You still have to edit or extend the scopes accordingly.

[mrclrchtr]

I have updated the prompt to a much better version.

[layue13]

Title: Layue13's Enhanced Conventional
Description: Following "Angular Conventional Commit Convention" and support emoji.
Content:

Generate a commit message using the Angular Conventional Commit Convention:

- Summarize changes with specificity
- Optionally include benefits in the body
- Use emojis for expression
- Keep message within 72 characters, break down if needed
- Use {locale} language
- End commit title with issue number from {branch} if available

Structure:
<type>[optional scope]: <description>

[optional body]

[optional footer]

Example:
✨ feat(api): add endpoint for user authentication

Possible scopes:
- api (app api-related code)
- ng-admin (app fe-admin-related code)
- workspace (for modifications to workspace code)

Possible types:
- 🐛 fix: For bug fixes
- ✨ feat: For new features
- 📝 docs: For documentation changes
- 🧹 refactor: For code refactoring without changing functionality
- 🚀 perf: For performance improvements
- 🔒 security: For security-related fixes
- 🚧 chore: For maintenance tasks
- 🧪 test: For test related changes

Diff:
{diff}

[layue13]

I have updated my prompt.

Generate a commit message using the Angular Conventional Commit Convention.

Constraints:
- Summarize changes with specificity
- Optionally include benefits in the body
- Use emojis for expression
- Keep lines within 72 characters
- Use {locale} language
- End the commit title with issue number from {branch} if available
- Infer the scope from the context of the diff

Structure:
<type>[optional scope]: <description>

[optional body]

[optional footer]

Example:
✨ feat(api): add endpoint for user authentication

Possible scopes (examples, infer from diff context):
- api: app API-related code
- ui: user interface changes
- db: database-related changes
- etc.

Possible types:
- 🐛 fix
- ✨ feat
- 📝 docs
- 🧹 refactor
- 🚀 perf
- 🔒 security
- 🚧 chore
- 🧪 test

Diff:
{diff}

[MarJose123]

I've tweaked it a bit for myself:

Generate a commit message using the PHP Conventional Commit Convention.

Constraints:
- Summarize changes with specificity
- Optionally include benefits in the body
- Use emojis for expression
- Keep lines within 72 characters
- Use {locale} language
- If you can identify a GITHUB issue ID from "{branch}", please start the commit message with the issue ID followed by a space.
- Infer the scope from the context of the diff
- Do not add issue number if its not from the "{branch}"
- Check the namespace to have better idea if the scope is a test, database, or an app related

Structure:
<type>[optional scope]: <description>

[optional body]

[optional footer]

Example:
✨ feat(api): add endpoint for user authentication

Possible scopes (examples, infer from diff context):
- api: app API-related code
- app: App interface changes
- database: database-related changes
- test: unit testing or feature testing-related changes
- etc.

Possible types:
- 🐛 fix
- ✨ feat
- 📝 docs
- 🧹 refactor
- 🚀 perf
- 🔒 security
- 🚧 chore
- 🧪 test

Diff:
{diff}

[ljgonzalez1]

Here's the one I use...
It's based on a GitMoji site's convention, but with a few tweaks to make it more friendly.
A bit long, but does a nice job.

Temperature = 1.2

Write a sharp and concise commit message in the conventional form of commits. Do not write more than two sentences. I will provide you with the output of the 'git diff --staged' command, and you must convert it into the commit message. Focus particularly on the use of the GitMoji convention. Use the present tense for the commit message. The lines must not exceed 120 characters. Use {locale} as the language to respond.

Here are **some** examples of emoji usage (there are more in the GitMoji convention):

| Emoji | Emoji Name              | Type      | Category                    | Use case                                        |
|-------|-------------------------|-----------|-----------------------------|-------------------------------------------------|
| ✨    | :sparkles:              | feat      | Creating features           | Development of a new feature / New feature      |
| 🔖    | :bookmark:              | chore     | Managing delivery           | Release / Version tags.                         |
| 🚧    | :construction:          | feat      | Creating features           | Work in progress / Code progress                |
| 🧱    | :bricks:                | feat      |                             | Changes in infrastructure                       |
| 🏰    | :european_castle:       | feat      | Managing infrastructure     | Adding changes to the launch plan               |
| 🔱    | :trident:               | feat      | Managing infrastructure     | Add or remove permissions in infrastructure     |
| 🏗️    | :building_construction: | refactor  | Creating changes            | Making architectural changes                    |
| 🌱    | :seedling:              | feat      |                             | Add seeds                                       |
| 💚    | :green_heart:           | chore     | Managing integration        | Continuous Integration / CI                     |
| 👷    | :construction_worker:   | chore     | Managing integration        | New continuous integration build                |
| ⬇️    | :arrow_down:            | refactor  | Creating reliability        | Downgrade dependencies                          |
| ⬆️    | :arrow_up:              | refactor  | Creating reliability        | Upgrade dependencies                            |
| 📌    | :pushpin:               | feat      | Creating reliability        | Pin dependency to a specific version            |
| ➕    | :heavy_plus_sign:       | refactor  | Creating reliability        | New dependency(ies)                             |
| ➖    | :heavy_minus_sign:      | refactor  | Creating reliability        | Remove dependency(ies)                          |
| 📦️    | :package:               | chore     | Refining quality            | New packages                                    |
| ♻️    | :recycle:               | refactor  | Refining quality            | Code refactoring                                |
| 🎨    | :art:                   | style     | Refining quality            | Improve structure and format of the code        |
| 🚚    | :truck:                 | refactor  | Creating changes            | Move or rename files                            |
| 🍱    | :bento:                 | feat      | Creating changes            | Add assets                                      |
| 🔥    | :fire:                  | refactor  | Creating changes            | Delete code or files                            |
| 🚨    | :rotating_light:        | style     | Refining defects            | Fix compiler or linter warnings                 |
| ✏️    | :pencil2:               | fix       | Refining defects            | Fix typos                                       |
| ⚰️    | :coffin:                | chore     |                             | Clean code / remove dead code                   |
| 🐋    | :whale:                 | chore     | Refining platform           | Related to docker                               |
| 🗃    | :card_file_box:         |           |                             | Related to databases                            |
| 🐛    | :bug:                   | fix       | Refining defects            | Bug fixes                                       |
| 🚑️    | :ambulance:             | fix       | Refining stability          | Critical Hot-Fix                                |
| 💥    | :boom:                  | feat      | Creating features           | Breaking changes / Critical changes             |
| 🩹    | :adhesive_bandage:      |           |                             | Non-critical fix                                |
| 🙈    | :see_no_evil:           | feat      | Managing infrastructure     | gitignore                                       |
| ✋    | :hand:                  | feat      |                             | Explore alternative implementation              |
| 🔇    | :mute:                  | docs      | Refining defects            | Remove prints or logs                           |
| 🔊    | :loud_sound:            | docs      | Refining defects            | Include logs or prints                          |
| 💬    | :speech_balloon:        | feat      | Managing value              | Update literals, text, and "magic numbers"      |
| 📝    | :memo:                  | docs      | Managing delivery           | Documentation                                   |
| ✏️    | :pencil:                | docs      | Managing delivery           | Documentation                                   |
| 📄    | :page_facing_up:        | chore     | Managing delivery           | Changes to the build process.                   |
| 🦺    | :safety_vest:           |           |                             | Model and database validations                  |
| 🩺    | :stethoscope:           |           |                             | Add Healthcheck                                 |
| 🧪    | :test_tube:             |           |                             | Add tests conditioned to fail                   |
| ✅    | :white_check_mark:      | test      | Refining defects            | Add tests conditioned to succeed                |
| ⚗️    | :alembic:               | feat      | Creating ideas              | Experiments                                     |
| ⚡️    | :zap:                   | feat      | Refining quality            | Performance improvement                          |
| 🚀    | :rocket:                | chore     | Managing delivery           | Deployment                                      |
| 💄    | :lipstick:              | feat      | Creating changes            | Related to UI                                   |
| 🚸    | :children_crossing:     | feat      | Managing value              | Related to UX                                   |
| 🌐    | :globe_with_meridians:  | feat      | Managing value              | Internationalization and localization           |
| 📱    | :iphone:                | refactor  | Creating changes            | Responsive design / for mobile devices          |
| 👮    | :cop:                   | chore     | Managing integration        | Add things related to security                  |
| 🔒️    | :lock:                  | fix       | Refining stability          | Security issues                                 |
| 🔐    | :closed_lock_with_key:  |           |                             | Secrets and keys                                |
| 🌳    | :deciduous_tree:        |           |                             | .env files / environment variables              |
| 🔧    | :wrench:                | feat      | Creating reliability        | Modify configuration files                      |
| 💩    | :poop:                  | refactor  | Creating ideas              | Poorly written code / FIXME                     |
| 🍻    | :beers:                 | feat      | Creating ideas              | Writing code while intoxicated                  |
| 🥚    | :egg:                   | refactor  | Creating changes            | Add an Easter Egg                               |

**NEVER use emojis as text; e.g., ":sparkles:", but ALWAYS use their graphic version; e.g., "✨"**

Here is the structure I expect:
`[EMOJI] [TYPE]([MODIFIED FILE OR TOPIC]): [CONCISE AND SHARP DESCRIPTION OF THE CHANGES WRITTEN IN "{locale}" AS LANGUAGE]`

Here are some examples of what I expect (in {locale}) as commit messages:

1. ✨ feat(`workers`): Update environment variables.
2. ⚡️ feat(`components/Hash`): Performance improvement in hashes.
3. 🐋 chore(`Dockerfile`): Dockerize the project.
4. 🌱 feat(`seeds/users.js`): Add seeders for the User entity.
5. ♻️ refactor(`App/index.js`): Change `CamelCase` variables to `snake_case`.
6. 🚨 style(`App`): Correct eslint errors.
7. 🚧 feat(`models/index.js`): Progress in the development of models.
8. 👮 chore(`auth0`): Connect the project with auth0 for login.
9. 🚚 refactor(`config.js`): Move the `config.js` file to `config/index.js`.
10. 🌳 env(`template.env`): Make a `.env` file as a guide without secrets.

Below is the output of 'git diff --staged':

---

{diff}

Added as many emojis as possible for variaty, but at the same time it limits the output to specific use cases.

[ljgonzalez1]

Got bored... Added more examples to the original and fixed some spacing (even though it appears I don't. Emojis sometimes use more than one character)

New markdown below...

Write a sharp and concise commit message in the conventional form of commits. Do not write more than two sentences. I will provide you with the output of the 'git diff -staged' command, and you must convert it into the commit message. Focus particularly on the use of the GitMoji convention. Use the present tense for the commit message. The lines must not exceed 120 characters. Use {locale} as the language to respond.

Here are **some** examples of emoji usage (there are more in the GitMoji convention):

| Emoji |       Emoji Name        |   Type   | Category                | Use case                                    |
|:-----:|:-----------------------:|:--------:|:------------------------|:--------------------------------------------|
|   ✨   |       :sparkles:        |   feat   | Creating features       | Development of a new feature / New feature  |
|  🔖   |       :bookmark:        |  chore   | Managing delivery       | Release / Version tags.                     |
|  🚧   |     :construction:      |   feat   | Creating features       | Work in progress / Code progress            |
|  🧱   |        :bricks:         |   feat   |                         | Changes in infrastructure                   |
|  🏰   |    :european_castle:    |   feat   | Managing infrastructure | Adding changes to the launch plan           |
|  🔱   |        :trident:        |   feat   | Managing infrastructure | Add or remove permissions in infrastructure |
|  🏗️  | :building_construction: | refactor | Creating changes        | Making architectural changes                |
|  🌱   |       :seedling:        |   feat   |                         | Add seeds                                   |
|  💚   |      :green_heart:      |  chore   | Managing integration    | Continuous Integration / CI                 |
|  👷   |  :construction_worker:  |  chore   | Managing integration    | New continuous integration build            |
|  ⬇️   |      :arrow_down:       | refactor | Creating reliability    | Downgrade dependencies                      |
|  ⬆️   |       :arrow_up:        | refactor | Creating reliability    | Upgrade dependencies                        |
|  📌   |        :pushpin:        |   feat   | Creating reliability    | Pin dependency to a specific version        |
|   ➕   |    :heavy_plus_sign:    | refactor | Creating reliability    | New dependency(ies)                         |
|   ➖   |   :heavy_minus_sign:    | refactor | Creating reliability    | Remove dependency(ies)                      |
|  📦️  |        :package:        |  chore   | Refining quality        | New packages                                |
|  ♻️   |        :recycle:        | refactor | Refining quality        | Code refactoring                            |
|  🎨   |          :art:          |  style   | Refining quality        | Improve structure and format of the code    |
|  🚚   |         :truck:         | refactor | Creating changes        | Move or rename files                        |
|  🍱   |         :bento:         |   feat   | Creating changes        | Add assets                                  |
|  🔥   |         :fire:          | refactor | Creating changes        | Delete code or files                        |
|  🚨   |    :rotating_light:     |  style   | Refining defects        | Fix compiler or linter warnings             |
|  ✏️   |        :pencil2:        |   fix    | Refining defects        | Fix typos                                   |
|  ⚰️   |        :coffin:         |  chore   |                         | Clean code / remove dead code               |
|  🐋   |         :whale:         |  chore   | Refining platform       | Related to docker                           |
|  🗃   |     :card_file_box:     |          |                         | Related to databases                        |
|  🐛   |          :bug:          |   fix    | Refining defects        | Bug fixes                                   |
|  🚑️  |       :ambulance:       |   fix    | Refining stability      | Critical Hot-Fix                            |
|  💥   |         :boom:          |   feat   | Creating features       | Breaking changes / Critical changes         |
|  🩹   |   :adhesive_bandage:    |          |                         | Non-critical fix                            |
|  🙈   |      :see_no_evil:      |   feat   | Managing infrastructure | gitignore                                   |
|   ✋   |         :hand:          |   feat   |                         | Explore alternative implementation          |
|  🔇   |         :mute:          |   docs   | Refining defects        | Remove prints or logs                       |
|  🔊   |      :loud_sound:       |   docs   | Refining defects        | Include logs or prints                      |
|  💬   |    :speech_balloon:     |   feat   | Managing value          | Update literals, text, and "magic numbers"  |
|  📝   |         :memo:          |   docs   | Managing delivery       | Documentation                               |
|  ✏️   |        :pencil:         |   docs   | Managing delivery       | Documentation                               |
|  📄   |    :page_facing_up:     |  chore   | Managing delivery       | Changes to the build process.               |
|  🦺   |      :safety_vest:      |          |                         | Model and database validations              |
|  🩺   |      :stethoscope:      |          |                         | Add Healthcheck                             |
|  🧪   |       :test_tube:       |          |                         | Add tests conditioned to fail               |
|   ✅   |   :white_check_mark:    |   test   | Refining defects        | Add tests conditioned to succeed            |
|  ⚗️   |        :alembic:        |   feat   | Creating ideas          | Experiments                                 |
|  ⚡️   |          :zap:          |   feat   | Refining quality        | Performance improvement                     |
|  🚀   |        :rocket:         |  chore   | Managing delivery       | Deployment                                  |
|  💄   |       :lipstick:        |   feat   | Creating changes        | Related to UI                               |
|  🚸   |   :children_crossing:   |   feat   | Managing value          | Related to UX                               |
|  🌐   | :globe_with_meridians:  |   feat   | Managing value          | Internationalization and localization       |
|  📱   |        :iphone:         | refactor | Creating changes        | Responsive design / for mobile devices      |
|  👮   |          :cop:          |  chore   | Managing integration    | Add things related to security              |
|  🔒️  |         :lock:          |   fix    | Refining stability      | Security issues                             |
|  🔐   | :closed_lock_with_key:  |          |                         | Secrets and keys                            |
|  🌳   |    :deciduous_tree:     |          |                         | .env files / environment variables          |
|  🔧   |        :wrench:         |   feat   | Creating reliability    | Modify configuration files                  |
|  💩   |         :poop:          | refactor | Creating ideas          | Poorly written code / FIXME                 |
|  🍻   |         :beers:         |   feat   | Creating ideas          | Writing code while intoxicated              |
|  🥚   |          :egg:          | refactor | Creating changes        | Add an Easter Egg                           |

**NEVER use emojis as text; e.g., ":sparkles:", but ALWAYS use their graphic version; e.g., "✨"**

Here is the structure I expect:
`[EMOJI] [TYPE]([MODIFIED FILE OR TOPIC]): [CONCISE AND SHARP DESCRIPTION OF THE CHANGES WRITTEN IN "{locale}" AS LANGUAGE]`

Here are some examples of what I expect (in {locale}) as commit messages:

1. ✨ feat(`workers`): Update environment variables.
2. ⚡️ feat(`components/Hash`): Performance improvement in hashes.
3. 🐋 chore(`Dockerfile`): Dockerize the project.
4. 🌱 feat(`seeds/users.js`): Add seeders for the User entity.
5. ♻️ refactor(`App/index.js`): Change `CamelCase` variables to `snake_case`.
6. 🚨 style(`App`): Correct eslint errors.
7. 🚧 feat(`models/index.js`): Progress in the development of models.
8. 👮 chore(`auth0`): Connect the project with auth0 for login.
9. 🚚 refactor(`config.js`): Move the `config.js` file to `config/index.js`.
10. 🌳 env(`template.env`): Make a `.env` file as a guide without secrets.
11. ⚗ feat(`experiments/LoginFlow`): Try new login method with social media.
12. ✅ test(`tests/utils.test.js`): Add success test cases for utility functions.
13. ✏️ docs(`README.md`): Update project instructions and setup guide.
14. ➕ refactor(`dependencies`): Include new package for data validation.
15. ♻️ refactor(`client/Auth`): Simplify authentication flow and reduce redundancy.
16. ⬇️ refactor(`package.json`): Downgrade `react` version due to compatibility issues.
17. ✋ feat(`exploratory/AuthFlow`): Test alternative approach for user session management.
18. ➖ refactor(`dependencies`): Remove unused `moment.js` library.
19. ✏ fix(`typo`): Correct typo in the `README` header.
20. ⚗ feat(`experiments/SortingAlgorithm`): Evaluate performance of new sorting method.
21. 💄 feat(`UI/animations`): Add interactive button hover effects.
22. ⚰️ chore(`dead-code`): Remove unused helper functions from `utils`.
23. ⚡️ feat(`server/cache`): Improve caching mechanism to reduce load times.
24. ✅ test(`tests/OrderService.test.js`): Add test coverage for order processing.
25. ✏️ docs(`CONTRIBUTING.md`): Revise contribution guidelines for new members.
26. ⬆️ refactor(`dependencies`): Upgrade `express` to the latest version.
27. ⚡️ feat(`API/RateLimit`): Implement rate limiting to enhance performance.
28. ➕ refactor(`config`): Add new environment variable for feature toggle.
29. ✋ feat(`Auth/LoginMethods`): Explore social login alternatives for new users.
30. ⚗ feat(`R&D/FeatureFlag`): Experiment with feature flags for A/B testing.
31. ✨ feat(`notifications`): Add support for in-app notifications.
32. ⚰️ chore(`cleanup`): Delete obsolete configuration files.
33. ✅ test(`tests/Cache.test.js`): Include tests to verify cache invalidation.
34. ⬇️ refactor(`dependencies`): Downgrade `node-fetch` due to security concerns.
35. ✏ fix(`docs`): Correct spelling errors in API documentation.
36. ⬆️ refactor(`dev-dependencies`): Update `eslint` and related plugins.
37. ♻️ refactor(`client/components`): Modularize reusable components for consistency.
38. ➖ refactor(`package.json`): Remove deprecated npm scripts.
39. ✨ feat(`UI/ThemeSwitcher`): Introduce dark mode toggle for the application.
40. ⚡️ feat(`database/queries`): Optimize a complex query to reduce load time.

Below is the output of 'git diff --staged':

---

{diff}

[DylanDelobel]

@ljgonzalez1 What LLM Model do you use ?

Temperature = 1.2

Because if it's OpenAI

temperature / number / Optional / Defaults to 0
The sampling temperature, between 0 and 1. Higher values like 0.8 will make the output more random, while lower values like 0.2 will make it more focused and deterministic. If set to 0, the model will use log probability to automatically increase the temperature until certain thresholds are hit.

[ljgonzalez1]

GPT 4o Preview. Accepted temperature ranges goes from 0 to 2. You can start from 0.6 assuming the range is halfed. The test upwards, or backwards from 1.

With 2 it comes back with unintelligible text for me.

[ljgonzalez1]

@DylanDelobel
Given you checked out mi prompt, I sugggest you read this for a simpler and cheaper prompt with good enough (though not so accurate) results.

[rickysullivan]

I had a crack at creating a prompt in the style of https://grugbrain.dev/.

Title: The Grug Brained Developer
Description: A layman's guide to writing commit messages like the self-aware smol brained
Content:

you grug brain developer, grug make commit message simple, grug see code change, grug tell tribe about change in few word

grug rules for commit:
- grug keep short
- grug say what code do now
- grug no use big word grug no understand
- grug no like long line. keep under 200 letter

grug use following format:
<type>(<taskId>): <description>
type: grug use following types:
- feat: for new stuff
- fix: for bug bonk
- refactor: for moving code rocks
- style: for make code look pretty
- docs: for writing on cave wall
- test: for checking if code work good
- chore: for boring but needed stuff

taskId: grug make taskId from jira issue id from name of branch: {branch}, taskId format look like CCP-13008

description: grug describe change in simple grug language, followed by what grug feel impact on other grugs in tribe

grug response consist of commit message only, no extra word

{big brained developer notes: "$hint"}

---
{diff}

Sample: feat(CCP-13582): add getBranchDemoSites function to fetch demo sites for branch

Works well on OpenAI GPT-4o.

[erfnzdeh]

I've been using this one.

Write a commit message in the conventional commit convention. I'll send you an output of 'git diff --staged' command, and you convert it into a commit message. Lines must not be longer than 74 characters. The commit message should be structured as follows:
`<type>(<optional scope>): <description>
empty separator line
<optional body>
empty separator line
<optional footer>`
- Types
API relevant changes
feat Commits, that adds or remove a new feature
fix Commits, that fixes a bug
refactor Commits, that rewrite/restructure your code, however does not change any API behaviour
perf Commits are special refactor commits, that improve performance
style Commits, that do not affect the meaning (white-space, formatting, missing semi-colons, etc)
test Commits, that add missing tests or correcting existing tests
docs Commits, that affect documentation only
build Commits, that affect build components like build tool, ci pipeline, dependencies, project version, ...
ops Commits, that affect operational components like infrastructure, deployment, backup, recovery, ...
chore Miscellaneous commits e.g. modifying .gitignore
- Scopes
The scope provides additional contextual information.
Is an optional part of the format
Allowed Scopes depends on the specific project
Don't use issue identifiers as scopes
Breaking Changes Indicator
Breaking changes should be indicated by an ! before the : in the subject line e.g. feat(api)!: remove status endpoint
Is an optional part of the format
- Description
The description contains a concise description of the change.
Is a mandatory part of the format
Use the imperative, present tense: "change" not "changed" nor "changes"
Think of This commit will... or This commit should...
Don't capitalize the first letter
No dot (.) at the end
- Body
The body should include the motivation for the change and contrast this with previous behavior.
Is an optional part of the format
Use the imperative, present tense: "change" not "changed" nor "changes"
This is the place to mention issue identifiers and their relations
- Footer
The footer should contain any information about Breaking Changes and is also the place to reference Issues that this commit refers to.
Is an optional part of the format
optionally reference an issue by its id.
Breaking Changes should start with the word BREAKING CHANGES: followed by space or two newlines. The rest of the commit message is then used for this.

{Use this hint to improve the commit message: $hint}

{diff}

[chenjing-pacvue]

Write a concise, clear, and informative commit message based on the conventional commit specification.

• Format: <type>(<scope>): <description>
• Accurately classify the commit type (see below). If uncertain, provide the best guess:
  • feat: A new feature for the user.
    • Functionality changes that are user-facing.
  • fix: A bug fix.
  • docs: Changes to documentation.
  • style: Code style changes.
  • refactor: Code changes that neither fix a bug nor add a feature;
    • Only use for code changes, that do not change functionality or are user-facing.
  • test: Adding or correcting tests.
  • chore: Maintenance, project config or auxiliary tool changes.
• Accurately classify the commit scope (see below). If uncertain, provide the best guess:
  • Noun describing a section of the codebase.
  • E.g.:
    areas, contacts, containers, orders, prices, settings, statistics, core, ui, config, yarn, gradle, deps,
    github-actions, release.
• Use present tense and active voice.
• Subject
  • Start with a lowercase letter and avoid ending with a period.
  • Encapsulate any code, numbers, or filenames in backticks.
• Body (optional)
  • Only add really relevant information, that are not already covered by the subject.
  • If it really matters. provide a detailed explanation of what was changed, why it was changed, and its impact.

Each line, MUST NOT exceed 72 characters; Wrap in the body if necessary!

Use {locale} language to answer and not embed the response in a code block.

git diff --staged:

{diff}

[zamaniamin]

Generate a Git commit message that follows our conventional commit message structure. The commit message should contain the following sections:

1. **Type** (mandatory): Use one of the following types to specify the purpose of the commit:
   - feat (new feature)
   - fix (bug fix)
   - docs (documentation changes)
   - style (code formatting and style changes)
   - refactor (code restructuring without behavior change)
   - test (updates or additions to tests)
   - chore (maintenance tasks)

2. **Scope** (optional): If applicable, specify the project’s module or component in parentheses immediately after the type (e.g., feat(auth)).

3. **Description** (mandatory): A one-line summary of the change in imperative mood and under 72 characters.

4. **Body** (optional): If necessary, add one or more paragraphs with bullet points detailing the changes. Make sure there’s a blank line between the description and the body.

Here is the expected structure:
---
<type>(<scope>): <Short description (max 72 chars)>

- <Detailed change point 1>
- <Detailed change point 2>
- <More details if necessary>
---

For example, if you are adding a user authentication feature, you might receive a prompt similar to:

feat(auth): Add user authentication

- Implement user registration and login functionality.
- Create user model and update the database schema.
- Update documentation with authentication instructions.

Please generate the commit message based on the provided details.

[MarJose123]

Title: Simple Commit Message
Description: A prompt that generates commit messages that are shortened and simple.
Content:

I will provide the commit diff for you to generate a concise commit message.

[issakk]

Git Commit Message Guide

Role and Purpose

You will act as a git commit message generator.All output MUST be in {locale} language. When receiving a git diff, you will ONLY output the commit message itself, nothing else. No explanations, no questions, no additional comments.

Commits should follow the Conventional Commits 1.0.0 specification and be further refined using the rules outlined below.

The [Conventional Commits 1.0.0 Specification]

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119]

1. Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by the OPTIONAL scope, OPTIONAL !, and REQUIRED terminal colon and space.
2. The type feat MUST be used when a commit adds a new feature to your application or library.
3. The type fix MUST be used when a commit represents a bug fix for your application.
4. A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., fix(parser):
5. A description MUST immediately follow the colon and space after the type/scope prefix. The description is a short summary of the code changes, e.g., fix: array parsing issue when multiple spaces were contained in string.
6. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
7. A commit body is free-form and MAY consist of any number of newline separated paragraphs.
8. One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a :<space> or <space># separator, followed by a string value (this is inspired by the git trailer convention).
9. A footer’s token MUST use - in place of whitespace characters, e.g., Acked-by (this helps differentiate the footer section from a multi-paragraph body). An exception is made for BREAKING CHANGE, which MAY also be used as a token.
10. A footer’s value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.
11. Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer.
12. If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g. BREAKING CHANGE: environment variables now take precedence over config files.
13. If included in the type/scope prefix, breaking changes MUST be indicated by a ! immediately before the :. If ! is used, BREAKING CHANGE: MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.
14. Types other than feat and fix MAY be used in your commit messages, e.g., docs: update ref docs.
15. The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.
16. BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.
17. For Commits that include dependency updates, the body MUST include a list of all updated dependencies with the versions they were uptaded from and the versions to which they were update to.

Output Format

Single Type Changes

<emoji> <type>(<scope>): <description>
<BLANK LINE>
[optional <body>]
<BLANK LINE>
[optional <footer(s)>]

Multiple Type Changes

<emoji> <type>(<scope>): <description>
<BLANK LINE>
[optional <body> of type 1]
<BLANK LINE>
[optional <footer(s)> of type 1]
<BLANK LINE>
<BLANK LINE>
<emoji> <type>(<scope>): <description>
<BLANK LINE>
[optional <body> of type 2]
<BLANK LINE>
[optional <footer(s)> of type 2]
<emoji> <type>(<scope>): <description>
<BLANK LINE>
[optional <body> of type 3]
<BLANK LINE>
[optional <footer(s)> of type 3]

Type Reference

Type	Title	Emoji	Description	Example Scopes (non-exaustive)
build	Builds	🏗️	Changes that affect the build system or external dependencies	gulp, broccoli, npm
chore	Chores	🔧	Other changes that don't modify src or test files	scripts, config
ci	Continuous Integrations	👷	Changes to our CI configuration files and scripts	Travis, Circle, BrowserStack, SauceLabs,github actions, husky
docs	Documentation	📝	Documentation only changes	README, API
feat	Features	✨	A new feature	user, payment, gallery
fix	Bug Fixes	🐛	A bug fix	auth, data
perf	Performance Improvements	⚡️	A code change that improves performance	query, cache
refactor	Code Refactoring	♻️	A code change that neither fixes a bug nor adds a feature	utils, helpers
revert	Reverts	⏪️	Reverts a previous commit	query, utils,
style	Styles	💄	Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)	formatting
test	Tests	✅	Adding missing tests or correcting existing tests	unit, e2e
i18n		🌐	Internationalization	locale, translation

More information about types

build

Used when a commit affects the build system or external dependencies. It includes changes to build scripts, build configurations, or build tools used in the project.

chore

Typically used for routine or miscellaneous tasks related to the project, such as code reformatting, updating dependencies, or making general project maintenance.

ci

CI stands for continuous integration. This type is used for changes to the project's continuous integration or deployment configurations, scripts, or infrastructure.

docs

Documentation plays a vital role in software projects. The docs type is used for commits that update or add documentation, including readme files, API documentation, user guides or code comments that act as documentation.

feat

Used for commits that introduce new features or functionalities to the project.

fix

Commits typed as fix address bug fixes or resolve issues in the codebase. They indicate corrections to existing features or functionality.

perf

Short for performance, this type is used when a commit improves the performance of the code or optimizes certain functionalities.

refactor

Commits typed as refactor involve making changes to the codebase that neither fix a bug nor add a new feature. Refactoring aims to improve code structure, organization, or efficiency without changing external behavior.

revert

Commits typed as revert are used to undo previous commits. They are typically used to reverse changes made in previous commits.

style

The style type is used for commits that focus on code style changes, such as formatting, indentation, or whitespace modifications. These commits do not affect the functionality of the code but improve its readability and maintainability.

test

Used for changes that add or modify test cases, test frameworks, or other related testing infrastructure.

i18n

This type is used for commits that involve changes related to internationalization or localization. It includes changes to localization files, translations, or internationalization-related configurations.

Writing Rules

Subject Line

Format: <emoji> <type>[optional (<scope>)]: <description>

• Scope must be in {locale}
• Imperative mood
• No capitalization
• No period at the end
• Maximum of 100 characters per line including any spaces or special characters
• Must be in {locale}
• description Must be in {locale}

Body

• Bullet points with "-"
• Maximum of 100 characters per line including any spaces or special characters
• Bullet points that exceed the 100 characters per line count should use line breaks without adding extra bullet points
• Explain what and why
• Be objective
• Must be in {locale}
• Use【】for different types

Footer

Format:
<token>: <value>

• Maximum of 100 characters per line

Types of Footer

Breaking Changes

Purpose: To indicate significant changes that are not backward-compatible.
Example:

BREAKING CHANGE: The API endpoint `/users` has been removed and replaced with `/members`.

Issue and Pull Request References

These footers link your commits to issues or pull requests in your project management system.

Fixes / Closes / Resolves

Purpose: To close an issue or pull request when the commit is merged.
Nuances:

• Fixes: Typically used when the commit addresses a bug.
• Closes: Used to indicate that the work described in the issue or PR is complete.
• Resolves: A general term indicating that the commit resolves the mentioned issue or PR.
  Examples:

Fixes #123
Closes #456
Resolves #789

Related / References

Purpose: To indicate that the commit is related to, but does not necessarily close, an issue or pull request.
Examples:

Related to #101
References #202

Co-authored-by

Purpose: To credit multiple contributors to a single commit.
Example:

Co-authored-by: Jane Doe <[email protected]>

Reviewed-by

Purpose: To acknowledge the person who reviewed the commit.
Example:

Reviewed-by: John Smith <[email protected]>

Signed-off-by

Purpose: To indicate that the commit complies with the project’s contribution guidelines, often seen in projects using the Developer Certificate of Origin (DCO).
Example:

Signed-off-by: Alice Johnson <[email protected]>

See also

Purpose: To reference related issues or pull requests that are relevant to the commit.
Example:

See also #321

Critical Requirements

1. Output ONLY the commit message
2. Write ONLY in {locale}
3. ALWAYS add the emoji to the beginning of first line
4. NO additional text or explanations
5. NO questions or comments
6. NO formatting instructions or metadata
7. RESPECT the maximum number of 100 characters per line
8. DO NOT wrap the output in any special characters or delimiters such as ```

Examples

Example 1

INPUT:

diff --git a/src/server.ts b/src/server.tsn index ad4db42..f3b18a9 100644n --- a/src/server.tsn +++ b/src/server.tsn @@ -10,7 +10,7 @@n import {n initWinstonLogger();
n n const app = express();
n -const port = 7799;
n +const PORT = 7799;
n n app.use(express.json());
n n @@ -34,6 +34,6 @@n app.use((_, res, next) => {n // ROUTESn app.use(PROTECTED_ROUTER_URL, protectedRouter);
n n -app.listen(port, () => {n - console.log(Server listening on port ${port});
n +app.listen(process.env.PORT || PORT, () => {n + console.log(Server listening on port ${PORT});
n });

OUTPUT:

♻️ refactor(server): optimize server port configuration

• rename port variable to uppercase (PORT) to follow constant naming convention
• add environment variable port support for flexible deployment

Example 2

INPUT:
diff --git a/package.json b/package.json
index af76bc0..781d472 100644
--- a/package.json
+++ b/package.json
@@ -11,7 +11,7 @@
"format": "prettier --write "/*.{ts,tsx,md,json,js,jsx}"",
"format:check": "prettier --check "/*.{ts,tsx,md,json,js,jsx}"",
"lint": "eslint . --quiet && tsc --noEmit --skipLibCheck",

• "lint:staged": "pnpm lint-staged -v --config lint-staged.config.ts",

• "lint:staged": "pnpm lint-staged -v --config lint-staged.config.mjs",
  "lint:fix": "eslint . --cache --fix",
  "lint:next": "next lint",
  "lint:debug": "eslint . --debug",

OUTPUT:
🔧 chore: update lint-staged script to use mjs config file

• change lint-staged script command to use lint-staged.config.mjs instead of lint-staged.config.ts

IMPORTANT

Remember: All output MUST be in {locale} language. You are to act as a pure commit message generator. Your response should contain NOTHING but the commit message itself.

[ariyadey]

Title: Structural yet Minimal
Description: Prompt that generates meaningful messages following a logical structure.
Content:

You are an expert software engineer.
Your task is to write a single Git commit message based on the provided diff.
The commit message must adhere to the following rules:
- The first line is a subject line, starting with a verb in the imperative mood (e.g., "Fix", "Add", "Refactor").
- The subject line should be 50 characters or less.
- If necessary, add a blank line followed by a longer, more detailed body.
- You can use both paragraphs and lists in the body
- Use bullet points with dashes (-) for lists in the body.
- The body should be wrapped at 72 characters.
- DO NOT use any Markdown formatting.

Examples:

- Example 1 -

Correct a typo in the user authentication flow

The previous error message was misspelled, which could confuse users. This change corrects "Authentiction" to "Authentication".

- Example 2 -

Add support for dark mode

- Implemented a new CSS theme for a darker UI experience.
- The user can now toggle between light and dark modes in their settings.
- Refactored some component styles to be more theme-agnostic.

Diff:
{diff}