Feature: Implement Expert Git Commit Agent Skill (#22)

# Summary

This PR introduces a specialized Agent Skill named `git-commit` to
provide a streamlined,standardized, and safe way to generate
high-quality commit messages within the Gemini CLI.

Previously, users had to manually prompt for commit suggestions, which
often resulted in output containing Markdown backticks. Since the Gemini
CLI interprets backticks as bash commands, this posed a significant
security risk and led to unintended command executions or shell errors.

This change implements a robust "No Backticks" policy across both the
new Agent Skill and the existing `/git:commit` command, ensuring all
output is strictly raw text or uses single quotes for references.

### Changes Made

- **New Git Commit Skill:** Created `skills/gitcommit/SKILL.md` to
define the expert commit agent,
   including a structured workflow for analyzing staged changes.
- **Commit Standards Documentation:** Added
`skills/gitcommit/references/commit-standards.md` which provides
detailed rules for Conventional Commits (types, scope detection, and
formatting).
- **Security Hardening:** Updated `commands/git/commit.toml` with
critical instructions to strictly forbid the use of backticks in
generated subjects and bodies, mandating single quotes instead.
- **Feature Documentation:** Updated `README.md` to highlight
Conventional Commits support, the "Safety First" backtick prevention,
and context awareness.
- **Version Bump:** Incremented the extension version to `0.2.0` in
`gemini-extension.json` to reflect the new functionality.
 
## Related Issues

Closes #21

## Type of Change

Please select the type of change that applies to this PR:

- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Refactor (code change that neither fixes a bug nor adds a feature)
- [x] Documentation (changes to documentation)
- [ ] Breaking change (fix or feature that would cause existing
functionality to not work as expected)
- [x] Chore (maintenance tasks, build process, etc.)

## Checklist

- [x] I have performed a self-review of my own code.
- [x] I have updated the documentation accordingly.
- [x] My changes generate no new warnings.

## Screenshots/Video

 N/A

Author: samucodesh

README.md

@@ -6,9 +6,11 @@ descriptive body to keep your project history clear and concise.
 
 ## Features
 
-- **Automated Analysis:** Inspects your Git staging area to understand code changes.
-- **Smart Generation:** Produces an AI-generated title and description based on the context of your work.
-- **Seamless Integration:** Adds a custom command directly into your Gemini CLI workflow.
+- **Conventional Commits:** Automatically generates messages following the industry-standard [Conventional Commits](https://www.conventionalcommits.org/) specification.
+- **Safety First (No Backticks):** Guarantees output without backticks (`), preventing the Gemini CLI from incorrectly identifying messages as bash commands.
+- **Context Awareness:** Automatically activates when you ask to "commit this," "write a commit message," or similar requests.
+- **Automated Analysis:** Inspects your Git staging area to understand code changes and provide meaningful context.
+- **Seamless Integration:** Adds both an Agent Skill and a custom command directly into your Gemini CLI workflow.
 
 ## Installation
 

commands/git/commit.toml

@@ -1,4 +1,4 @@
-# In: .gemini/commands/git/commit.toml
+# In: commands/git/commit.toml
 # Invoked via: /git:commit
 
 description = "Generates a Git commit message (title and body) based on staged changes."
@@ -49,13 +49,15 @@ Analyze the provided code changes (`git diff`) and generate a complete commit me
     *   Write in the **imperative mood** (e.g., "add", "fix", "change" not "added", "fixed").
     *   Begin with a lowercase letter.
     *   Do not end with a period.
+    *   **CRITICAL: Never include backticks (`) in the output.**
     </subject>
 
     <body_formatting>
     *   Separate from the subject with a blank line.
     *   Explain the **intent** and **reasoning**. Answer "why" you are making the change, not just "what" you changed.
     *   **Lists:** If the commit includes multiple distinct logical changes, use a bulleted list (using `-`) to detail them for better readability.
     *   Wrap the body at 72 characters per line.
+    *   **CRITICAL: Never include backticks (`) in the output. Use single quotes (') instead if needed.**
     </body_formatting>
 
     <breaking_changes>

gemini-extension.json

@@ -1,6 +1,6 @@
 {
     "name": "geminicli-gitcommit",
-    "version": "0.1.1",
+    "version": "0.2.0",
     "excludeTools": [],
     "tools": ["list_directory", "search_file_content", "read_file", "glob", "replace", "run_shell_command", "save_memory"],
     "model": "flash",

skills/gitcommit/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: git-commit
+description: Expert Git commit message generation following Conventional Commits. Use when the user wants to commit changes, needs help writing a commit message, or asks to "commit this".
+---
+
+# Git Commit Generator
+
+This skill transforms staged changes into professional, meaningful commit messages.
+
+## Workflow
+
+1.  **Analyze Staged Changes**: Use `git diff --staged` to understand the code changes.
+2.  **Apply Standards**: Follow the detailed rules in [references/commit-standards.md](references/commit-standards.md).
+3.  **Generate Output**: Produce a commit command that the user can run.
+
+## Guidelines
+
+- **Context First**: Always read the diff before proposing a message.
+- **No Backticks**: **CRITICAL**: Never include backticks (`) in the commit message or any part of the output. Gemini CLI interprets backticks as shell commands.
+- **Why over What**: Prioritize the reasoning behind the change in the message body.
+- **Breaking Changes**: Be extremely vigilant about breaking changes and document them in the footer as per the standards.
+
+## Example Usage
+
+When a user says "Commit these changes", you should:
+1. Run `git diff --staged`.
+2. Review the output.
+3. Construct the message following the standards.
+4. Output the final `git commit` command for the user.

skills/gitcommit/references/commit-standards.md

@@ -0,0 +1,47 @@
+# Conventional Commit Standards
+
+## Structure
+```
+<type>(<scope>): <concise subject>
+
+<body explaining the "why" of the change>
+
+<footer for BREAKING CHANGES or issue references>
+```
+
+## Mandatory 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, 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 (e.g., npm, make).
+*   **ci**: Changes to our CI configuration files and scripts (e.g., GitHub Actions).
+*   **chore**: Other changes that don't modify source or test files (e.g., updating `.gitignore`).
+
+## Scope Detection
+*   **Infer Scope:** Look at file paths.
+    *   If changes are isolated (e.g., `src/auth/`, `lib/utils.ts`), use that as scope (e.g., `auth`, `utils`).
+    *   If changes are global or spread across many modules, omit the scope.
+
+## Subject Rules
+*   Max 50 characters.
+*   Use **imperative mood** (e.g., "add", "fix", "change").
+*   Lowercase start, no trailing period.
+*   **NO BACKTICKS**: Never use backticks (`) in the subject.
+
+## Body Formatting
+*   Blank line after subject.
+*   Explain **intent** and **reasoning** ("why", not just "what").
+*   Use bulleted lists (`-`) for multiple distinct changes.
+*   Wrap at 72 characters.
+*   **NO BACKTICKS**: Never use backticks (`) in the body. Use single quotes (') instead if needed.
+
+## Breaking Changes
+*   **Detection:** Look for removal of public API, signature changes, or incompatible config changes.
+*   **Format:** Footer MUST start with `BREAKING CHANGE:` followed by description and migration instructions.
+
+## Footer
+*   Reference issues using `Closes: #`.