Initial commit

.claude-plugin/plugin.json

@@ -0,0 +1,14 @@
+{
+  "name": "git-workflow",
+  "description": "Git and GitHub workflow commands for commits and pull requests",
+  "version": "1.0.0",
+  "author": {
+    "name": "David Lopes"
+  },
+  "skills": [
+    "./skills"
+  ],
+  "commands": [
+    "./commands"
+  ]
+}

README.md

@@ -0,0 +1,3 @@
+# git-workflow
+
+Git and GitHub workflow commands for commits and pull requests

commands/commit.md

@@ -0,0 +1,39 @@
+---
+name: commit
+description: Create git commits with user approval and no Claude attribution
+---
+
+# Committing Work
+
+## Overview
+
+**Core principle:** Analyze changes → Plan commits → Execute.
+
+## The Process
+**IMPORTANT:** use skill `committing-work` to learn how to draft good commit messages and how to organize commits.
+
+### Step 1: Think about what changed
+
+1. Review the conversation history and understand what was accomplished
+2. Run `git status` to see current changes
+3. Run `git diff` to understand the modifications
+4. Consider whether changes should be one commit or multiple logical commits
+
+### Step 2: Plan your commit(s)
+
+1. Identify which files belong together
+2. Draft clear, descriptive commit messages
+3. Use imperative mood in commit messages
+4. Focus on why the changes were made, not just what
+
+### Step 3: Present your plan to the user
+> **IMPORTANT** this step can be skipped if the user explicitely allowed.
+
+1. List the files you plan to add for each commit
+2. Show the commit message(s) you'll use
+3. Ask: "I plan to create [N] commit(s) with these changes. Shall I proceed?"
+
+### Step 4: Execute planned commits
+1. Use `git add` with specific files (never use `-A` or `.`)
+- Create commits with your planned messages
+- Show the result with `git log --oneline -n [number]`

commands/create-pr.md

@@ -0,0 +1,38 @@
+---
+name: create-pr
+description: Create a new branch, push to remote, and create a pull request on GitHub
+---
+
+You are helping create a GitHub pull request. Follow these steps:
+
+**ASSUMPTIONS:**
+- All changes are already committed locally
+- The current branch is the one with the changes
+
+**STEPS:**
+
+1. **Analyze the commits:**
+   - Run `git log origin/main..HEAD` (or appropriate base branch) to see all commits that will be included
+   - Run `git diff origin/main...HEAD` to see the full diff
+
+2. **Create a new branch:**
+   - Generate a descriptive branch name based on the changes (use kebab-case, e.g., `feature/add-user-auth` or `fix/memory-leak`)
+   - Create and checkout the new branch: `git checkout -b <branch-name>`
+
+3. **Push to remote:**
+   - Push the new branch to origin with tracking: `git push -u origin <branch-name>`
+
+4. **Create the pull request:**
+   - Analyze ALL commits (not just the latest) to understand the full scope of changes
+   - Generate a clear, concise title (max 72 characters) that describes what the PR does
+   - Create a PR body with:
+     - Brief summary of changes (2-3 sentences)
+     - Why these changes were made
+     - Any relevant context or notes
+
+**IMPORTANT:**
+- DO NOT use the TodoWrite tool
+- Be concise and focused
+- Return the PR URL when done
+- If $ARGUMENTS is provided, use it as context or as the target base branch
+- Use the GH cli tool to interact with GitHub

plugin.lock.json

@@ -0,0 +1,57 @@
+{
+  "$schema": "internal://schemas/plugin.lock.v1.json",
+  "pluginId": "gh:dnlopes/claude-code-plugins:git-workflow",
+  "normalized": {
+    "repo": null,
+    "ref": "refs/tags/v20251128.0",
+    "commit": "fcbf08c8665382b0d330d60945bd2de384d44090",
+    "treeHash": "1c22e0a6defd57c68d8b100f3099f335cf5ecc023f33f8d66768d698ce491fcf",
+    "generatedAt": "2025-11-28T10:16:32.266506Z",
+    "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-workflow",
+    "description": "Git and GitHub workflow commands for commits and pull requests",
+    "version": "1.0.0"
+  },
+  "content": {
+    "files": [
+      {
+        "path": "README.md",
+        "sha256": "73515100b8e49aaa69859daff7979e01e7e94f751d31aecb91549f294ba045d7"
+      },
+      {
+        "path": ".claude-plugin/plugin.json",
+        "sha256": "d1ced03ae936f2d2d3380daa3e30090c5b6184e8c72478413517082ca6b589a2"
+      },
+      {
+        "path": "commands/create-pr.md",
+        "sha256": "5057cada9774ce3eb0850f219d42b4d44d8e6411fb7c39dffdcdf1b803acfafd"
+      },
+      {
+        "path": "commands/commit.md",
+        "sha256": "2402876f3eb313ce8c56236ba6a33f4b230d6ada4aa6d719933cffd61ca49fbd"
+      },
+      {
+        "path": "skills/creating-pull-requests/SKILL.md",
+        "sha256": "74971c2a1a1a162d95fc9dd3ed2c32f7eb2366207e31dbf566ec354e7c2ebf20"
+      },
+      {
+        "path": "skills/committing-work/SKILL.md",
+        "sha256": "f4ca71ff698b535376c488fae63e0fa28dbaea11b02807dc8a4459226b896170"
+      }
+    ],
+    "dirSha256": "1c22e0a6defd57c68d8b100f3099f335cf5ecc023f33f8d66768d698ce491fcf"
+  },
+  "security": {
+    "scannedAt": null,
+    "scannerVersion": null,
+    "flags": []
+  }
+}

skills/committing-work/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: committing-work
+description: Use this skill before committing changes on the repository.
+---
+
+# Committing Work
+
+## Overview
+
+**Announce at start:** "🟢 I'm using the committing-work skill to complete this work."
+
+## Key Principles
+
+- **Commit message**: commit messages must be constructed based on the changes detected
+- **Atomic commits**: Each commit should contain related changes that serve a single purpose
+- **Split large changes**: If changes touch multiple concerns, split them into separate commits
+- **Conventional commit format**: Use the format `<type>(<ticket>): <description>`:
+  - `<ticket>` section is optional
+  - `<type>` section is one of:
+    - `feat`: A new feature
+    - `fix`: A bug fix
+    - `docs`: Documentation changes
+    - `style`: Code style changes (formatting, etc)
+    - `refactor`: Code changes that neither fix bugs nor add features
+    - `perf`: Performance improvements
+    - `test`: Adding or fixing tests
+    - `chore`: Changes to the build process, tools, etc.
+- **Present tense, imperative mood**: Write commit messages as commands (e.g., "add feature" not "added feature")
+- **Ignore not relevant changes**: Changed files unrelated to the work done should be ignored (e.g., temporary files). If unsure, ask the user for guidance.
+- **Concise first line**: Keep the first line under 72 characters
+- **Use emojis**: Each commit type **MUST** be paired with an appropriate emoji:
+  - ✨ `feat`: New feature
+  - 🐛 `fix`: Bug fix
+  - 📝 `docs`: Documentation
+  - 💄 `style`: Formatting/style
+  - ♻️ `refactor`: Code refactoring
+  - ⚡️ `perf`: Performance improvements
+  - ✅ `test`: Tests
+  - 🔧 `chore`: Tooling, configuration
+  - 🚀 `ci`: CI/CD improvements
+  - 🗑️ `revert`: Reverting changes
+  - 🧪 `test`: Add a failing test
+  - 🚨 `fix`: Fix compiler/linter warnings
+  - 🔒️ `fix`: Fix security issues
+  - 👥 `chore`: Add or update contributors
+  - 🚚 `refactor`: Move or rename resources
+  - 🏗️ `refactor`: Make architectural changes
+  - 🔀 `chore`: Merge branches
+  - 📦️ `chore`: Add or update compiled files or packages
+  - ➕ `chore`: Add a dependency
+  - ➖ `chore`: Remove a dependency
+  - 🌱 `chore`: Add or update seed files
+  - 🧑‍💻 `chore`: Improve developer experience
+  - 🧵 `feat`: Add or update code related to multithreading or concurrency
+  - 🔍️ `feat`: Improve SEO
+  - 🏷️ `feat`: Add or update types
+  - 💬 `feat`: Add or update text and literals
+  - 🌐 `feat`: Internationalization and localization
+  - 👔 `feat`: Add or update business logic
+  - 📱 `feat`: Work on responsive design
+  - 🚸 `feat`: Improve user experience / usability
+  - 🩹 `fix`: Simple fix for a non-critical issue
+  - 🥅 `fix`: Catch errors
+  - 👽️ `fix`: Update code due to external API changes
+  - 🔥 `fix`: Remove code or files
+  - 🎨 `style`: Improve structure/format of the code
+  - 🚑️ `fix`: Critical hotfix
+  - 🎉 `chore`: Begin a project
+  - 🔖 `chore`: Release/Version tags
+  - 🚧 `wip`: Work in progress
+  - 💚 `fix`: Fix CI build
+  - 📌 `chore`: Pin dependencies to specific versions
+  - 👷 `ci`: Add or update CI build system
+  - 📈 `feat`: Add or update analytics or tracking code
+  - ✏️ `fix`: Fix typos
+  - ⏪️ `revert`: Revert changes
+  - 📄 `chore`: Add or update license
+  - 💥 `feat`: Introduce breaking changes
+  - 🍱 `assets`: Add or update assets
+  - ♿️ `feat`: Improve accessibility
+  - 💡 `docs`: Add or update comments in source code
+  - 🗃️ `db`: Perform database related changes
+  - 🔊 `feat`: Add or update logs
+  - 🔇 `fix`: Remove logs
+  - 🤡 `test`: Mock things
+  - 🥚 `feat`: Add or update an easter egg
+  - 🙈 `chore`: Add or update .gitignore file
+  - 📸 `test`: Add or update snapshots
+  - ⚗️ `experiment`: Perform experiments
+  - 🚩 `feat`: Add, update, or remove feature flags
+  - 💫 `ui`: Add or update animations and transitions
+  - ⚰️ `refactor`: Remove dead code
+  - 🦺 `feat`: Add or update code related to validation
+  - ✈️ `feat`: Improve offline support
+
+### Guidelines for Splitting Commits
+
+When analyzing the diff, consider splitting commits based on these criteria:
+
+1. **Different concerns**: Changes to unrelated parts of the codebase
+2. **Different types of changes**: Mixing features, fixes, refactoring, etc.
+3. **File patterns**: Changes to different types of files (e.g., source code vs documentation)
+4. **Logical grouping**: Changes that would be easier to understand or review separately
+6. **Size**: Very large changes that would be clearer if broken down
+
+### Examples
+
+Good commit messages:
+- ✨ feat: add user authentication system
+- 🐛 fix: resolve memory leak in rendering process
+- 📝 docs: update API documentation with new endpoints
+- ♻️ refactor: simplify error handling logic in parser
+- 🚨 fix: resolve linter warnings in component files
+- 🧑‍💻 chore: improve developer tooling setup process
+- 👔 feat: implement business logic for transaction validation
+- 🩹 fix: address minor styling inconsistency in header
+- 🚑️ fix: patch critical security vulnerability in auth flow
+- 🎨 style: reorganize component structure for better readability
+- 🔥 fix: remove deprecated legacy code
+- 🦺 feat: add input validation for user registration form
+- 💚 fix: resolve failing CI pipeline tests
+- 📈 feat: implement analytics tracking for user engagement
+- 🔒️ fix: strengthen authentication password requirements
+- ♿️ feat: improve form accessibility for screen readers
+
+Example of splitting commits:
+- First commit: ✨ feat: add new solc version type definitions
+- Second commit: 📝 docs: update documentation for new solc versions
+- Third commit: 🔧 chore: update package.json dependencies
+- Fourth commit: 🏷️ feat: add type definitions for new API endpoints
+- Fifth commit: 🧵 feat: improve concurrency handling in worker threads
+- Sixth commit: 🚨 fix: resolve linting issues in new code
+- Seventh commit: ✅ test: add unit tests for new solc version features
+- Eighth commit: 🔒️ fix: update dependencies with security vulnerabilities

skills/creating-pull-requests/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: creating-pull-requests
+description: Use this skill before creating pull requests
+---
+
+# Committing Work
+
+## Overview
+
+**Announce at start:** "🟢 I'm using the creating-pull-requests skill to complete this work."
+
+## Key Principles
+
+- Pull-request titles must follow all the commit message rules as described in skill `committing-work`
+- **Conventional commit format**: Use the format `<type>(<ticket>): <description>`:
+  - `<ticket>` section is optional
+  - `<type>` section is one of:
+    - `feat`: A new feature
+    - `fix`: A bug fix
+    - `docs`: Documentation changes
+    - `style`: Code style changes (formatting, etc)
+    - `refactor`: Code changes that neither fix bugs nor add features
+    - `perf`: Performance improvements
+    - `test`: Adding or fixing tests
+    - `chore`: Changes to the build process, tools, etc.
+- **Language**: Always use English for PR titles and descriptions
+- **Use emojis**: Each commit type **MUST** be paired with an appropriate emoji:
+  - ✨ `feat`: New feature
+  - 🐛 `fix`: Bug fix
+  - 📝 `docs`: Documentation
+  - 💄 `style`: Formatting/style
+  - ♻️ `refactor`: Code refactoring
+  - ⚡️ `perf`: Performance improvements
+  - ✅ `test`: Tests
+  - 🔧 `chore`: Tooling, configuration
+  - 🚀 `ci`: CI/CD improvements
+  - 🗑️ `revert`: Reverting changes
+  - 🧪 `test`: Add a failing test
+  - 🚨 `fix`: Fix compiler/linter warnings
+  - 🔒️ `fix`: Fix security issues
+  - 👥 `chore`: Add or update contributors
+  - 🚚 `refactor`: Move or rename resources
+  - 🏗️ `refactor`: Make architectural changes
+  - 🔀 `chore`: Merge branches
+  - 📦️ `chore`: Add or update compiled files or packages
+  - ➕ `chore`: Add a dependency
+  - ➖ `chore`: Remove a dependency
+  - 🌱 `chore`: Add or update seed files
+  - 🧑‍💻 `chore`: Improve developer experience
+  - 🧵 `feat`: Add or update code related to multithreading or concurrency
+  - 🔍️ `feat`: Improve SEO
+  - 🏷️ `feat`: Add or update types
+  - 💬 `feat`: Add or update text and literals
+  - 🌐 `feat`: Internationalization and localization
+  - 👔 `feat`: Add or update business logic
+  - 📱 `feat`: Work on responsive design
+  - 🚸 `feat`: Improve user experience / usability
+  - 🩹 `fix`: Simple fix for a non-critical issue
+  - 🥅 `fix`: Catch errors
+  - 👽️ `fix`: Update code due to external API changes
+  - 🔥 `fix`: Remove code or files
+  - 🎨 `style`: Improve structure/format of the code
+  - 🚑️ `fix`: Critical hotfix
+  - 🎉 `chore`: Begin a project
+  - 🔖 `chore`: Release/Version tags
+  - 🚧 `wip`: Work in progress
+  - 💚 `fix`: Fix CI build
+  - 📌 `chore`: Pin dependencies to specific versions
+  - 👷 `ci`: Add or update CI build system
+  - 📈 `feat`: Add or update analytics or tracking code
+  - ✏️ `fix`: Fix typos
+  - ⏪️ `revert`: Revert changes
+  - 📄 `chore`: Add or update license
+  - 💥 `feat`: Introduce breaking changes
+  - 🍱 `assets`: Add or update assets
+  - ♿️ `feat`: Improve accessibility
+  - 💡 `docs`: Add or update comments in source code
+  - 🗃️ `db`: Perform database related changes
+  - 🔊 `feat`: Add or update logs
+  - 🔇 `fix`: Remove logs
+  - 🤡 `test`: Mock things
+  - 🥚 `feat`: Add or update an easter egg
+  - 🙈 `chore`: Add or update .gitignore file
+  - 📸 `test`: Add or update snapshots
+  - ⚗️ `experiment`: Perform experiments
+  - 🚩 `feat`: Add, update, or remove feature flags
+  - 💫 `ui`: Add or update animations and transitions
+  - ⚰️ `refactor`: Remove dead code
+  - 🦺 `feat`: Add or update code related to validation
+  - ✈️ `feat`: Improve offline support
+- Use GitHub CLI to create pull-requests:
+```bash
+gh pr create --base main --head <branch> --title "<pr-title>" --body "<pr-body>"
+```
+
+### Examples
+
+Good pull request titles:
+- ✨ feat: add user authentication system
+- 🐛 fix: resolve memory leak in rendering process
+- 📝 docs: update API documentation with new endpoints
+- ♻️ refactor: simplify error handling logic in parser
+- 🚨 fix: resolve linter warnings in component files
+- 🧑‍💻 chore: improve developer tooling setup process
+- 👔 feat: implement business logic for transaction validation
+- 🩹 fix: address minor styling inconsistency in header
+- 🚑️ fix: patch critical security vulnerability in auth flow
+- 🎨 style: reorganize component structure for better readability
+- 🔥 fix: remove deprecated legacy code
+- 🦺 feat: add input validation for user registration form
+- 💚 fix: resolve failing CI pipeline tests
+- 📈 feat: implement analytics tracking for user engagement
+- 🔒️ fix: strengthen authentication password requirements
+- ♿️ feat: improve form accessibility for screen readers