Run any Skill in Manus with one click

git-commit-helper

Stars2

Forks0

UpdatedJanuary 15, 2026 at 21:21

Generate well-structured git commit messages following conventional commits format. Use when committing changes, creating commit messages, or when commit history needs improvement. Ensures commits are clear, descriptive, and follow project conventions.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

lexicalninja

lexicalninja/my-little-scrum-team

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	git-commit-helper
description	Generate well-structured git commit messages following conventional commits format. Use when committing changes, creating commit messages, or when commit history needs improvement. Ensures commits are clear, descriptive, and follow project conventions.

Git Commit Helper Skill

Instructions

Analyze the staged changes or diff to understand what was modified
Determine the type of change:
- feat: New feature
- fix: Bug fix
- docs: Documentation changes
- style: Code style changes (formatting, no logic change)
- refactor: Code refactoring
- perf: Performance improvements
- test: Adding or updating tests
- chore: Maintenance tasks, build config, etc.
- ci: CI/CD changes
- build: Build system changes
Write a clear, concise subject line (50 chars or less)
Add a blank line, then detailed body if needed (wrap at 72 chars)
Reference issues/PRs when applicable
Use imperative mood: "Add feature" not "Added feature" or "Adds feature"
Follow conventional commits format: type(scope): subject

Examples

Input: "I added a new login button and fixed the validation bug" Output:

feat(auth): add login button to header

- Add new login button component to navigation header
- Implement click handler to open login modal
- Add styling to match design system

fix(validation): resolve email validation error

- Fix regex pattern for email validation
- Add test cases for edge cases
- Update error message to be more user-friendly

Closes #123

Input: "Updated the README and fixed some typos" Output:

docs: update README with installation instructions

- Add detailed installation steps for different platforms
- Include troubleshooting section
- Fix typos in existing documentation

Input: "Refactored the payment processing code" Output:

refactor(payments): improve payment processing logic

- Extract payment validation into separate function
- Simplify retry logic for failed transactions
- Improve error handling and logging
- Add unit tests for payment flow

BREAKING CHANGE: PaymentProcessor constructor now requires config object

Format Guidelines

Conventional Commits Format:

<type>(<scope>): <subject>

<body>

<footer>

Types:

feat: New feature for users
fix: Bug fix for users
docs: Documentation only
style: Formatting, missing semicolons, etc.
refactor: Code change that neither fixes bug nor adds feature
perf: Performance improvement
test: Adding missing tests
chore: Changes to build process or auxiliary tools

Best Practices:

Subject line: imperative, lowercase, no period
Body: explain what and why, not how
Footer: reference issues, breaking changes
Use present tense: "Fix bug" not "Fixed bug"

More from this repository

same repository

accessibility-checker

lexicalninja/my-little-scrum-team

Checks code for accessibility issues including missing alt text, poor color contrast, missing ARIA labels, keyboard navigation issues, screen reader compatibility, and focus management. Returns structured accessibility issue reports with WCAG compliance information.

2026-01-152

accessibility-design-checker

lexicalninja/my-little-scrum-team

Ensures designs meet accessibility requirements including WCAG compliance, color contrast, keyboard navigation, screen reader support, and focus management. Reviews designs for accessibility issues and provides recommendations.

2026-01-152

agent-capability-assessor

lexicalninja/my-little-scrum-team

Assesses agent capabilities by analyzing agent files and determining what tasks they can handle. Use when you need to evaluate if an existing agent can handle a task or if a new agent is needed. Reviews agent descriptions, skills, and workflows to determine capability match.

2026-01-152

agent-creator

lexicalninja/my-little-scrum-team

Creates new agent files with complete specifications, following the same format as existing agents. Use when a new agent is needed for tasks that existing agents cannot handle. Generates agent markdown files with name, description, core principles, workflow, and integration details.

2026-01-152

api-implementer

lexicalninja/my-little-scrum-team

Implements API endpoints, routes, controllers, and request/response handling. Use when implementing REST APIs, GraphQL APIs, or other API endpoints. Handles routing, validation, error handling, and response formatting.

2026-01-152

architecture-reviewer

lexicalninja/my-little-scrum-team

Reviews code architecture for design issues including poor separation of concerns, tight coupling, missing abstractions, design pattern violations, scalability concerns, and maintainability issues. Returns structured architecture review reports with improvement suggestions.

2026-01-152

name	git-commit-helper
description	Generate well-structured git commit messages following conventional commits format. Use when committing changes, creating commit messages, or when commit history needs improvement. Ensures commits are clear, descriptive, and follow project conventions.

Git Commit Helper Skill

Instructions

Analyze the staged changes or diff to understand what was modified
Determine the type of change:
- feat: New feature
- fix: Bug fix
- docs: Documentation changes
- style: Code style changes (formatting, no logic change)
- refactor: Code refactoring
- perf: Performance improvements
- test: Adding or updating tests
- chore: Maintenance tasks, build config, etc.
- ci: CI/CD changes
- build: Build system changes
Write a clear, concise subject line (50 chars or less)
Add a blank line, then detailed body if needed (wrap at 72 chars)
Reference issues/PRs when applicable
Use imperative mood: "Add feature" not "Added feature" or "Adds feature"
Follow conventional commits format: type(scope): subject

Examples

Input: "I added a new login button and fixed the validation bug" Output:

feat(auth): add login button to header

- Add new login button component to navigation header
- Implement click handler to open login modal
- Add styling to match design system

fix(validation): resolve email validation error

- Fix regex pattern for email validation
- Add test cases for edge cases
- Update error message to be more user-friendly

Closes #123

Input: "Updated the README and fixed some typos" Output:

docs: update README with installation instructions

- Add detailed installation steps for different platforms
- Include troubleshooting section
- Fix typos in existing documentation

Input: "Refactored the payment processing code" Output:

refactor(payments): improve payment processing logic

- Extract payment validation into separate function
- Simplify retry logic for failed transactions
- Improve error handling and logging
- Add unit tests for payment flow

BREAKING CHANGE: PaymentProcessor constructor now requires config object

Format Guidelines

Conventional Commits Format:

<type>(<scope>): <subject>

<body>

<footer>

Types:

feat: New feature for users
fix: Bug fix for users
docs: Documentation only
style: Formatting, missing semicolons, etc.
refactor: Code change that neither fixes bug nor adds feature
perf: Performance improvement
test: Adding missing tests
chore: Changes to build process or auxiliary tools

Best Practices:

Subject line: imperative, lowercase, no period
Body: explain what and why, not how
Footer: reference issues, breaking changes
Use present tense: "Fix bug" not "Fixed bug"