An attempt of a "good commit" message prompt.

v3_commit.txt

You will be analyzing a git diff and generating a well-structured commit message following conventional commit guidelines. 

Here is the git diff to analyze:

<git_diff>
</git_diff>

Here is additional context about the change:

<context>
</context>

Your task is to generate a professional commit message that follows best practices. The commit message should help reviewers and future maintainers understand what changed, why it changed, and what impact it has.

To create an effective commit message, consider these guiding questions:

1. **What is the high-level purpose of the change?** What problem does this diff solve, or what new capability does it add?

2. **What kind of change is it?** Pick the most appropriate type:
   - **feat** – new feature / user-visible functionality
   - **fix** – bug correction / regression fix
   - **docs** – documentation only
   - **style** – formatting, whitespace, lint fixes (no code change)
   - **refactor** – internal restructuring, no functional change
   - **perf** – performance improvement
   - **test** – adding/changing tests only
   - **chore** – build, CI, tooling, or other maintenance

3. **Which part(s) of the codebase are affected?** Component, module, package, or file pattern.

4. **Are there any external references to include?** Issue/PR numbers, ticket IDs, JIRA keys, or design doc links.

5. **Does the change alter the public API or behavior?** Is this a breaking change? If so, what compatibility notes should be added?

6. **What is the expected impact for users or downstream services?** New endpoints, changed response formats, UI tweaks, performance gains, etc.

7. **Were any side-effects introduced that need to be documented?** Database migrations, config defaults, environment variables, feature flags.

8. **What testing was added or updated?** Unit/Integration/E2E tests, test coverage impact, manual verification steps.

9. **Any "why" details that aren't obvious from the diff?** Motivation, design decisions, trade-offs, known limitations.

10. **Do you need a body or footer in the commit message?** Longer explanations, "BREAKING CHANGE:" notes, "Co-authored-by", "Signed-off-by", etc.

Before writing the commit message, verify it meets these criteria:

1. **Problem Statement** – Opens with a clear description of the issue being addressed
2. **Self-Containment** – Can stand alone without depending on external documents
3. **Rationale Over Mechanics** – Explains *why* the change is necessary, not just *what* changed
4. **Subject Line** – Succinct (under 50 characters), summarizes the change, names the affected component
5. **Contextual Detail** – Provides enough background for reviewers to understand without diving into code
6. **Atomicity Check** – Ensures the commit doesn't bundle unrelated changes
7. **Relevance Information** – Includes details that help reviewers assess pertinence
8. **Limitations & Future Work** – Notes any known constraints or planned enhancements
9. **Test Plan** – Lists automated and/or manual tests performed
10. **No Patch-Set Noise** – Removes comments specific to particular patch sets
11. **Completeness** – Contains all information needed for full understanding

Follow these formatting guidelines:

- **Subject line**: Start with type(scope): followed by a brief summary in imperative mood
- Keep the subject line under 50 characters (72 character hard limit)
- Do not end the subject line with a period
- Capitalize the subject line and each paragraph
- Use imperative mood: "Add feature" not "Added feature" or "Adds feature"
- Separate subject from body with a blank line
- Wrap body text at 72 characters
- Use the body to explain what and why, not how
- Include bullet points where appropriate (use - or * with hanging indent)
- Add relevant references (Closes #123, Fixes #456, etc.)
- Include "BREAKING CHANGE:" footer if the change breaks compatibility

Use your scratchpad to analyze the diff and context before writing the final commit message.

<scratchpad>
In your scratchpad:
1. Analyze the git diff to understand what files changed and how
2. Identify the type of change (feat, fix, refactor, etc.)
3. Determine the scope/component affected
4. Extract the core purpose and motivation
5. Note any breaking changes, side effects, or important details
6. Consider what testing information should be included
7. Draft the subject line (type(scope): summary)
8. Draft the body paragraphs explaining why and what impact
9. Add any necessary footers (references, breaking changes, etc.)
</scratchpad>

After your analysis, write the final commit message inside <commit_message> tags. The commit message should be ready to use as-is, properly formatted with subject line, body (if needed), and footer (if needed).

Your final output should contain only the commit message in the specified tags, not the scratchpad analysis.