Team
21a530484d
Updated SKILL.md to reflect new commit message convention using uppercase types wrapped in brackets. Changed format from conventional lowercase `type(scope): description` to `[TYPE](scope) description` format. Updated examples and breaking change notation to use `[FEAT!]`/`[FIX!]` syntax with exclamation inside brackets.
2.6 KiB
name, description
| name | description |
|---|---|
| commit-message | Generates high-quality, professional git commit messages following Conventional Commits standards. Use when the user wants to commit changes, needs a suggestion for a commit message, or is ready to wrap up a task. |
Commit Message
Overview
This skill helps you generate professional git commit messages that adhere to the Conventional Commits specification. It automates the analysis of staged changes and provides a structured message that captures the intent and impact of the work.
Workflow
1. Identify Staged Changes
Run git status to identify which files are staged for commit. If no files are staged, inform the user and ask if they would like to stage specific files.
2. Analyze Diffs
Run git diff --cached to analyze the actual changes in the staged files. For large diffs, focus on the most significant changes or summarize by file.
3. Draft the Message
Apply the Conventional Commits standard to draft the message, using uppercase type wrapped in brackets.
Format: [TYPE] description or [TYPE](scope) description
- Type: Choose the most appropriate type and write it UPPERCASE in brackets:
[FEAT],[FIX],[DOCS],[STYLE],[REFACTOR],[PERF],[TEST],[BUILD],[CI],[CHORE],[REVERT]. - Scope: (Optional) Add a scope in parentheses after the type bracket:
[FEAT](auth). - Description: Write a concise, imperative-mood summary of the change.
- Body: (Optional) Provide a more detailed explanation if the changes are complex or require context.
- Breaking Changes: Note with
[FEAT!]or[FIX!](exclamation inside the bracket) and explain in the body.
4. Present and Refine
Present the drafted message to the user. Ask if they would like to use it as-is, make adjustments, or if they want a different version.
Examples
Request: "Commit these changes"
Response: "I see you have staged changes in src/auth.ts and src/user.ts. I've analyzed the diff and suggest the following commit message:
[FEAT](auth) add JWT-based session management
Would you like me to commit with this message?"
Request: "Give me a commit message for my work"
Response: "Based on your changes in docs/api.md, I suggest:
[DOCS] update API endpoints for user registration
Does this look good to you?"
Guidelines
- Imperative Mood: Use "add", "fix", "update" instead of "added", "fixed", "updates".
- Conciseness: Keep the first line (header) under 50-72 characters if possible.
- Context: Use the commit body for "why" rather than "what" (the diff shows "what").