How do I install the Commit skill?

Run npx skillmds@latest add tomevault-io/commit-52 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 safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with 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 Commit free to use?

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

Who published Commit?

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

Commit by tomevault-io — Agent Skill

Name: Commit
Author: tomevault-io

File contents

CRITICAL — Never open an interactive editor

This applies to ALL git operations, not just commits.

Any git command that opens an editor will hang the agent forever. Always prevent this:

Command	Safe version
`git commit`	`git commit -m "message"`
`git rebase --continue`	`GIT_EDITOR=true git rebase --continue`
`git merge --continue`	`GIT_EDITOR=true git merge --continue`
`git cherry-pick --continue`	`GIT_EDITOR=true git cherry-pick --continue`
`git revert --continue`	`GIT_EDITOR=true git revert --continue`
`git rebase -i`	Never use — use non-interactive rebase only
Any `--continue` after conflict resolution	Always prefix with `GIT_EDITOR=true`

Rule: Every --continue gets GIT_EDITOR=true. No exceptions.

Commit format

Create commits using Conventional Commits: <type>(<scope>): <summary>

type REQUIRED. Use feat for new features, fix for bug fixes. Other common types: docs, refactor, chore, test, perf.
scope OPTIONAL. Short noun in parentheses for the affected area (e.g., api, parser, ui).
summary REQUIRED. Short, imperative, <= 72 chars, no trailing period.

Notes

Never use --no-gpg-sign. Commits must be signed. The user has 1Password SSH signing configured — a Touch ID prompt will appear when you commit. Let it happen. If signing fails, tell the user rather than bypassing it.
Body is strongly encouraged — always include one unless the change is trivially obvious (e.g., fixing a typo). The body should explain what changed, why it changed, the approach taken, and any notable decisions. A reader of git log should understand the change without looking at the diff.
Do NOT include breaking-change markers or footers.
Do NOT add sign-offs (no Signed-off-by).
Only commit; do NOT push.
If it is unclear whether a file should be included, ask the user which files to commit.
Treat any caller-provided arguments as additional commit guidance. Common patterns:
- Freeform instructions should influence scope, summary, and body.
- File paths or globs should limit which files to commit. If files are specified, only stage/commit those unless the user explicitly asks otherwise.
- If arguments combine files and instructions, honor both.

Steps

Infer from the prompt if the user provided specific file paths/globs and/or additional instructions.
Review git status and git diff to understand the current changes (limit to argument-specified files if provided).
(Optional) Run git log -n 50 --pretty=format:%s to see commonly used scopes.
If there are ambiguous extra files, ask the user for clarification before committing.
Stage only the intended files (all changes if no files specified).
Run git commit -m "<subject>" (and -m "<body>" if needed).

Converted and distributed by TomeVault — claim your Tome and manage your conversions.

---name: commit-52description: Read this skill before making git commits, rebases, merges, cherry-picks, or any git operation Use when this capability is needed.---## CRITICAL — Never open an interactive editor**This applies to ALL git operations, not just commits.**Any git command that opens an editor will hang the agent forever. Always prevent this:| Command | Safe version ||---------|-------------|| `git commit` | `git commit -m "message"` || `git rebase --continue` | `GIT_EDITOR=true git rebase --continue` || `git merge --continue` | `GIT_EDITOR=true git merge --continue` || `git cherry-pick --continue` | `GIT_EDITOR=true git cherry-pick --continue` || `git revert --continue` | `GIT_EDITOR=true git revert --continue` || `git rebase -i` | **Never use** — use non-interactive rebase only || Any `--continue` after conflict resolution | Always prefix with `GIT_EDITOR=true` |**Rule: Every `--continue` gets `GIT_EDITOR=true`. No exceptions.**---## Commit formatCreate commits using Conventional Commits: `<type>(<scope>): <summary>`- `type` REQUIRED. Use `feat` for new features, `fix` for bug fixes. Other common types: `docs`, `refactor`, `chore`, `test`, `perf`.- `scope` OPTIONAL. Short noun in parentheses for the affected area (e.g., `api`, `parser`, `ui`).- `summary` REQUIRED. Short, imperative, <= 72 chars, no trailing period.## Notes- **Never use `--no-gpg-sign`.** Commits must be signed. The user has 1Password SSH signing configured — a Touch ID prompt will appear when you commit. Let it happen. If signing fails, tell the user rather than bypassing it.- Body is **strongly encouraged** — always include one unless the change is trivially obvious (e.g., fixing a typo). The body should explain **what** changed, **why** it changed, the approach taken, and any notable decisions. A reader of `git log` should understand the change without looking at the diff.- Do NOT include breaking-change markers or footers.- Do NOT add sign-offs (no `Signed-off-by`).- Only commit; do NOT push.- If it is unclear whether a file should be included, ask the user which files to commit.- Treat any caller-provided arguments as additional commit guidance. Common patterns: - Freeform instructions should influence scope, summary, and body. - File paths or globs should limit which files to commit. If files are specified, only stage/commit those unless the user explicitly asks otherwise. - If arguments combine files and instructions, honor both.## Steps1. Infer from the prompt if the user provided specific file paths/globs and/or additional instructions.2. Review `git status` and `git diff` to understand the current changes (limit to argument-specified files if provided).3. (Optional) Run `git log -n 50 --pretty=format:%s` to see commonly used scopes.4. If there are ambiguous extra files, ask the user for clarification before committing.5. Stage only the intended files (all changes if no files specified).6. Run `git commit -m "<subject>"` (and `-m "<body>"` if needed).---> Converted and distributed by [TomeVault](https://tomevault.io/claim/bruno-garcia) — claim your Tome and manage your conversions.

Frequently asked questions

Commit