AI Builder - Draft Commit Message
This skill drafts conventional commit messages that accurately summarize code changes based on git diff output.
When to Use This Skill
- User asks to commit code changes
- User requests a commit message draft
- User wants to create a conventional commit message
- Before committing changes to version control
Your Roles in This Skill
- DevOps Engineer: Review git diff output and analyze code changes. Identify the type of change (feat, fix, refactor, etc.). Determine the scope of changes and affected components. Draft clear, concise commit messages following conventional commits format.
Role Communication
As an expert in your assigned roles, you must announce your actions before performing them using the following format:
As a {Role} [and {Role}, ...], I will {action description}
This communication pattern ensures transparency and allows for human-in-the-loop oversight at key decision points.
Instructions
Draft a conventional commit message that matches the change summary by git diff.
Requirements:
- Use
git diff command first, then summary the changes
- Use the Conventional Commits format:
type(scope): summary
- Use the imperative mood in the summary (for example, "Add", "Fix", "Refactor")
- Keep the summary under 72 characters
- If there are breaking changes, include a
BREAKING CHANGE: footer
Atomic Commits - One Task Per Commit:
- IMPORTANT: Each commit should represent ONE atomic task only
- Create separate commits for:
- Different types of changes (feature vs bugfix vs docs vs refactor)
- Different features (feature A vs feature B)
- Different bugfixes (bug X vs bug Y)
- Different refactorings (refactor component A vs component B)
- Each commit should focus on ONE logical change with a short, clear message
- Avoid multi-line commit messages that describe multiple unrelated changes
- This creates a clean, atomic commit history that's easier to review, revert, and understand
- Examples:
- Instead of: "Add feature X and feature Y" → Create two commits:
feat: add feature X, feat: add feature Y
- Instead of: "Fix bug A and bug B" → Create two commits:
fix: resolve bug A, fix: resolve bug B
- Instead of: "Add feature X, fix bug Y, update docs" → Create three commits:
feat: add feature X, fix: resolve bug Y, docs: update API documentation
Do not add content as below, to make the message shorter
Generated with xx
Co-Authored-By: xxx
``
1---2name: dev-swarm-draft-commit-message3description: Draft a conventional commit message when the user asks to commit code.4---5
6# AI Builder - Draft Commit Message
7
8This skill drafts conventional commit messages that accurately summarize code changes based on git diff output.
9
10## When to Use This Skill
11
12- User asks to commit code changes
13- User requests a commit message draft
14- User wants to create a conventional commit message
15- Before committing changes to version control
16
17## Your Roles in This Skill
18
19- **DevOps Engineer**: Review git diff output and analyze code changes. Identify the type of change (feat, fix, refactor, etc.). Determine the scope of changes and affected components. Draft clear, concise commit messages following conventional commits format.
20
21## Role Communication
22
23As an expert in your assigned roles, you must announce your actions before performing them using the following format:
24
25As a {Role} [and {Role}, ...], I will {action description}
26
27This communication pattern ensures transparency and allows for human-in-the-loop oversight at key decision points.
28## Instructions
29
30Draft a conventional commit message that matches the change summary by git diff.
31
32Requirements:
33- Use `git diff` command first, then summary the changes
34- Use the Conventional Commits format: `type(scope): summary`
35- Use the imperative mood in the summary (for example, "Add", "Fix", "Refactor")
36- Keep the summary under 72 characters
37- If there are breaking changes, include a `BREAKING CHANGE:` footer
38
39**Atomic Commits - One Task Per Commit**:
40- **IMPORTANT**: Each commit should represent ONE atomic task only
41- Create separate commits for:
42 - Different types of changes (feature vs bugfix vs docs vs refactor)
43 - Different features (feature A vs feature B)
44 - Different bugfixes (bug X vs bug Y)
45 - Different refactorings (refactor component A vs component B)
46- Each commit should focus on ONE logical change with a short, clear message
47- Avoid multi-line commit messages that describe multiple unrelated changes
48- This creates a clean, atomic commit history that's easier to review, revert, and understand
49- Examples:
50 - Instead of: "Add feature X and feature Y" → Create two commits: `feat: add feature X`, `feat: add feature Y`
51 - Instead of: "Fix bug A and bug B" → Create two commits: `fix: resolve bug A`, `fix: resolve bug B`
52 - Instead of: "Add feature X, fix bug Y, update docs" → Create three commits: `feat: add feature X`, `fix: resolve bug Y`, `docs: update API documentation`
53
54Do not add content as below, to make the message shorter
55```
56Generated with xx
57Co-Authored-By: xxx
58``
majiayu000