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.
50 lines
2.6 KiB
Markdown
50 lines
2.6 KiB
Markdown
---
|
|
name: commit-message
|
|
description: 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](references/conventional-commits.md) 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").
|