How do I install the Committing Changes skill?

Run npx skillmds add majiayu000/committing-changes 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 Committing Changes safe to use?

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

Which AI agents work with Committing Changes?

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 Committing Changes free to use?

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

Who published Committing Changes?

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

Committing Changes by majiayu000 — Agent Skill

Name: Committing Changes
Rating: 4.666666666666667 (3 reviews)
Author: majiayu000

Committing Changes

Use this skill when committing code changes, creating git commits, staging files for commit, or when the user asks to commit, save changes, or make a commit. Handles conventional commit format, explicit file staging, and commit message crafting.

majiayu000 972e9aa 2 files · 2.9 KB Updated Sep 9, 2026 567 repo stars

File contents

Context

Current git status: !git status
Current git diff (staged and unstaged changes): !git diff HEAD
Recent commit messages (for style reference): !git log --oneline -10
User-provided message override (optional): $ARGUMENTS

Your task

Commit the work from this chat session using best practice conventions.

Step 1: Identify Changed Files

Review the git status output above. Only stage files that were actually modified during this conversation. Do NOT use git add -A or git add . blindly.

Step 2: Stage Files Explicitly

Add only the specific files that changed:

git add path/to/file1 path/to/file2

Step 3: Craft the Commit Message

Follow conventional commits format:

feat: New feature
fix: Bug fix
refactor: Code change that neither fixes nor adds
docs: Documentation only
test: Adding or updating tests
chore: Maintenance tasks

Structure:

<type>(<scope>): <short description>

<optional body with details>

Guidelines:

Keep the subject line under 72 characters
Use imperative mood ("add" not "added")
Focus on the "why" not just the "what"
Reference any relevant context from the conversation

Step 4: Create the Commit

If user provided a message override in $ARGUMENTS, use that instead of crafting one.

Use a HEREDOC for proper formatting:

git commit -m "$(cat <<'EOF'
<type>(<scope>): <description>

<optional body>
EOF
)"

Step 5: Verify Success

After committing, run git status to confirm the commit succeeded.

Important

Never stage files that weren't part of this session's work
Never commit secrets, credentials, or .env files
If no changes exist to commit, inform the user instead of creating an empty commit
You MUST complete all steps in a single response using parallel tool calls where appropriate

---name: committing-changesdescription: Use this skill when committing code changes, creating git commits, staging files for commit, or when the user asks to commit, save changes, or make a commit. Handles conventional commit format, explicit file staging, and commit message crafting.--- ## Context - Current git status: !`git status` - Current git diff (staged and unstaged changes): !`git diff HEAD` - Recent commit messages (for style reference): !`git log --oneline -10` - User-provided message override (optional): $ARGUMENTS ## Your task Commit the work from this chat session using best practice conventions. ### Step 1: Identify Changed Files Review the git status output above. Only stage files that were actually modified during this conversation. Do NOT use `git add -A` or `git add .` blindly. ### Step 2: Stage Files Explicitly Add only the specific files that changed: ```bash git add path/to/file1 path/to/file2 ``` ### Step 3: Craft the Commit Message Follow conventional commits format: - **feat**: New feature - **fix**: Bug fix - **refactor**: Code change that neither fixes nor adds - **docs**: Documentation only - **test**: Adding or updating tests - **chore**: Maintenance tasks Structure: ``` <type>(<scope>): <short description> <optional body with details> ``` Guidelines: - Keep the subject line under 72 characters - Use imperative mood ("add" not "added") - Focus on the "why" not just the "what" - Reference any relevant context from the conversation ### Step 4: Create the Commit If user provided a message override in $ARGUMENTS, use that instead of crafting one. Use a HEREDOC for proper formatting: ```bash git commit -m "$(cat <<'EOF' <type>(<scope>): <description> <optional body> EOF )" ``` ### Step 5: Verify Success After committing, run `git status` to confirm the commit succeeded. ## Important - Never stage files that weren't part of this session's work - Never commit secrets, credentials, or .env files - If no changes exist to commit, inform the user instead of creating an empty commit - You MUST complete all steps in a single response using parallel tool calls where appropriate

Frequently asked questions