Token导航 LogoToken导航

Agent Skill · 待分类

commit-work(提交工作)

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

commit-work 是待分类类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为只读;许可证信息还不明确,第三方扫描已通过,按安装量在待分类类的 11,209 个 Skill 里排第 2,652。

总安装 1,458周安装 59GitHub Stars 7下载 458核验 2026-05-01

安装说明

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

安装方式

通过对话安装

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

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

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/nesnilnehc/ai-cortex --skill commit-work

这个 Skill 是做什么的

这个 Skill 的分类还没最终确定,用法以来源仓库的说明为准。

用于处理 GitHub 仓库、Issue、Pull Request 等代码协作信息。适合在 Codex、Claude、Cursor、Gemini CLI 中围绕仓库状态或代码变更进行整理。可结合来源仓库和原始 README 进一步核验具体用法和功能边界。

安装前建议确认权限范围和项目维护状态,避免触发不必要的联网或命令执行。注意该技能可能涉及文件读写,操作前请确保有足够的安全检查和备份措施。

来源仓库内路径:skills/commit-work

上手步骤

4 步
  1. 1

    确认自己的宿主工具

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

  2. 2

    拿到安装命令

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

  3. 3

    安装后重启宿主

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

  4. 4

    按最小权限试用

    它标注为只读,先用只读任务试一次,确认行为符合预期再扩大使用范围。

常见问题

6 条

commit-work 怎么安装?

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

commit-work 支持哪些 AI 工具?

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

commit-work 需要什么权限?

权限级别是只读。该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

commit-work 是免费的吗?

公开资料没有标注明确许可证,收费和商用限制都无法确认。正式使用前请到来源仓库核对授权说明。

commit-work 用的人多吗?

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

commit-work 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

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

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 第三方扫描已通过,常见的高风险行为没有命中。
  • 标注为只读权限,试用阶段不容易误改本地文件。

先想清楚的地方

  • 许可证没有明确标注,能不能商用、能不能再分发都不确定。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理待分类类任务、又不想每次都手写提示词的人。
  • 只想先试试效果、不希望它改动本地文件的人。

不太适合

  • 需要明确授权才能用到公司项目里的场景。
  • 需要厂商级技术支持和 SLA 的生产系统。

待分类类 Skill 对比

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

infsh CLI · Codex、Claude

4,374,576382权限未标注未明确未收录
ai-video-generation

AI 视频生成 · Codex、Claude

4,313,376382调用外部服务未明确有提醒
lark-openapi-explorer

云雀 OpenAPI 浏览器 · Codex、Claude

2,064,1209,011需要联网未明确有提醒
lark-workflow-standup-report

Lark 工作流程站立报告 · Codex、Claude

2,041,6328,978需要联网未明确通过
use-my-browser

使用我的浏览器 · Codex、Claude

1,848,49140操作浏览器未明确未通过
commit-work

提交工作 · 本页

1,4587只读未明确通过

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

SKILL.md 原文

技能(Skill):承诺工作

目的 (Purpose)

通过确保仅包含预期的更改、提交的逻辑范围以及提交消息清楚地描述更改的内容和原因,使提交易于审查且安全交付。该技能使用技能规范集成了项目的 AI Cortex 治理标准。


核心目标(Core Objective)

首要目标:生成一个或多个 git 提交,其中包含清晰的消息、逻辑范围和经过验证的质量,可供推送。

成功标准(必须满足所有要求):

  1. ✅ 已审查的更改:在暂存之前运行“git diff”,在每次提交之前运行“git diff --cached”
  2. ✅ 逻辑范围:每次提交仅包含相关更改;不相关的更改分为单独的提交
  3. ✅ 常规提交格式:所有提交消息均遵循 type(scope):summary 格式,正文清晰
  4. ✅ 质量验证:运行适当的测试、lint 或构建命令并且所有检查均已通过
  5. ✅ 无敏感数据:不包含秘密、令牌、调试代码或意外更改
  6. ✅ 注册表同步(AI Cortex 项目):如果技能/更改,则 INDEX.md 和 manifest.json 都会更新

验收测试:审阅者是否可以仅从提交消息中了解更改的内容以及原因,而无需阅读差异?


范围边界(范围边界)

本技能负责:

  • 审查未提交的更改
  • 将混合更改拆分为逻辑提交
  • 需要时使用补丁模式进行暂存更改
  • 编写常规提交消息
  • 运行预提交质量检查
  • 同步 AI Cortex 注册表(INDEX.md、manifest.json)

本技能不负责:

  • 现有提交的代码审查(使用“review-diff”技能)
  • 重写 git 历史记录或变基(使用 git rebase 命令)
  • 解决合并冲突(使用 git merge/rebase 工作流)
  • 创建拉取请求或推送到远程(单独的工作流)

转交点:当所有变更都提交并验证后,移交给推送/PR 工作流或下一个开发任务。

使用场景(用例)

  • 用户要求提交工作、阶段更改或制作提交消息
  • 需要将混合更改拆分为逻辑的、可审查的提交
  • 创建遵循常规提交格式的提交
  • 在推动之前确保提交符合项目质量标准
  • 在AI Cortex项目中工作,其中INDEX.md和manifest.json必须保持同步

行为(行为)

工作流程(清单)

若存在 CLAUDE.md 或 .ai-cortex/config.yaml,优先读取其中的 test_command 用于质量验证;否则从项目构建配置推断。参见 docs/guides/project-config.md。

  1. 在登台前检查工作树

- 运行git status - 运行“git diff”(未暂存的更改) - 如果有很多更改:git diff --stat 进行概述

  1. 运行预提交审查(AI Cortex 增强)

- 调用“review-diff”技能来检查: - 意外的更改或调试代码 - 安全问题或泄露的秘密 - 重大更改或兼容性问题 - 在进行分期之前解决发现的问题

  1. 决定提交边界(如果需要则分割)

- 按逻辑问题划分: - 功能与重构 - 后端与前端 - 格式与逻辑 - 测试与生产代码 - 依赖性颠簸与行为改变 - 如果更改混合在一个文件中,则计划使用补丁暂存

  1. 仅暂存属于下一次提交的内容

- 更喜欢混合更改的补丁暂存:git add -p - 要取消暂存块/文件: git restore --staged -p 或 git Restore --staged <path> - 阶段相关的变化一起

  1. 审查实际要提交的内容

- 运行“git diff --cached” - 健全性检查: - 没有秘密或代币 - 没有意外的调试日志记录 - 没有不相关的格式改动 - 没有注释掉的代码块

  1. 用 1-2 句话描述阶段性变化

- 回答:“什么改变了?” +“为什么?” - 如果你不能清楚地描述它,则提交可能太大或混合;返回步骤 3

  1. 写入提交消息

- 使用常规提交(必需):

     type(scope): short summary

     body (what/why, not implementation diary)

     footer (BREAKING CHANGE) if needed

- 更喜欢多行消息的编辑器:git commit -v - Use references/commit-message-template.md if helpful - 保持摘要的必要性和具体性(“添加”、“修复”、“删除”、“重构”)

8) 运行最小相关验证 - 在继续之前运行存储库最快的有意义的检查(单元测试、lint 或构建) - 确保提交不会破坏现有功能

9) 如果需要,同步注册表(仅限 AI Cortex 项目) - 如果提交影响 skills/ 目录: - 验证“skills/INDEX.md”是否已更新为新的/更改的技能 - 验证“manifest.json”功能数组是否已更新 - 如果添加、删除或重大更改了技能,则验证 manifest.json 与 INDEX 已同步 - 运行“scripts/verify-registry.mjs”(如果存在) - 如果添加或移动技能,INDEX、清单和(根据需要)场景地图必须一起更新

10) 重复下一次提交,直到工作树干净

交互(互动)政策

  • 询问用户是否想要单个或多个提交(默认:针对不相关的更改进行多个小提交)
  • 确认提交风格需求(该技能需要常规提交)
  • 询问任何特定于项目的规则:最大主题长度、所需范围等。
  • 对于 AI Cortex 项目:确认是否运行注册表同步检查

输入与输出 (Input & Output)

输入(输入)要求

  • 包含未提交更改的 git 存储库
  • 用户意图:应该致力于哪些工作
  • 可选:提交样式首选项、范围规则

产出(Output)合约

提供:

  • 最终提交消息,包含类型、范围和清晰的描述
  • 每次提交的简短摘要,解释发生了什么变化以及原因
  • 用于暂存和审查的命令(至少:git diff --cached)
  • 运行任何测试或验证命令
  • 对于 AI Cortex 项目:确认 INDEX.md、manifest.json 已同步

限制(限制)

硬边界(Hard Boundaries)

  • 在未审查分阶段更改的情况下不要提交(git diff --cached)
  • 不要在一次提交中混合不相关的更改
  • 不要编写模糊的提交消息(“修复内容”、“更新”、“WIP”)
  • 如果测试或 linter 可用,请勿跳过验证步骤
  • 不要提交秘密、令牌或敏感数据
  • 对于 AI Cortex 项目:在未更新 INDEX.md、manifest.json 的情况下,请勿提交技能更改

技能边界 (Skill Boundaries)(避免重叠)

不要做这些(其他技能可以处理它们):

  • 现有提交的代码审查:审查已提交的差异 → 使用“review-diff”技能
  • Git 历史重写:变基、压缩、修改旧提交 → 直接使用 git rebase/amend 命令
  • 合并冲突解决:解决合并/变基期间的冲突 → 使用 git merge/rebase 工作流程
  • 拉取请求创建:创建 PR、请求审查、管理 PR 工作流程 → 使用特定于平台的 PR 工具
  • 代码实施:编写正在提交的代码更改→使用开发/实施技能

何时停止并交接:

  • 用户问“你能审查这个提交吗?” → 对现有提交使用“review-diff”技能
  • 用户问“你能推这个吗?” → 提交完成,移交推送/公关工作流程
  • 用户问“你可以重新调整这些提交的基础吗?” → 提交完成,移交给 git rebase 工作流程
  • 提交并验证所有更改 → 技能完成,准备好推送或下一个任务

自检(Self-Check)

核心成功标准(必须满足所有标准)

  • [ ] 已审查的更改:在暂存之前运行“git diff”,在每次提交之前运行“git diff --cached”
  • [ ] 逻辑范围:每次提交仅包含相关更改;不相关的更改分为单独的提交
  • [ ] 常规提交格式:所有提交消息均遵循“类型(范围):摘要”格式,正文清晰
  • [ ] 质量验证:运行适当的测试、lint 或构建命令并且所有检查均已通过
  • [ ] 无敏感数据:不包含秘密、令牌、调试代码或意外更改
  • [ ] 注册表同步(AI Cortex 项目):如果技能变更,则更新 INDEX.md、manifest.json

流程质量检查

  • [ ] 提交前审查:为 AI Cortex 项目运行“review-diff”技能,以检查是否存在意外更改、安全问题或重大更改
  • [ ] 使用补丁暂存:当更改混合在单个文件中时使用git add -p
  • [ ] 提交边界清晰:可以用 1-2 句话描述每个提交的目的
  • [ ] 消息质量:摘要是必要且具体的;正文解释了内容和原因(不是实现细节)
  • [ ] Breaking changes marked: Used ! or BREAKING CHANGE: footer if applicable
  • [ ] 记录的命令:列出用于暂存、审查和验证的命令

验收测试

审阅者可以仅从提交消息中了解更改的内容和原因,而不阅读差异吗?

如果否:提交消息不清楚。修改消息以解释内容和原因。

如果是:提交已准备好推送。

示例(示例)

示例 1:简单的功能添加

场景:向 utils.js 添加新函数

命令:

git status
git diff
# Review shows only the new function, no other changes
git add utils.js
git diff --cached
# Verify staged changes are correct
npm test
git commit -m "feat(utils): add formatDate helper function

Add formatDate to handle ISO 8601 date formatting consistently
across the application. Returns formatted string or null for
invalid inputs."

输出:

  • 提交:feat(utils):添加 formatDate 辅助函数
  • 摘要:添加了日期格式化实用程序以集中日期处理逻辑
  • 命令:git diff、git diff --cached、npm test

示例 2:需要拆分的混合更改(边缘情况)

场景:修改了 auth.js,修复了错误并进行了重构,并更新了测试

命令:

git status
git diff --stat
# Shows auth.js and auth.test.js changed

# Run review-diff first (AI Cortex)
# [review-diff identifies: bug fix in line 45, refactor in lines 100-150]

# Split into logical commits
# Commit 1: Bug fix only
git add -p auth.js
# Select only the bug fix hunk
git diff --cached
npm test
git commit -m "fix(auth): prevent null pointer in token validation

Check for null token before accessing properties to avoid
runtime errors when token is missing."

# Commit 2: Refactor
git add -p auth.js
# Select refactor hunks
git diff --cached
npm test
git commit -m "refactor(auth): extract token parsing to separate function

Move token parsing logic into parseAuthToken() for better
testability and reuse across auth module."

# Commit 3: Tests
git add auth.test.js
git diff --cached
npm test
git commit -m "test(auth): add tests for token validation edge cases

Cover null token, malformed token, and expired token scenarios."

输出:

  • 提交 1:“修复(auth):在令牌验证中防止空指针” - 修复了令牌为空时的崩溃
  • 提交 2:“重构(auth):将令牌解析提取到单独的函数” - 改进的代码组织
  • 提交 3:“测试(auth):添加令牌验证边缘情况的测试” - 增加测试覆盖率
  • 命令:git add -p、git diff --cached (×3)、npm test (×3)

示例 3:AI Cortex 技能添加(边缘情况)

场景:为 AI Cortex 项目添加新技能“analyze-logs”

命令:

git status
# Shows: skills/analyze-logs/SKILL.md (new), skills/INDEX.md (modified), manifest.json (modified)

git diff skills/INDEX.md
git diff manifest.json
# Verify both registries reference the new skill correctly

git add skills/analyze-logs/
git add skills/INDEX.md
git add manifest.json
git diff --cached

# Run registry verification
node scripts/verify-registry.mjs
# ✓ INDEX.md and manifest.json are synchronized

npm test
git commit -m "feat(skills): add analyze-logs skill for log parsing

Add new skill to parse and analyze application logs with pattern
matching and error extraction. Includes examples for common log
formats.

Updated INDEX.md and manifest.json to register the new skill."

输出:

  • 提交:feat(skills):添加分析日志技能以进行日志解析
  • 摘要:添加了带有注册表同步的日志分析功能
  • 命令:git diff --cached、node script/verify-registry.mjs、npm test
  • 注册表同步:✓ INDEX.md 和 manifest.json 均已更新

附录:输出合约

该技能会产生副作用输出(git 提交)和报告。输出报告必须包括:

元素要求
提交消息常规提交格式:类型(范围):主题 + 正文 + 可选页脚
每次提交摘要一句话:改变了什么以及为什么改变
使用的命令最小值:git diff --cached;包括暂存和验证命令
注册表同步对于 AI Cortex 项目:确认 INDEX.md、manifest.json 已同步

报告示例:

  • 提交:feat(utils):添加 formatDate 辅助函数
  • 摘要:添加了日期格式化实用程序以集中日期处理逻辑
  • 命令:git diff、git diff --cached、npm test

平台分布

Codex

36.95%
按下载量换算169

Claude

32.9%
按下载量换算151

Cursor

18.48%
按下载量换算85

Gemini CLI

9.62%
按下载量换算44

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills