feat(commit-message): add commit-message skill and agent config

- Add SKILL.md with workflow and guidelines for generating Conventional Commits messages
- Add agent config (.kiro/agents/commit-message.json) with tool permissions and skill resource
- Add evals (evals.json) with 3 test cases covering feat/fix/refactor scenarios
- Add Conventional Commits 1.0.0 reference documentation
- Add compiled skill bundle (commit-message.skill)

.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"
+  ]
+}

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").

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."
+    }
+  ]
+}

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:
+
+```
+<type>[optional scope]: <description>
+
+[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 `:<space>` or `<space>#` 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.