Token导航 LogoToken导航

Agent Skill · 开发

commit(提交)

commit 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

commit 是开发类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为需要联网;许可证为 MIT,第三方扫描有提醒项,按安装量在开发类的 21,746 个 Skill 里排第 15,154。

总安装 624周安装 26GitHub Stars 12下载 208核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:commit(提交)
来源仓库:https://github.com/sergio-bershadsky/ai
仓库路径:skills/commit
安装命令:
npx skills add https://github.com/sergio-bershadsky/ai --skill commit
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/sergio-bershadsky/ai --skill commit

这个 Skill 是做什么的

开发类 Skill 面向写代码、改代码和排查问题,一般会读写仓库文件,部分还会执行构建或测试命令。

用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息。适合在 Codex、Claude、Cursor、Gemini CLI 中围绕仓库状态、代码变更或协作事项进行整理。通过 npx skills add 命令从指定 GitHub 仓库安装并使用。

建议确认权限范围和维护状态,注意可能触发联网或文件读写操作。commit 属于开发类 Skill,可作为该场景下的辅助能力补充。

来源仓库内路径:skills/commit

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/sergio-bershadsky/ai --skill commit;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要需要联网,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

commit 怎么安装?

在终端执行 npx skills add https://github.com/sergio-bershadsky/ai --skill commit。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

commit 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

commit 需要什么权限?

权限级别是需要联网。该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

commit 是免费的吗?

来源标注的许可证是 MIT。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

commit 用的人多吗?

公开数据是累计安装 624 次,近一周安装 26 次,下载 208 次,GitHub 12 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

commit 安全吗?

第三方扫描有提醒项,说明存在需要人工确认的行为。安装前请打开源码看清它读了什么、联网到哪里。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 3 个目录同时收录,说明这个 Skill 流传比较广。
  • 许可证明确为 MIT,商用和分发边界好判断。

先想清楚的地方

  • 第三方扫描存在提醒项或未通过项,需要人工逐条确认。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理开发类任务、又不想每次都手写提示词的人。

不太适合

  • 需要厂商级技术支持和 SLA 的生产系统。

开发类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
skill-vetter

技能审查员 · OpenClaw

8,779,018986操作浏览器MIT-0通过
ontology

本体论 · OpenClaw

6,636,960576只读MIT-0通过
entra-app-registration

内部应用程序注册 · Codex、Claude

6,631,872764接触敏感数据未明确通过
entra-app-registration

内部应用程序注册 · Codex、Claude

3,757,680201接触敏感数据未明确通过
nano-banana-pro

纳米香蕉专业版 · OpenClaw

3,526,898364接触敏感数据MIT-0有提醒
commit

提交 · 本页

62412需要联网MIT有提醒

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

Commit Skill

Create conventional commits with branch protection, semantic correlation, and user confirmation.

When to Use

  • After completing a task or logical unit of work
  • When the user requests a commit
  • After significant documentation updates
  • After implementing a feature or fix
  • When the user says they're "done", "finished editing", or wants to "wrap up"

Procedure

Step 1: Gather Changes

git status
git diff --stat
git diff --cached --stat

If there are no changes (nothing staged, modified, or untracked), inform the user and stop.

Step 2: Branch Safety Check (mandatory)

Detect the current branch and the default branch:

git symbolic-ref --short HEAD
git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null || echo ""

If refs/remotes/origin/HEAD is not set, check whether main or master exists as fallback.

If on the default branch:

  1. Warn the user: "You're committing directly to <default-branch>. Consider creating a feature branch."
  2. Run Step 3 (Ticket Tracking) to check for an associated ticket before proposing a branch.
  3. Detect the repo's branch naming convention by inspecting existing branches: git branch -a --format='%(refname:short)'
  4. Analyze naming patterns:

- Separator style: / vs - vs _ - Type prefixes: feat, fix, chore, docs, etc. - Nested patterns: user/type/desc, type/desc - Issue ID patterns: PROJ-123-desc - Default to type/short-description if no clear pattern found

  1. Propose a new branch name following the detected convention. If a ticket was found/created in Step 3, incorporate the ticket ID into the branch name (e.g., feat/PROJ-123-add-auth).
  2. Ask user to: confirm the proposed name, suggest an alternative, or continue on the default branch

If the user chooses to create a branch, run:

git checkout -b <branch-name>

Step 3: Ticket Tracking (when on default branch or no ticket in branch name)

Detect whether the project uses a ticket tracking system and ensure changes are associated with a ticket.

Detection — check for ticket system indicators (in order):

  1. GitHub/GitLab Issues — Check if remote is GitHub/GitLab: git remote get-url origin If GitHub: use gh issue list --limit 5 --state open to confirm issues are enabled. If GitLab: note that GitLab issues are likely available.
  2. Jira — Look for Jira-style ticket IDs in existing branch names ([A-Z]+-\d+ pattern like PROJ-123). Check for .jira config or Jira URL references in the repo.
  3. Linear — Check for Linear-style IDs in branches ([A-Z]+-\d+ with short prefixes like ENG-123). Check for linear references in the repo.
  4. No ticket system detected — Skip this step entirely and proceed.

If a ticket system is detected:

  1. Check if the current changes are already associated with a ticket:

- Parse the current branch name for a ticket ID - If on default branch, there is no ticket association

  1. If no ticket is associated, analyze the changes (from Step 1) to understand their nature, then:

- Warn: "This project uses [system] for tracking. No ticket is associated with these changes." - Propose creating a ticket first: - Draft a ticket title and description based on the changes - For GitHub: offer to run gh issue create --title "..." --body "..." - For other systems: show the suggested title/description and ask user to create it manually - Ask user to: create the ticket, provide an existing ticket ID, or skip (commit without ticket)

  1. If user provides or creates a ticket, use the ticket ID when constructing the branch name in Step 2.

Step 4: Semantic Correlation (feature branches only)

Only when on a feature branch (not the default branch):

  1. Parse the branch name into tokens (split on /, -, _)
  2. Compare tokens against the nature of the changes (file paths, change type, scope)
  3. If there is zero semantic overlap between branch name and changes, warn: "Changes appear to be about X, but branch branch-name suggests Y. Continue?"
  4. Wait for user confirmation before proceeding

Step 5: Analyze Changes

Identify:

  • Files modified, added, or deleted
  • Type of change (feat, fix, docs, refactor, style, test, chore)
  • Scope (which module/area affected)
  • Breaking changes (if any)

Step 6: Draft Commit Message

Use conventional commits format:

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

<body with details>

<footer>

Types:

  • feat: New feature
  • fix: Bug fix
  • docs: Documentation only
  • refactor: Code change that neither fixes a bug nor adds a feature
  • style: Formatting, missing semicolons, etc.
  • test: Adding or updating tests
  • chore: Maintenance tasks, dependencies

If a ticket was associated in Step 3, include it in the footer (e.g., Closes #123 or Refs: PROJ-123).

Step 7: Show Diff and Confirm

Before committing, ALWAYS:

  1. Show the staged diff (or unstaged diff if nothing is staged yet):
git diff --staged
  1. Show the proposed commit message
  2. Ask: "Ready to commit these changes? (yes/no)"
  3. Wait for explicit user approval

Step 8: Execute Commit (only after approval)

Stage files — prefer specific files over git add -A:

git add <specific-files>
git commit -m "<message>"

Step 9: Verify

git log -1 --stat

Rules

  1. NEVER push — Only commit locally, never run git push
  2. ALWAYS confirm — Never commit without explicit user approval
  3. Show diff first — User must see changes before approving
  4. One logical unit — Each commit should represent one complete change
  5. Conventional format — Always use type(scope): description format
  6. Branch safety — Always check if on default branch before committing
  7. Ticket alignment — If project has ticket tracking, ensure changes are associated with a ticket
  8. Semantic alignment — Warn if changes don't match branch purpose
  9. Proactive suggestion — After completing edits, suggest committing

Output Format

## Proposed Commit

**Branch:** feat/add-auth
**Type:** feat
**Scope:** auth
**Files:**
- src/auth/reset.ts (new)
- src/components/ResetForm.tsx (new)
- src/api/routes.ts (modified)

**Message:**
feat(auth): add password reset flow

- Add forgot password endpoint
- Implement email verification token
- Add password reset form component

Closes #123

**Diff summary:**
3 files changed, 245 insertions(+)

---
Ready to commit these changes?

平台分布

windsurf

29.75%
按下载量换算62

OpenCode

23.68%
按下载量换算49

Codex

15.45%
按下载量换算32

Claude Code

11.18%
按下载量换算23

Antigravity

6.82%
按下载量换算14

Gemini CLI

3.64%
按下载量换算8

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

可疑

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在提醒或未通过项,安装前请自行复核。

继续浏览同类 Skills