diff --git a/.kiro/agents/commit-message.json b/.kiro/agents/commit-message.json new file mode 100644 index 0000000..96d48ef --- /dev/null +++ b/.kiro/agents/commit-message.json @@ -0,0 +1,10 @@ +{ + "name": "commit-message", + "description": "Agent specializing in generating Conventional Commits messages.", + "prompt": "You are an expert at generating git commit messages following the Conventional Commits 1.0.0 specification. Your goal is to analyze staged changes and provide a high-quality, professional commit message. Always use the `commit-message` skill for guidance.", + "tools": ["fs_read", "execute_bash", "grep", "glob"], + "allowedTools": ["fs_read", "execute_bash", "grep", "glob"], + "resources": [ + "skill://skills/commit-message/SKILL.md" + ] +} diff --git a/commit-message.skill b/commit-message.skill new file mode 100644 index 0000000..25cdbac Binary files /dev/null and b/commit-message.skill differ diff --git a/skills/commit-message/SKILL.md b/skills/commit-message/SKILL.md new file mode 100644 index 0000000..8d3346a --- /dev/null +++ b/skills/commit-message/SKILL.md @@ -0,0 +1,47 @@ +--- +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. + +- **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. +- **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. + +### 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"). diff --git a/skills/commit-message/evals/evals.json b/skills/commit-message/evals/evals.json new file mode 100644 index 0000000..e72c440 --- /dev/null +++ b/skills/commit-message/evals/evals.json @@ -0,0 +1,20 @@ +{ + "skill_name": "commit-message", + "evals": [ + { + "id": 1, + "prompt": "Commit the changes in src/auth.ts where I added JWT logic.", + "expected_output": "Suggests a feat(auth) or similar Conventional Commit message, uses imperative mood (e.g., 'add JWT authentication logic')." + }, + { + "id": 2, + "prompt": "What's the commit message for fixing a typo in the README?", + "expected_output": "Suggests 'docs: fix typo in README' or similar." + }, + { + "id": 3, + "prompt": "I refactored the database connection pool. What's a good commit message?", + "expected_output": "Suggests 'refactor: refactor database connection pool' or similar, mentions it's a refactor type." + } + ] +} diff --git a/skills/commit-message/references/conventional-commits.md b/skills/commit-message/references/conventional-commits.md new file mode 100644 index 0000000..73727ad --- /dev/null +++ b/skills/commit-message/references/conventional-commits.md @@ -0,0 +1,46 @@ +# Conventional Commits 1.0.0 + +The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with [SemVer](http://semver.org), by describing the features, fixes, and breaking changes made in commit messages. + +The commit message should be structured as follows: + +``` +[optional scope]: + +[optional body] + +[optional footer(s)] +``` + +## Types + +- **feat**: A new feature +- **fix**: A bug fix +- **docs**: Documentation only changes +- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) +- **refactor**: A code change that neither fixes a bug nor adds a feature +- **perf**: A code change that improves performance +- **test**: Adding missing tests or correcting existing tests +- **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) +- **ci**: Changes to our CI configuration files and scripts (example scopes: GitHub Actions, Travis, Circle, BrowserStack, SauceLabs) +- **chore**: Other changes that don't modify src or test files +- **revert**: Reverts a previous commit + +## Rules + +1. Commits MUST be prefixed with a type (feat, fix, etc.), followed by an optional scope, and a REQUIRED terminal colon and space. +2. The type feat MUST be used when a commit adds a new feature to your application or library. +3. The type fix MUST be used when a commit represents a bug fix for your application. +4. An optional scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., `fix(parser):` +5. A description MUST immediately follow the colon and space after the type/scope prefix. The description is a short summary of the code changes, e.g., `fix: array parsing issue when multiple spaces were contained in string`. +6. A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description. +7. A commit body is free-form and MAY consist of any number of new-line separated paragraphs. +8. One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a `:` or `#` separator, followed by a string value (this is inspired by the git trailer convention). +9. A footer’s token MUST use `-` in place of whitespace characters, e.g., `Acked-by` (this helps differentiate the footer from a multi-paragraph body). An exception is made for `BREAKING CHANGE`, which MAY also be used as a token. +10. A footer’s value MAY contain whitespace and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed. +11. Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer. +12. If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., `BREAKING CHANGE: environment variables now take precedence over config files`. +13. If included in the type/scope prefix, breaking changes MUST be indicated by a `!` immediately before the `:`. If `!` is used, `BREAKING CHANGE:` MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change. +14. Types other than feat and fix MAY be used in your commit messages, e.g., `docs: updated ref docs`. +15. The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementers, with the exception of BREAKING CHANGE which MUST be uppercase. +16. BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.