New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Commit

by opsmill in opsmill/infrahub

Stages and commits the current changes onto a safe working branch, enforcing branch discipline and optionally pushing upstream.

Apache-2.0Auto-check: notesDevelopment

Install Commit

skills CLI
$ npx skills add opsmill/infrahub --skill commit -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install opsmill/infrahub commit --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/opsmill/infrahub.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/commit .claude/skills/commit && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
commit
GitHub stars
529
Token cost
~2.8k tokens
SKILL.md length
1,579 words
Files
1
Skills in repo
32
Repo updated
First seen
Licence
Apache-2.0

At a glance

Stages and commits the current changes onto a safe working branch, enforcing branch discipline and optionally pushing upstream.

  • Works in 6 steps: Assess Current State → Branch Safety — Never Commit to a… → Stage Changes → …
  • : the user wants to commit
  • SKILL.md covers Introduction, Arguments, Main Tasks and Notes, plus 1 more section
  • Calls git; reaches claude.ai

What it does

Commit is an agent skill from opsmill/infrahub. Stages and commits the current changes onto a safe working branch, enforcing branch discipline and optionally pushing upstream. TRIGGER when: the user wants to commit, save, or check in the current changes. DO NOT TRIGGER when: opening a pull request → pr.

Its SKILL.md is about 2.8k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts. Compatibility notes: Requires a Git working tree.

It sits in Development, covering Pull requests and Commit messages. It works with Git. The repository describes itself as: Infrahub is a graph-based data management platform with built-in version control, CI workflows, peer review, and API access. It’s purpose-built to power reliable infrastructure… The licence is Apache-2.0.

When your agent uses it

  • : the user wants to commit
  • Check in the current changes
  • : opening a pull request → pr

Example prompts

  • “Use the commit skill to stage and commits the current changes onto a safe working branch, enforcing branch discipline and optionally pushing upstream”
  • “/commit”

Requirements

  • Compatibility (from SKILL.md): Requires a Git working tree.

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Assess Current State
  2. Branch Safety — Never Commit to a Protected or Placeholder Branch
  3. Stage Changes
  4. Draft the Commit Message
  5. Create the Commit
  6. Push Upstream (only when push argument is provided)

What it can do on your machine

Read from SKILL.md and the folder at commit af1c6c8. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • claude.ai

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

  • Compatibility

    Requires a Git working tree.

    From compatibility in the SKILL.md frontmatter.

Context cost

Commit loads about 2.8k tokens when it runs. Until then it costs about 66 tokens; SKILL.md has 1,579 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~66
When it runs · the whole SKILL.md, loaded when a task matches
~2.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NoteMentions a .env fileSKILL.md:63
    avoids accidentally committing secrets (`.env`, credentials, key files) or large/generated artefacts.
  • NoteMentions a .env fileSKILL.md:65
    staging any file that looks sensitive (`.env*`, `*secret*`, `*credential*`, `*.key`, `*.pem`) or generated/large (`node

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from opsmill/infrahub at commit af1c6c8, republished under its Apache-2.0 licence (© opsmill). 1,579 words, ~2,805 tokens.

Download SKILL.mdSave it as .claude/skills/commit/SKILL.md (or your agent's skills folder).
name
commit
description
Stages and commits the current changes onto a safe working branch, enforcing branch discipline and optionally pushing upstream. TRIGGER when: the user wants to commit, save, or check in the current changes. DO NOT TRIGGER when: opening a pull request → pr.
compatibility
Requires a Git working tree.
argument-hint
Optional `push` to push the branch upstream after committing.
metadata.version
0.1.0
metadata.author
OpsMill

Commit Changes

Introduction

Stage and commit the current changes onto a safe working branch. This skill enforces branch discipline: when the current branch is unsafe to commit to (the canonical rules live in step 2 below), it proposes a new fix/, feat/, docs/, etc. branch and switches to it after approval. It works equally well for brand-new work and for additional commits on an existing feature branch. If the user passes push, the branch is pushed upstream after the commit.

Arguments

<arguments> $ARGUMENTS </arguments>

Supported arguments:

  • push — After committing, push the branch upstream (git push -u origin <branch> on first push, otherwise git push).

Main Tasks

1. Assess Current State
  1. Run git status to see staged, unstaged, and untracked files.
  2. Run git branch --show-current to identify the current branch.
  3. Run git diff --stat and git diff --cached --stat to summarise the change footprint.
  4. If there are no changes to commit (working tree clean, nothing staged) — STOP and tell the user there's nothing to commit. Do not create an empty commit.
  5. If a merge, rebase, or cherry-pick is in progress (git status reports it, or .git/MERGE_HEAD / .git/rebase-* / .git/CHERRY_PICK_HEAD exist) — STOP and surface it to the user rather than committing into the middle of that operation.
2. Branch Safety — Never Commit to a Protected or Placeholder Branch

A branch is unsafe to commit to if any of the following hold:

  • It is the repository's default branch (resolve with git symbolic-ref refs/remotes/origin/HEAD --short 2>/dev/null | sed 's@^origin/@@', falling back to git remote show origin | sed -n 's/ *HEAD branch: //p').
  • It is a long-standing integration branch by name: main, master, stable, develop, dev, trunk.
  • It is a release branch: matches release/*, release-*, or is otherwise clearly named release-something (e.g. release-2026.05, releases/v3).
  • It is a placeholder / scratch branch generated by the harness or a worktree — specifically the auto-generated adjective-animal pattern (e.g. wary-cuckoo, lumbar-gorilla, wacky-otter, silent-fox), where the second word is an animal. These exist only to host a session and should not be committed to directly. Be careful not to over-match: legitimate two-word branches like dark-mode, rate-limit, cache-layer, or user-auth are real feature branches, not scratch branches. When a name is ambiguous (two hyphenated words but not clearly adjective-animal), do not assert it is unsafe — instead ask the user "this looks like it might be a generated scratch branch — is it, or is it a real branch you want to commit to?" and proceed on their answer.

If the current branch is unsafe by any of those rules:

  1. Do NOT commit on the current branch.
  2. Analyse the changes (diffs from step 1) to understand whether the work is a bug fix or new/extended behaviour.
  3. Propose a branch name using the conventional prefix that matches the change:
    • Bug fix → fix/<short-description> (e.g. fix/graphql-codegen-missing-types).
    • New feature or enhancement → feat/<short-description> (e.g. feat/add-commit-skill).
    • Docs-only, chore, refactor, etc. → mirror the conventional-commit type: docs/<…>, chore/<…>, refactor/<…>.
    • Use a concise kebab-case slug. If the repo has a visible naming convention in git branch -a or in AGENTS.md / CONTRIBUTING.md, follow that instead.
  4. Present the proposed branch name to the user and wait for explicit approval (the user may suggest a different name).
  5. After approval, create and switch to the branch: git checkout -b <branch-name>. The uncommitted changes carry across automatically.

If the current branch is already a real feature branch (i.e. not in any of the unsafe categories above), continue on it. Do not create a new branch unless the user explicitly asks for one.

3. Stage Changes
  1. Review what will be staged. Prefer adding files explicitly by path rather than git add -A or git add ., especially when untracked files are present — this avoids accidentally committing secrets (.env, credentials, key files) or large/generated artefacts.
  2. If staged changes already exist (the user pre-staged), respect that staging and only add additional files when it's clearly intended.
  3. Warn the user and require explicit confirmation before staging any file that looks sensitive (.env*, *secret*, *credential*, *.key, *.pem) or generated/large (node_modules/, build artefacts, dist/, __pycache__/, lockfiles changed unexpectedly).
4. Draft the Commit Message

Follow the repo's conventional-commit style (visible in git log):

  • Use a type prefix: feat:, fix:, refactor:, docs:, test:, chore:, ci:, etc.
  • Optional scope in parentheses: feat(backend): ..., fix(e2e): ....
  • Subject line under ~72 characters, imperative mood, no trailing period.
  • Focus on the why — what changed in terms of behaviour or capability, not a file list.
  • For multi-area changes, add a short body explaining the motivation.
  • Respect any repo or harness commit-trailer convention (e.g. a Co-Authored-By trailer the harness expects to append). Don't strip trailers that are already part of the project's workflow.
  • Never write a session-link trailer into the commit — strip it if the harness added one. Some harnesses append a line pointing at the private agent session, e.g. Claude-Session: https://claude.ai/code/session_… (or any trailer carrying a URL to an agent, chat, or coding session). These leak an internal, usually unshareable URL into the project's permanent — often public — git history, and they reference session state no future reader can open, so they're pure noise at best and a disclosure at worst. This is the one exception to "don't strip trailers" above: if the harness has inserted such a line, remove it before committing, and never author one yourself. Legitimate project trailers (Co-Authored-By, Signed-off-by, Reviewed-by, etc.) still stay.

Inspect the most recent ~20 commits with git log --oneline -20 and mirror the style you see (scope conventions, capitalisation, whether bodies are used). Generic examples:

  • fix: correct off-by-one in pagination cursor
  • docs: archive completed specs and extract durable knowledge
  • feat: add commit skill for safe branch discipline

Present the proposed commit message to the user before committing. Adjust based on feedback.

Show full SKILL.md (644 more words)Show less
5. Create the Commit

  1. Run git commit -m "<message>". For multi-line messages, use a HEREDOC:

    bash
    git commit -m "$(cat <<'EOF'
<subject>

<body>
EOF
)"

  2. Do NOT pass --no-verify — let pre-commit hooks run. If a hook fails:

    • Read the hook output carefully.
    • Fix the underlying issue (formatting, lint, etc.) rather than bypassing.
    • Re-stage the fixed files and create a NEW commit so each fix stays traceable. (Don't reach for --amend to absorb hook fixes — only amend a commit you deliberately intend to rewrite.)

  3. Run git status after the commit to confirm a clean tree and verify success.

  4. Run git log -1 --stat so the user can see what landed.

6. Push Upstream (only when push argument is provided)

Skip this phase entirely if push was NOT passed.

When push IS provided:

  1. Re-verify the branch is not unsafe per the rules in step 2 (defence in depth, though step 2 should have prevented this).
  2. Check whether the branch already tracks a remote:
    • git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null
  3. If no upstream exists: git push -u origin <branch-name>.
  4. If an upstream exists: git push.
  5. Never use --force or --force-with-lease unless the user explicitly asks for it. Regular git push will fail if the remote has diverged — surface that error to the user instead of overwriting.
  6. Report the push result and, if a remote URL is configured (git config --get remote.origin.url), the branch URL the user can open.

Notes

Branch Safety:

  • The canonical list of unsafe branches lives in step 2 — that is the single source of truth; don't re-derive it from memory.
  • If asked to override the rule, refuse and explain — the user can switch branches themselves first if they truly intend to commit there (in which case this skill no longer applies).

This is a discipline skill — hold the line under pressure. Refusing to commit to a protected branch is the whole point, and the excuses below will appear. None of them change where the commit should land:

Excuse / pressureReality
"It's urgent / it's an emergency, just commit to main."Urgency doesn't change where the commit lands. A feat//fix/ branch takes seconds and is just as fast to merge.
"Just this once, skip the branch."There is no "just once" — the rule exists precisely for the tempting one-off. Propose a branch.
"It's a tiny change, the branch is overkill."Size is irrelevant to branch safety; a one-line fix on main is still a direct commit to a protected branch.
"The hook is failing, just use --no-verify."Fix the violation instead. Bypassing the hook defeats its purpose.
"The remote diverged, just --force."Never force-push unless the user explicitly asks. Surface the divergence instead.

Red-flags self-check — if you catch yourself thinking any of these, STOP and re-read step 2:

  • "This branch is probably fine to commit to."
  • "I'll commit here and sort the branch out later."
  • "The user clearly wants this on main, so the rule doesn't apply."

Secret Hygiene:

  • Prefer explicit git add <path> over wholesale git add -A.
  • Warn before staging anything that looks like a secret or credential.
  • A session-link trailer (Claude-Session: / any agent-session URL) is a disclosure too — strip it from the commit message before committing, per step 4.

Hook Discipline:

  • Pre-commit hooks exist for good reasons. Fix violations rather than bypassing with --no-verify.

Idempotency:

  • Safe to invoke repeatedly. With no changes to commit, the skill exits cleanly without creating an empty commit.

Expected Outcome

  • All staged/unstaged changes that the user wanted to capture are committed on a safe working branch.
  • The branch is named meaningfully (existing real feature branch preserved, or a new fix/<…> / feat/<…> / docs/<…> / etc. name approved by the user).
  • The commit message follows the repo's existing conventional-commit style.
  • If push was provided, the branch is pushed upstream.
  • Every branch deemed unsafe in step 2 is left untouched in all cases.

© opsmill, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/commit of opsmill/infrahub.

Open the folder on GitHubat commit af1c6c8

Compare with similar skills

Commit next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Commit compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Commit this skillopsmill/infrahub529—~2.8kAutomated safety check: NotesApache-2.0
Git Workflow and Versioningaddyosmani/agent-skills102k2 repos~3.5kAutomated safety check: NotesMIT
React Router Pull Request Creatorremix-run/react-router57k—~2.5kAutomated safety check: PassMIT
Verdaccio Pull Request Workflowverdaccio/verdaccio18k—~1.9kAutomated safety check: PassMIT
Emoji Commit ConventionsbaptisteArno/typebot.io11k—~424Automated safety check: PassCustom licence
Draft Pull Request Creatorwordpress-mobile/WordPress-Android3.2k—~881Automated safety check: NotesGPL-2.0

Similar skills

  • Git Workflow and Versioning

    addyosmani/agent-skills

    Sets git habits for every change: short-lived branches, atomic commits with descriptive messages, clean pull requests, plus versioning, tagging and changelogs for releases.

    102k GitHub starsUsed in 2 repos~3.5k tokens
    DevelopmentAuto-check: notes

  • React Router Pull Request Creator

    remix-run/react-router

    Packages finished React Router work into a draft pull request: branch, commit, push, a written PR body and the right GitHub labels.

    57k GitHub stars~2.5k tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Verdaccio Pull Request Workflow

    verdaccio/verdaccio

    Takes a change through a verdaccio pull request: branch, local checks, changeset, title and body, labels, CI and review rounds, and ports to other release lines.

    18k GitHub stars~1.9k tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Emoji Commit Conventions

    baptisteArno/typebot.io

    Sets the repository's convention for commit messages and pull request titles: one emoji prefix for the main intent, a concise title and clean follow-up commits.

    11k GitHub stars~424 tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Draft Pull Request Creator

    wordpress-mobile/WordPress-Android

    Commits and pushes current changes, writes a pull request title and body from the branch history and template, and opens a draft PR on GitHub after you approve it.

    3.2k GitHub stars~881 tokensUpdated today
    DevelopmentAuto-check: notes

  • Submit PR

    tisfeng/Easydict

    创建或复用当前 checkout 已提交变更的 GitHub PR，必要时推送任务分支。PR 审查使用 review-pr；仅本地提交使用 git-commit。

    15k GitHub stars~595 tokensUpdated yesterday
    DevelopmentAuto-check passed

More from opsmill/infrahub

All 32 skills in this repo

  • Analyzing CI Flakiness

    opsmill/infrahub

    Analyzes recent CI failures on pull requests to identify flaky tests, using retry outcomes (failed attempt → green re-run) and cross-PR recurrence as evidence, and maintains a local longitudinal…

    529 GitHub stars~2k tokensUpdated today
    Auto-check passed

  • Audit Docs

    opsmill/infrahub

    Audits internal (dev/) and external (docs/) documentation completeness for a feature, subject, or set of existing docs, maps changes indicated by the user, across Infrahub's documentation layers…

    529 GitHub stars~1.5k tokensUpdated today
    Auto-check passed

  • Creating Changelog Entries

    opsmill/infrahub

    A skill your agent uses when you've fixed a bug, added a feature, or made any user-facing change in a project that uses Towncrier and need to record it for the changelog — before committing or…

    529 GitHub stars~1.9k tokensUpdated today
    Auto-check passed

  • Creating Issues

    opsmill/infrahub

    Turns a single feature idea, improvement, or bug into ONE well-structured GitHub issue.

    529 GitHub stars~1.2k tokensUpdated today
    Auto-check passed

  • Creating Prd

    opsmill/infrahub

    Synthesises the current conversation context into a Product Requirements Document and publishes it to GitHub (as a comment on a referenced issue, or a new issue).

    529 GitHub stars~4k tokensUpdated today
    Auto-check passed

  • Grilling Ideas

    opsmill/infrahub

    Stress-tests a fuzzy or vague feature idea before any PRD, spec, or ticket is written.

    529 GitHub stars~3.8k tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about Commit

What does Commit do?

Stages and commits the current changes onto a safe working branch, enforcing branch discipline and optionally pushing upstream. Commit is an agent skill from opsmill/infrahub. Stages and commits the current changes onto a safe working branch, enforcing branch discipline and optionally pushing upstream.

When should I use Commit?

Commit fits situations like: : the user wants to commit; check in the current changes; : opening a pull request → pr.

How do I install Commit in Claude Code?

Run `npx skills add opsmill/infrahub --skill commit -a claude-code`. Or copy the skill folder (.agents/skills/commit in opsmill/infrahub) into .claude/skills/commit in your project. Claude Code loads it when a task matches its description.

How do I install Commit in Codex?

Run `npx skills add opsmill/infrahub --skill commit -a codex`. Or copy the skill folder (.agents/skills/commit in opsmill/infrahub) into .agents/skills/commit in your project. Codex loads it when a task matches its description.

Can I use Commit in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add opsmill/infrahub --skill commit -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/commit, .gemini/skills/commit, .github/skills/commit and .opencode/skills/commit in your project.

What does Commit need to run?

Going by SKILL.md and its folder, Commit needs the command-line tools its instructions call (git). Compatibility (from SKILL.md): Requires a Git working tree..

Does Commit access the network?

SKILL.md names 1 domain. In commands or code: claude.ai; the agent is likely to contact it when it follows the instructions. This is read from the text; nothing was executed.

Is Commit safe to install?

Our automated static check of SKILL.md found notes only (mentions a .env file), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Commit use?

Commit is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Commit use?

About 2.8k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Commit?

Skills that share tags, products or a category with Commit: Git Workflow and Versioning (addyosmani/agent-skills, 102k stars), React Router Pull Request Creator (remix-run/react-router, 57k stars), Verdaccio Pull Request Workflow (verdaccio/verdaccio, 18k stars) and Emoji Commit Conventions (baptisteArno/typebot.io, 11k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Commit?

opsmill (a GitHub organization) maintains it in opsmill/infrahub, which has 529 GitHub stars. The repository holds 32 skills in this directory. The repository was last updated on October 7, 2026.

Source: opsmill/infrahub on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.