Skip to content

[Feature]: make the git commit better with system prompt of how to commit #1181

@seifalmotaz

Description

@seifalmotaz

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I am describing a concrete problem or use case, not just a vague idea.

Area

apps/server

Problem or use case

When creating commits, the messages are often very general and raw, lacking the structured format that professional engineers use. They don’t follow conventions like feat, chore, refactor, style, or test prefixes, nor do they reflect technical changes or PM-style review notes.

Proposed solution

add system prompt wth the generate git commit fnction with clear guid of how to create and write a commit

You are a commit message generator. Your role is to produce clear, professional, and standardized commit messages following conventional commit guidelines.

Guidelines:
1. **Commit Type Prefixes**  
   - `feat`: A new feature  
   - `fix`: A bug fix  
   - `chore`: Maintenance tasks (dependencies, configs)  
   - `refactor`: Code restructuring without changing behavior  
   - `style`: Formatting, whitespace, or non-functional changes  
   - `test`: Adding or modifying tests  
   - `docs`: Documentation updates  

2. **Scope (optional)**  
   - Defines the area of the codebase affected (e.g., `auth`, `payment`, `ui`).  
   - Example: `feat(auth): add JWT validation`

3. **Description**  
   - Use imperative mood (“add”, “fix”, “update”)  
   - Be concise but descriptive  
   - Avoid vague terms like “stuff”, “changes”, “update”  

4. **Extended Body (optional)**  
   - Explain *why* the change was made, not just *what*  
   - Include context, trade-offs, or references to issues/tickets  

5. **Examples**  
   - `feat(payment): support multi-currency transactions`  
   - `fix(ui): resolve button alignment issue on mobile`  
   - `docs(readme): update installation instructions`  
   - `test(api): add unit tests for order service`  

Output Format:
- Always return commit messages in the form:  
  `<type>(<scope>): <short description>`  
- If body is needed, add after a blank line.

Why this matters

This matters because commit messages are not just a formality — they’re the communication layer of your codebase. When commits are written in a raw, unstructured way, they lose their value as a historical record and make collaboration harder. Here’s why adopting proper conventions (like feat, fix, chore, refactor, etc.) is important.

Why Structured Commit Messages Matter

  • Clarity for the team: A well-written commit immediately tells others what changed and why. Raw text like “update stuff” forces teammates to dig into diffs instead of understanding at a glance.

  • Project history as documentation: The commit log becomes a living changelog. With proper prefixes, you can trace features, bug fixes, and refactors without needing external notes.

  • Automation & tooling: Many CI/CD pipelines, release tools, and changelog generators rely on conventional commit formats. Without them, automation breaks or produces noisy results.

  • Professionalism & consistency: Engineers are expected to communicate changes in a structured way. It shows discipline and makes onboarding new developers smoother.

  • PM & review alignment: Prefixes and scopes help non-technical stakeholders (like PMs) quickly understand the nature of changes — whether it’s a new feature, a bug fix, or just maintenance.

Smallest useful scope

just add simple simple couple of line before the changes like

generate a commit message like Staff Software Engineer will do <type>(<scope>): <short description>

Alternatives considered

No response

Risks or tradeoffs

No response

Examples or references

like the windsurf commit auto commit messages tool

Contribution

  • I would be open to helping implement this.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementRequested improvement or new capability.needs-triageIssue needs maintainer review and initial categorization.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions