From 21a530484d1c5e45e3798223efb2f3889f1a3bbf Mon Sep 17 00:00:00 2001 From: Team Date: Sat, 25 Apr 2026 18:39:15 +0800 Subject: [PATCH] docs(commit-message): update commit message format to use uppercase bracket notation 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. --- skills/commit-message/SKILL.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/skills/commit-message/SKILL.md b/skills/commit-message/SKILL.md index 8d3346a..34d887d 100644 --- a/skills/commit-message/SKILL.md +++ b/skills/commit-message/SKILL.md @@ -18,13 +18,15 @@ Run `git status` to identify which files are staged for commit. If no files are 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. +Apply the [Conventional Commits](references/conventional-commits.md) standard to draft the message, using uppercase type wrapped in brackets. -- **Type**: Choose the most appropriate type (feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert). -- **Scope**: (Optional) Add a scope if the change is localized to a specific module or component. +**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**: Explicitly note any breaking changes in the footer or with a `!` in the prefix. +- **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. @@ -33,12 +35,12 @@ Present the drafted message to the user. Ask if they would like to use it as-is, ### 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` +`[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` +`[DOCS] update API endpoints for user registration` Does this look good to you?" ## Guidelines