How do I install the Commit Helper skill?

Run npx skillmds add majiayu000/commit-helper-6 in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Commit Helper safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: makes network calls. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Commit Helper?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Commit Helper free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Commit Helper?

majiayu000 (@majiayu000) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Commit Helper by majiayu000 — Agent Skill

Name: Commit Helper
Rating: 4.5 (4 reviews)
Author: majiayu000

File contents

Generating Commit Messages

Generate commit messages following the Conventional Commits specification.

Format

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Common Types

feat: New feature (correlates with MINOR in SemVer)
fix: Bug fix (correlates with PATCH in SemVer)
docs: Documentation changes
style: Code style changes (formatting, semicolons, etc.)
refactor: Code refactoring without changing behavior
perf: Performance improvements
test: Adding or updating tests
build: Build system or dependency changes
ci: CI/CD configuration changes
chore: Other changes that don't modify src or test files

Breaking Changes

Use ! after type/scope or add BREAKING CHANGE: footer:

feat!: redesign API response format

BREAKING CHANGE: Response format changed from array to object

Examples

Simple commit

docs: fix typo in README

With scope

feat(cli): add status command

With body

fix: prevent race condition in request handling

- Introduce request ID tracking to dismiss stale responses.
- Remove obsolete timeout-based mitigation.

Breaking change

feat(api)!: change authentication flow

BREAKING CHANGE: JWT tokens now required for all endpoints

Instructions

Run git diff --staged to see staged changes
Generate a commit message with:
- Clear, concise header in present tense.
- Optional body with bullet points for complex changes. Always use bullet points when adding a body.
- Optional footer for breaking changes or references.
Show the proposed commit message to the user, by printing to stdout.
Ask the user for their approval using the AskUserQuestion tool.
If yes, commit the changes.
If no, incorporate the feedback and go back to step 2 to generate the correct message.

Best Practices

Use present tense ("add feature" not "added feature")
Keep header under 72 characters
Explain what and why, not how
Reference issues/PRs in footer when relevant (e.g., Refs: #123)
Use body for complex changes, omit for simple ones

IMPORTANT: Be concise. Grammar does not matter as long as it's clear and concise. Try to keep the body within 2-3 bullet points with very concise sentences.

---name: commit-helper-6description: Generates clear commit messages from git diffs. Use when writing commit messages or reviewing staged changes.--- # Generating Commit Messages Generate commit messages following the [Conventional Commits](https://www.conventionalcommits.org/) specification. ## Format ``` <type>[optional scope]: <description> [optional body] [optional footer(s)] ``` ## Common Types - **feat**: New feature (correlates with MINOR in SemVer) - **fix**: Bug fix (correlates with PATCH in SemVer) - **docs**: Documentation changes - **style**: Code style changes (formatting, semicolons, etc.) - **refactor**: Code refactoring without changing behavior - **perf**: Performance improvements - **test**: Adding or updating tests - **build**: Build system or dependency changes - **ci**: CI/CD configuration changes - **chore**: Other changes that don't modify src or test files ## Breaking Changes Use ! after type/scope or add BREAKING CHANGE: footer: ``` feat!: redesign API response format BREAKING CHANGE: Response format changed from array to object ``` ## Examples ### Simple commit ``` docs: fix typo in README ``` ### With scope ``` feat(cli): add status command ``` ### With body ``` fix: prevent race condition in request handling - Introduce request ID tracking to dismiss stale responses. - Remove obsolete timeout-based mitigation. ``` ### Breaking change ``` feat(api)!: change authentication flow BREAKING CHANGE: JWT tokens now required for all endpoints ``` ## Instructions 1. Run `git diff --staged` to see staged changes 2. Generate a commit message with: - Clear, concise header in present tense. - Optional body with bullet points for complex changes. Always use bullet points when adding a body. - Optional footer for breaking changes or references. 3. Show the proposed commit message to the user, by printing to stdout. 4. Ask the user for their approval using the `AskUserQuestion` tool. 5. If yes, commit the changes. 6. If no, incorporate the feedback and go back to step 2 to generate the correct message. ## Best Practices - Use present tense ("add feature" not "added feature") - Keep header under 72 characters - Explain **what** and **why**, not how - Reference issues/PRs in footer when relevant (e.g., `Refs: #123`) - Use body for complex changes, omit for simple ones IMPORTANT: Be concise. Grammar does not matter as long as it's clear and concise. Try to keep the body within 2-3 bullet points with very concise sentences.

Frequently asked questions