How do I install the J5ik2o Git Commit skill?

Run npx skillmds@latest add j5ik2o/j5ik2o-git-commit 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 J5ik2o Git Commit safe to use?

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

Which AI agents work with J5ik2o Git Commit?

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 J5ik2o Git Commit free to use?

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

Who published J5ik2o Git Commit?

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

J5ik2o Git Commit by j5ik2o — Agent Skill

Name: J5ik2o Git Commit
Author: j5ik2o

J5ik2o Git Commit

Commit working-tree changes using Conventional Commits. Stage changes in meaningful units, write commit messages in English, and avoid co-author or agent attribution in commit messages. Use this skill only when the user explicitly asks to create a real git commit, such as "commit these changes", "create a git commit", "git commit", or "commit this work". Do not use it when the user only wants commit message wording without making an actual commit. This skill commits locally only; it does not push.

j5ik2o a7b36c5 2 files · 3.9 KB Updated Sep 17, 2026

File contents

Git Commit

Create clear project history by committing changes in meaningful, reviewable units.

Workflow

1. Inspect Recent Commit History

Review the latest commits to match the repository's commit style.

git log --oneline -10

2. Inspect Current Changes

Check the working tree state. Do not use the -uall flag because it can cause memory problems in large repositories.

git status
git diff
git diff --staged

3. Stage Meaningful Units

Stage only the files that belong in the current logical change. Do not blindly run git add -A or git add .; specify the intended files or directories.

git add <target-files-or-directories>

After staging, always inspect the exact content that will be committed. git diff does not show new untracked file contents or all staged changes, so use git diff --staged to review staged content, including new files and any changes produced by hooks or formatters.

git diff --staged

Never include .env files or files containing credentials. If the user explicitly asks to commit such files, stop and ask them to remove or redact the secret material first.

Also do not include files the user explicitly asked to exclude.

If one staged set contains multiple logically independent changes, split it into multiple commits.

4. Write the Commit Message and Commit

Use Conventional Commits and write the message in English.

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

<body-if-needed>
EOF
)"

Commit message rules:

Conventional Commits format: type(scope): description
- type: feat, fix, docs, style, refactor, test, chore, ci, perf, build, and similar types
- scope: affected area, optional
- description: concise summary of the change
Write in English
Do not include co-author lines or agent names such as "Claude Code" or "Codex"
Emphasize why the change exists, not just what changed
Write the description in imperative mood, for example "add" rather than "added"

5. Verify the Commit

Verify the commit that was actually created. Pre-commit hooks or formatters may modify and re-stage files during commit creation, so the post-commit check is required even after reviewing staged changes.

git log --oneline -5
git show --stat HEAD   # Files included in the commit
git show HEAD          # Exact committed diff, including hook-produced changes
git status             # Confirm hook-produced changes were not left uncommitted

If hooks introduced unintended committed content, or if hook-produced changes remain uncommitted, inspect the result and address it with a follow-up commit when appropriate.

Notes

If a pre-commit hook fails, no commit was created. Fix the problem and create a new commit; do not use --amend.
If a pre-commit hook modifies files, step 5 must verify whether those changes were included in the commit or left unstaged.
Do not bypass hooks with --no-verify. Investigate and fix failing hooks.
Pushing is outside this skill's scope. Do not push unless the user explicitly asks for it.

---name: j5ik2o-git-commitdescription: Commit working-tree changes using Conventional Commits. Stage changes in meaningful units, write commit messages in English, and avoid co-author or agent attribution in commit messages. Use this skill only when the user explicitly asks to create a real git commit, such as "commit these changes", "create a git commit", "git commit", or "commit this work". Do not use it when the user only wants commit message wording without making an actual commit. This skill commits locally only; it does not push.---# Git CommitCreate clear project history by committing changes in meaningful, reviewable units.## Workflow### 1. Inspect Recent Commit HistoryReview the latest commits to match the repository's commit style.```bashgit log --oneline -10```### 2. Inspect Current ChangesCheck the working tree state. Do not use the `-uall` flag because it can cause memory problems in large repositories.```bashgit statusgit diffgit diff --staged```### 3. Stage Meaningful UnitsStage only the files that belong in the current logical change. Do not blindly run `git add -A` or `git add .`; specify the intended files or directories.```bashgit add <target-files-or-directories>```After staging, **always inspect the exact content that will be committed**. `git diff` does not show new untracked file contents or all staged changes, so use `git diff --staged` to review staged content, including new files and any changes produced by hooks or formatters.```bashgit diff --staged```Never include `.env` files or files containing credentials. If the user explicitly asks to commit such files, stop and ask them to remove or redact the secret material first.Also do not include files the user explicitly asked to exclude.If one staged set contains multiple logically independent changes, split it into multiple commits.### 4. Write the Commit Message and CommitUse Conventional Commits and write the message in English.```bashgit commit -m "$(cat <<'EOF'<type>(<scope>): <description><body-if-needed>EOF)"```**Commit message rules:**- **Conventional Commits format**: `type(scope): description` - type: `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`, `ci`, `perf`, `build`, and similar types - scope: affected area, optional - description: concise summary of the change- **Write in English**- **Do not include co-author lines or agent names such as "Claude Code" or "Codex"**- Emphasize why the change exists, not just what changed- Write the description in imperative mood, for example "add" rather than "added"### 5. Verify the CommitVerify the commit that was actually created. Pre-commit hooks or formatters may modify and re-stage files during commit creation, so the post-commit check is required even after reviewing staged changes.```bashgit log --oneline -5git show --stat HEAD # Files included in the commitgit show HEAD # Exact committed diff, including hook-produced changesgit status # Confirm hook-produced changes were not left uncommitted```- If hooks introduced unintended committed content, or if hook-produced changes remain uncommitted, inspect the result and address it with a follow-up commit when appropriate.## Notes- If a pre-commit hook fails, no commit was created. Fix the problem and create a new commit; do not use `--amend`.- If a pre-commit hook modifies files, step 5 must verify whether those changes were included in the commit or left unstaged.- Do not bypass hooks with `--no-verify`. Investigate and fix failing hooks.- Pushing is outside this skill's scope. Do not push unless the user explicitly asks for it.

Frequently asked questions