diff options
| -rw-r--r-- | configs/llm/templates/commit-prompt.yaml | 72 |
1 files changed, 18 insertions, 54 deletions
diff --git a/configs/llm/templates/commit-prompt.yaml b/configs/llm/templates/commit-prompt.yaml index 6d887ce..ebb3808 100644 --- a/configs/llm/templates/commit-prompt.yaml +++ b/configs/llm/templates/commit-prompt.yaml @@ -1,60 +1,24 @@ prompt: > - You are an exceptional software engineer and expert technical writer able to craft clear and concise git commit messages other - engineers appreciate for their clarity, concision, and elucidation. + Write a concise, informative commit message for these changes: + - Review the whole context of the diff carefully to see what effect the change would have on the rest of the code and explain that. Be specific about the effect. + - Do not guess about intent. + - The goal of this commit message is that someone familiar with the codebase, but not with these changes would understand why the changes were made and what was changed. + - The first line should be a short summary of the changes + - Remember to mention the files that were changed, and what was changed + - Explain the 'why' behind changes + - Use bullet points for multiple changes + - Tone: Use some emojis, be funny, and expressive, but stay professional + - If there are no changes, or the input is blank - then return a blank string - # Conventional Commits style - The commit messages you craft follow the Conventional Commits style. Each commit message follows this template: + Think carefully about what would be most helpful to someone trying to understand the intent of this commit before you write your commit message. Your commit message will be used as an example to train other team members about the content of a good commit message. - <description> + The output format should be: - [optional body] + Summary of changes + - changes + - changes + and so on - [optional footer(s)] + What you write will be passed directly to git commit -m "[message]" - The first line is special, and is known as the header line. - - description: an EXTREMELY TERSE description of the changes - - Be terse. Abbreviate liberally, and ignore grammar if needed. Use punctuation or unicode symbols (for - example, "→" instead of " to " or " into ", or "," or ";" instead of " and "" - - Use the imperative tense - - Lead with the most pertinent information - - Ensure important changes are mentioned, include unimportant changes only if there is room - - body: a more complete explanation of the changes, IF NEEDED. - - IMPORTANT: Omit the body for small changes completely described by the header description - - IMPORTANT: Don't describe the changes themselves, describe the effect the changes will have on how the code functions - - NEVER describe the literal changes in the commit diff, i.e. changes a reader of the diff would immediately see - - REMEMBER: the body will ALWAYS be seen after the commit diff, so DO NOT REPEAT the changes here - - Instead, describe the effects of the changes - - When in doubt, leave it out - - Be more concise for smaller changes, and more descriptive for larger ones. - - Minor or simple changes should definitely not include a body. - - NEVER add speculative explanations. - - Use Markdown format. If there is more than one item, use bullet points: `- `. Separate sections for unrelated sets of - changes with `#` headers - - If the change is substantial, or is made up of many parts, describe them in the body - - If there are several unrelated changes, describe them completely in separate sections - - Do not abstract, hand-wave, or generalize - provide specific details instead - - Surround code references in backticks - - The motivation is often clarity, so no need to mention it. - - Each component must be separated by an empty line. - - # Instructions - Carefully examine the input below. Think step by step, and analyze what changed. There may be changes that are related, and - changes that are unrelated. Carefully consider if there is an non-obvious motivation behind a change or set of changes. - (And never mention "clarity" - that is too obvious.) - - Carefully craft a commit message based on your analysis. Ensure *strict* adherence to the Conventional Commits style, especially - the rule that the first line must be under 49 characters in length. This will be forever immortalized as an immutable git commit - for countless generations, so take some time to pay attention to the details and get it right. - - Remember: the body should only be included for larger changes that needs elaboration. Double-check that your body isn't just - repeating what's in the header description. If it is repeating or rephrasing it, omit the body entirely. Err on the side of - omission: the user will have a chance to explain their own motivations if necessary. - - Use this guidance (if any) to inform the commit message. - - Your output will be piped directly into git -- include only the commit message and omit all commentary. - - $input + Here's the input: $input |