-
Notifications
You must be signed in to change notification settings - Fork 894
Description
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.