Initial commit

.claude-plugin/plugin.json

@@ -0,0 +1,12 @@
+{
+  "name": "git-commit",
+  "description": "Create well-formatted commit messages for your current work",
+  "version": "1.0.0",
+  "author": {
+    "name": "Vincent Demeester",
+    "email": "vincent@sbr.pm"
+  },
+  "commands": [
+    "./commands"
+  ]
+}

README.md

@@ -0,0 +1,3 @@
+# git-commit
+
+Create well-formatted commit messages for your current work

commands/commit-no-claude.md

@@ -0,0 +1,252 @@
+---
+description: Create a well-formatted commit message for your current work
+---
+
+# Commit Current Work
+
+Review changed files individually and create a concise, conventional commit message.
+
+## Important
+
+- **DO NOT use the Bash tool with echo or any other command-line tools to communicate with the user** - output all communication directly in your response text
+- **Use parallel tool calls** when gathering git information (status, diff, log)
+- **Only commit when user explicitly confirms** - this command is for structured review and commit creation
+- **Do NOT keep committing subsequent work** unless explicitly instructed
+
+---
+
+## Workflow
+
+### Phase 1: Gather Repository Information
+
+**Goal**: Understand current state in parallel
+
+**Actions**:
+
+1. Create a todo list for this workflow:
+   - Phase 1: Gather repository information
+   - Phase 2: Review files individually
+   - Phase 3: Create commit message
+   - Phase 4: Execute commit
+
+2. Run these commands **in parallel** using multiple Bash tool calls:
+   - `git status` - See all untracked files and changes
+   - `git diff --stat` - See summary of changes
+   - `git diff` - See both staged and unstaged changes
+   - `git log -5 --oneline` - See recent commits for style reference
+
+3. Analyze the results:
+   - Current branch name
+   - Files changed (staged, unstaged, untracked)
+   - Nature of changes (new files, modifications, deletions)
+
+4. Present summary:
+   ```
+   Current branch: feature-auth
+
+   Changes:
+   - 3 modified files
+   - 2 new files
+   - ~150 lines changed
+   ```
+
+---
+
+### Phase 2: Review Each File Individually
+
+**Goal**: Ensure all changes are related and understand what changed
+
+**Actions**:
+
+1. For **each changed file**, review the diff and describe:
+   - What changed in this file
+   - Why it's part of this work
+   - Any concerns or notable aspects
+
+2. Present a file-by-file summary:
+   ```
+   Files to commit:
+
+   1. src/auth/login.ts (45 lines)
+      ✓ Added JWT token validation
+      ✓ Implemented login/logout handlers
+      Related: Core auth feature
+
+   2. src/middleware/auth.ts (new file, 32 lines)
+      ✓ Created auth middleware for route protection
+      Related: Core auth feature
+
+   3. tests/auth.test.ts (new file, 73 lines)
+      ✓ Added tests for auth flow
+      Related: Core auth feature
+   ```
+
+3. Ask: "Do these changes look correct for a single commit?"
+
+---
+
+### Phase 3: Create Commit Message
+
+**Goal**: Draft a concise, meaningful commit message
+
+**Actions**:
+
+1. Based on the file review, create a commit message that focuses on **WHY** not just what:
+
+   Format:
+   ```
+   <type>: <short description (max 80 chars)>
+
+   - <bullet point describing impact/reason>
+   - <bullet point describing impact/reason>
+   - <bullet point describing impact/reason>
+   ```
+
+   **Types**: feat, fix, chore, docs, refactor, test, perf, style, ci
+
+2. **Guidelines**:
+   - First line: Clear, concise summary under 80 characters
+   - Bullet points: Focus on "why" and impact, not just "what"
+   - Each bullet: Under 80 characters
+   - 2-4 bullets (not more)
+
+3. **Example** (good):
+   ```
+   feat: Add user authentication system
+
+   - Enable secure user sessions for multi-user support
+   - Prevent unauthorized API access with JWT validation
+   - Establish foundation for role-based permissions
+   ```
+
+4. **Anti-example** (bad - too "what" focused):
+   ```
+   feat: Add auth
+
+   - Added login.ts file
+   - Added middleware
+   - Added tests
+   ```
+
+5. Present the commit message to the user
+
+6. Ask: "Would you like to commit with this message?"
+
+---
+
+### Phase 4: Execute Commit
+
+**Goal**: Create the commit safely
+
+**DO NOT PROCEED WITHOUT USER APPROVAL**
+
+**Actions**:
+
+1. If user approves the commit message:
+
+2. Stage files as needed:
+   - If there are unstaged changes, ask which files to include
+   - Stage approved files: `git add <files>`
+
+3. Create commit with HEREDOC format:
+   ```bash
+   git commit --signoff --message "$(cat <<'EOF'
+   <type>: <title>
+
+   - <bullet 1>
+   - <bullet 2>
+   - <bullet 3>
+   EOF
+   )"
+   ```
+
+4. Verify commit succeeded: `git log -1 --oneline`
+
+5. Mark todo complete
+
+---
+
+### Phase 5: Optional Push
+
+**Goal**: Offer to push if appropriate
+
+**Actions**:
+
+1. Check current branch name from earlier git status
+
+2. **If NOT on main/master**:
+   - Ask: "Would you like to push this commit?"
+   - If yes:
+     - Check if upstream exists: `git rev-parse --abbrev-ref @{u}` (may error if no upstream)
+     - If no upstream: `git push -u origin <branch>`
+     - If upstream exists: `git push`
+
+3. **If on main/master**:
+   - Do NOT offer to push automatically
+   - Inform: "You're on main/master. Push manually if needed: `git push`"
+
+---
+
+## Commit Message Examples
+
+### Feature
+```
+feat: Implement user authentication
+
+- Enable secure multi-user sessions with JWT
+- Prevent unauthorized access to protected routes
+- Lay groundwork for role-based access control
+```
+
+### Bug Fix
+```
+fix: Prevent null pointer in user validation
+
+- Resolve crashes when user object is undefined
+- Ensure defensive checks at API boundaries
+```
+
+### Refactoring
+```
+refactor: Simplify error handling in API layer
+
+- Reduce code duplication across endpoints
+- Improve error message clarity for debugging
+- Make error handling more maintainable
+```
+
+### Chore
+```
+chore: Update dependencies and resolve warnings
+
+- Address security vulnerabilities in npm packages
+- Fix ESLint warnings for cleaner codebase
+```
+
+---
+
+## Error Handling
+
+- **No changes to commit**: Inform user and exit gracefully
+- **User rejects commit message**: Ask if they want to provide their own or cancel
+- **Git command fails**: Show error and ask user to resolve
+- **User cancels**: Exit cleanly without committing
+
+---
+
+## Best Practices
+
+1. **One concern per commit**: If files address different concerns, suggest splitting into multiple commits
+2. **Focus on "why"**: Commit messages should explain impact and reasoning, not just what changed
+3. **Use conventional commits**: Helps with changelog generation and understanding history
+4. **Keep it concise**: Respect 80-character limits for readability in git log
+5. **Review individually**: Understand each file's changes before committing
+
+---
+
+## Notes
+
+- This command uses TodoWrite to track progress - you'll see phases marked as you go
+- Parallel git commands run faster and use fewer tokens
+- The commit format includes Claude Code attribution automatically
+- Only commit when the user explicitly confirms

commands/commit.md

@@ -0,0 +1,254 @@
+---
+description: Create a well-formatted commit message for your current work
+---
+
+# Commit Current Work
+
+Review changed files individually and create a concise, conventional commit message.
+
+## Important
+
+- **DO NOT use the Bash tool with echo or any other command-line tools to communicate with the user** - output all communication directly in your response text
+- **Use parallel tool calls** when gathering git information (status, diff, log)
+- **Only commit when user explicitly confirms** - this command is for structured review and commit creation
+- **Do NOT keep committing subsequent work** unless explicitly instructed
+
+---
+
+## Workflow
+
+### Phase 1: Gather Repository Information
+
+**Goal**: Understand current state in parallel
+
+**Actions**:
+
+1. Create a todo list for this workflow:
+   - Phase 1: Gather repository information
+   - Phase 2: Review files individually
+   - Phase 3: Create commit message
+   - Phase 4: Execute commit
+
+2. Run these commands **in parallel** using multiple Bash tool calls:
+   - `git status` - See all untracked files and changes
+   - `git diff --stat` - See summary of changes
+   - `git diff` - See both staged and unstaged changes
+   - `git log -5 --oneline` - See recent commits for style reference
+
+3. Analyze the results:
+   - Current branch name
+   - Files changed (staged, unstaged, untracked)
+   - Nature of changes (new files, modifications, deletions)
+
+4. Present summary:
+   ```
+   Current branch: feature-auth
+
+   Changes:
+   - 3 modified files
+   - 2 new files
+   - ~150 lines changed
+   ```
+
+---
+
+### Phase 2: Review Each File Individually
+
+**Goal**: Ensure all changes are related and understand what changed
+
+**Actions**:
+
+1. For **each changed file**, review the diff and describe:
+   - What changed in this file
+   - Why it's part of this work
+   - Any concerns or notable aspects
+
+2. Present a file-by-file summary:
+   ```
+   Files to commit:
+
+   1. src/auth/login.ts (45 lines)
+      ✓ Added JWT token validation
+      ✓ Implemented login/logout handlers
+      Related: Core auth feature
+
+   2. src/middleware/auth.ts (new file, 32 lines)
+      ✓ Created auth middleware for route protection
+      Related: Core auth feature
+
+   3. tests/auth.test.ts (new file, 73 lines)
+      ✓ Added tests for auth flow
+      Related: Core auth feature
+   ```
+
+3. Ask: "Do these changes look correct for a single commit?"
+
+---
+
+### Phase 3: Create Commit Message
+
+**Goal**: Draft a concise, meaningful commit message
+
+**Actions**:
+
+1. Based on the file review, create a commit message that focuses on **WHY** not just what:
+
+   Format:
+   ```
+   <type>: <short description (max 80 chars)>
+
+   - <bullet point describing impact/reason>
+   - <bullet point describing impact/reason>
+   - <bullet point describing impact/reason>
+   ```
+
+   **Types**: feat, fix, chore, docs, refactor, test, perf, style, ci
+
+2. **Guidelines**:
+   - First line: Clear, concise summary under 80 characters
+   - Bullet points: Focus on "why" and impact, not just "what"
+   - Each bullet: Under 80 characters
+   - 2-3 bullets (not more)
+
+3. **Example** (good):
+   ```
+   feat: Add user authentication system
+
+   - Enable secure user sessions for multi-user support
+   - Prevent unauthorized API access with JWT validation
+   - Establish foundation for role-based permissions
+   ```
+
+4. **Anti-example** (bad - too "what" focused):
+   ```
+   feat: Add auth
+
+   - Added login.ts file
+   - Added middleware
+   - Added tests
+   ```
+
+5. Present the commit message to the user
+
+6. Ask: "Would you like to commit with this message?"
+
+---
+
+### Phase 4: Execute Commit
+
+**Goal**: Create the commit safely
+
+**DO NOT PROCEED WITHOUT USER APPROVAL**
+
+**Actions**:
+
+1. If user approves the commit message:
+
+2. Stage files as needed:
+   - If there are unstaged changes, ask which files to include
+   - Stage approved files: `git add <files>`
+
+3. Create commit with HEREDOC format:
+   ```bash
+   git commit --signoff --message "$(cat <<'EOF'
+   <type>: <title>
+
+   - <bullet 1>
+   - <bullet 2>
+   - <bullet 3>
+
+   Co-Authored-By: Claude <noreply@anthropic.com>
+   EOF
+   )"
+   ```
+
+4. Verify commit succeeded: `git log -1 --oneline`
+
+5. Mark todo complete
+
+---
+
+### Phase 5: Optional Push
+
+**Goal**: Offer to push if appropriate
+
+**Actions**:
+
+1. Check current branch name from earlier git status
+
+2. **If NOT on main/master**:
+   - Ask: "Would you like to push this commit?"
+   - If yes:
+     - Check if upstream exists: `git rev-parse --abbrev-ref @{u}` (may error if no upstream)
+     - If no upstream: `git push -u origin <branch>`
+     - If upstream exists: `git push`
+
+3. **If on main/master**:
+   - Do NOT offer to push automatically
+   - Inform: "You're on main/master. Push manually if needed: `git push`"
+
+---
+
+## Commit Message Examples
+
+### Feature
+```
+feat: Implement user authentication
+
+- Enable secure multi-user sessions with JWT
+- Prevent unauthorized access to protected routes
+- Lay groundwork for role-based access control
+```
+
+### Bug Fix
+```
+fix: Prevent null pointer in user validation
+
+- Resolve crashes when user object is undefined
+- Ensure defensive checks at API boundaries
+```
+
+### Refactoring
+```
+refactor: Simplify error handling in API layer
+
+- Reduce code duplication across endpoints
+- Improve error message clarity for debugging
+- Make error handling more maintainable
+```
+
+### Chore
+```
+chore: Update dependencies and resolve warnings
+
+- Address security vulnerabilities in npm packages
+- Fix ESLint warnings for cleaner codebase
+```
+
+---
+
+## Error Handling
+
+- **No changes to commit**: Inform user and exit gracefully
+- **User rejects commit message**: Ask if they want to provide their own or cancel
+- **Git command fails**: Show error and ask user to resolve
+- **User cancels**: Exit cleanly without committing
+
+---
+
+## Best Practices
+
+1. **One concern per commit**: If files address different concerns, suggest splitting into multiple commits
+2. **Focus on "why"**: Commit messages should explain impact and reasoning, not just what changed
+3. **Use conventional commits**: Helps with changelog generation and understanding history
+4. **Keep it concise**: Respect 80-character limits for readability in git log
+5. **Review individually**: Understand each file's changes before committing
+
+---
+
+## Notes
+
+- This command uses TodoWrite to track progress - you'll see phases marked as you go
+- Parallel git commands run faster and use fewer tokens
+- The commit format includes Claude Code attribution automatically
+- Only commit when the user explicitly confirms

plugin.lock.json

@@ -0,0 +1,49 @@
+{
+  "$schema": "internal://schemas/plugin.lock.v1.json",
+  "pluginId": "gh:vdemeester/claude-code-plugins:plugins/git-commit",
+  "normalized": {
+    "repo": null,
+    "ref": "refs/tags/v20251128.0",
+    "commit": "b0c0de45bac1b873e4f8d3a8590817da86643628",
+    "treeHash": "d70ea3b7b66ef3e2860468eec2505fc9df24a786e5adfb2abb526acdf8e0b065",
+    "generatedAt": "2025-11-28T10:28:53.690010Z",
+    "toolVersion": "publish_plugins.py@0.2.0"
+  },
+  "origin": {
+    "remote": "git@github.com:zhongweili/42plugin-data.git",
+    "branch": "master",
+    "commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
+    "repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
+  },
+  "manifest": {
+    "name": "git-commit",
+    "description": "Create well-formatted commit messages for your current work",
+    "version": "1.0.0"
+  },
+  "content": {
+    "files": [
+      {
+        "path": "README.md",
+        "sha256": "bea7f4597e8b1b55d617a4f8bfe1ab04332fabf1b59ed09d3d3e260fbb4c0942"
+      },
+      {
+        "path": ".claude-plugin/plugin.json",
+        "sha256": "3bc7fbcbf179ca6a430cd0d0643068ad9017aa8d54d1fc8b85e1aee301c7a080"
+      },
+      {
+        "path": "commands/commit-no-claude.md",
+        "sha256": "2ea9a9a87a17673b8b4796b8889d6bb673a2f9b721415fb18652c5125b43dbf9"
+      },
+      {
+        "path": "commands/commit.md",
+        "sha256": "5e1d6e7e89facc102dec01212f1cdaf201e66f8e0ad3c57056953fbfb3f97b38"
+      }
+    ],
+    "dirSha256": "d70ea3b7b66ef3e2860468eec2505fc9df24a786e5adfb2abb526acdf8e0b065"
+  },
+  "security": {
+    "scannedAt": null,
+    "scannerVersion": null,
+    "flags": []
+  }
+}