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.

[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.

[hand32]

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}.
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}.
diffs:
{diff}

[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.