git-commit-message.yaml 3.2 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283
  1. version: 1.0.0
  2. title: Create git commit message from staged changes
  3. description: Generate meaningful git commit messages by analyzing staged changes
  4. prompt: |
  5. You are tasked with creating a clear and descriptive git commit message based on staged Git changes. Follow these instructions:
  6. ## Analysis Process:
  7. 1. **Read staged changes**: Use `git diff --staged` to analyze what files and code changes are currently staged for commit
  8. 2. **Analyze change scope**: Identify which components/modules are affected (e.g., cdk, cashu, cdk-cli, etc.)
  9. 3. **Determine change type**: Categorize the primary change as:
  10. - **feat**: New features or functionality
  11. - **fix**: Bug fixes
  12. - **refactor**: Code refactoring without functional changes
  13. - **docs**: Documentation changes
  14. - **style**: Code style/formatting changes
  15. - **test**: Adding or updating tests
  16. - **chore**: Maintenance tasks, dependency updates, build changes
  17. ## Commit Message Format:
  18. Follow conventional commit format:
  19. ```
  20. type(scope): description
  21. Optional body with more details if needed
  22. ```
  23. ### Examples:
  24. ```
  25. feat(cdk): add keyset refresh functionality with improved error handling
  26. refactor(wallet): improve keyset management for better performance
  27. fix(cdk-cli): resolve token parsing error for malformed inputs
  28. docs(README): update installation instructions
  29. chore(deps): update rust dependencies to latest versions
  30. ```
  31. ## Commit Message Guidelines:
  32. 1. **Subject line (first line)**:
  33. - Start with conventional commit type and scope
  34. - Use imperative mood ("add", "fix", "update", not "added", "fixed", "updated")
  35. - Keep under 72 characters
  36. - Don't end with a period
  37. - Be specific and descriptive
  38. 2. **Body (optional)**:
  39. - Add if the change needs more explanation
  40. - Wrap at 72 characters
  41. - Explain **what** and **why**, not **how**
  42. - Separate from subject with blank line
  43. 3. **Scope identification**:
  44. - Use component names from file paths (cdk, cashu, cdk-cli, etc.)
  45. - Use general scopes like "deps", "ci", "docs" for broad changes
  46. - Omit scope if change affects multiple unrelated areas
  47. ## Analysis Priority:
  48. 1. **Focus on the main change**: If multiple types of changes, pick the most significant one
  49. 2. **Combine related changes**: Group similar modifications into one cohesive message
  50. 3. **Ignore trivial changes**: Don't mention minor formatting, whitespace, or comment changes unless that's the primary purpose
  51. 4. **Be user/developer focused**: Describe impact rather than implementation details
  52. ## Steps to Execute:
  53. 1. Analyze staged changes with `git diff --staged`
  54. 2. Identify primary change type and affected components
  55. 3. Write a clear, descriptive commit message following conventional format
  56. 4. Output ONLY the commit message (no additional explanation unless asked)
  57. extensions:
  58. - type: builtin
  59. name: developer
  60. display_name: Developer
  61. timeout: 300
  62. bundled: true
  63. activities:
  64. - Analyze staged git changes
  65. - Generate conventional commit messages
  66. - Identify change types and scopes
  67. - Create clear and descriptive commit subjects
  68. - Format commit messages properly
  69. author:
  70. contact: thesimplekid