Token导航 LogoToken导航TokenDH.com
研究检索敏感数据github未标认证来源可访问clear审计未展示

git-commitGit 提交

Agent Skill

git-commit 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

321

周安装

13

GitHub Stars

公开资料未说明

下载量

101
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

MIT

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

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

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

命令行安装

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

AgentSkills.tonpx skills
npx skills add lukasstrickler/ai-dev-atelier --skill "git-commit"

简介

用于查找与筛选 Git 提交相关 AI 代理技能的搜索工具。

  • 适用于 Codex、Claude、Cursor、Gemini CLI 环境。
  • 根据任务场景返回候选技能建议。
  • 安装前请核实仓库维护状态。git-commit 属于研究检索类 Skill,可作为该场景下的辅助能力补充。
  • 可能涉及本地 Git 操作,需确保文件系统权限。

SKILL.md

name
git-commit
description
Write clear git commits with Conventional Commits format. Detects project conventions from history and config. Guides commit granularity. Use when: (1) Completing working code, (2) Code builds and tests pass, (3) Ready to save, (4) Before pushing, (5) After review feedback. Triggers: automatically when finishing commitable work that builds and passes tests.
metadata
author
ai-dev-atelier
version
1.0

Git Commit

Write clear, atomic commits. Detect and match project conventions first; use Conventional Commits as fallback. Every commit = one complete, working change.

Feature Branch Workflow

Philosophy: Commit early, commit often.

Feature branch: Create → [Change → Test → COMMIT]* → PR → Merge

Why frequent commits matter:

BenefitDescription
Easy rollbackRevert to last working state in seconds
Safety checkpointsNever lose more than one small step
Better debugginggit bisect works with granular history
CollaborationOthers see incremental progress
AutomationEnables auto-changelogs and semantic versioning

Anti-pattern: One giant commit at end of feature (47 files, 2800+ lines). Split into logical increments instead.

Quick Start

Pre-Commit Checklist:

  • [ ] Code builds and tests pass
  • [ ] ONE logical change (describable in one sentence)
  • [ ] Checked project conventions (Step 1)

Workflow

Step 1: Detect Conventions (REQUIRED)

ls .commitlintrc* commitlint.config.* .czrc .cz.json 2>/dev/null
git log --oneline -15
FindingAction
Config file existsFollow those rules exactly
feat:, fix: patternUse Conventional Commits
[JIRA-123] patternMatch ticket prefix format
Component: message patternMatch component prefix format
No clear patternUse Conventional Commits (Step 2)

Step 2: Format Message

<type>(<scope>)!: <subject>     ← 50 chars ideal, 72 max
                                ← blank line
<body>                          ← wrap at 72 chars, optional
                                ← blank line
<footer>                        ← optional (Closes #123, BREAKING CHANGE)

Subject rules: Imperative mood (add not added), lowercase after colon, no trailing period, no filler words.

Types:

TypePurposeSemVerExample
featNew featureMINORfeat(auth): add OAuth
fixBug fixPATCHfix(cart): prevent neg qty
docsDocumentation-docs(api): add examples
styleFormatting-style: fix indentation
refactorCode restructure-refactor: extract helper
perfPerformance-perf(db): add index
testTests-test(auth): add edge cases
buildBuild/deps-build: update webpack
ciCI config-ci: add deploy workflow
choreMaintenance-chore: update gitignore
revertRevert previous commit-revert: let us not...

Breaking changes: Add ! after type/scope, explain in body/footer.

feat(api)!: require API key for all endpoints

BREAKING CHANGE: Anonymous access removed. All requests need X-API-Key header.

Step 3: Body (When Needed)

RequiredOptional
Breaking change (impact/migrate)Self-explanatory from diff
Non-obvious fix (root cause)Simple docs/style/chore
Complex feature (design decision)Tests with descriptive names

Body content: WHY (motivation), WHAT problem, HOW users affected. Not: Which files (diff shows), line-by-line explanation (code comments).

Step 4: Footer

Closes #123                              # Issue reference
Fixes #456                               # Also closes issue
Refs: #789                               # Reference without closing
BREAKING CHANGE: <description>           # If not in body
Co-authored-by: Name < [email protected] > # Co-authorship
Reviewed-by: Name                        # Use hyphens in tokens

Commit Granularity

Atomic Commit = Smallest Complete Change

  1. ONE purpose - single feature/fix/refactor
  2. Self-contained - doesn't depend on uncommitted work
  3. Leaves code working - builds pass, tests pass
  4. Revertable alone - without breaking other features

What Goes Together vs Separate

Together (same commit)Separate (different commits)
Feature + its unit testsFeature + unrelated formatting
Bug fix + regression testBug fix + dependency update
API change + docs updateRefactor + new feature
Refactor + affected testsMultiple unrelated fixes

When to Commit (Triggers)

TriggerAction
Function works and testedCOMMIT now
Test passes (red → green)COMMIT now
Bug fixed and verifiedCOMMIT before next task
About to refactorCOMMIT working state first
Starting new sub-taskCOMMIT current progress
End of session / before pullCOMMIT if working

Key: Before starting new task, commit all current task changes.

When NOT to Commit

SituationWhy
Code doesn't buildBreaks bisect, blocks others
Tests failing*Not a valid checkpoint
"I think this works" (untested)Verify first, commit second
Mid-debugging / mid-fixWait until fix is complete
Uncertain about approachPrototype first, commit when solid
CI still running / redWait for green, then commit fix

*_Exception: TDD RED commits (test-only commits that intentionally fail) are valid._

"Commit often" means verified working increments, not untested guesses.

❌ BAD: Commit-and-pray workflow
───────────────────────────────
1. Write fix
2. "Looks right to me" → commit
3. Push → CI fails
4. "Oops, forgot X" → commit again
5. Push → CI fails again
6. Repeat 3 more times...
Result: 5 broken commits in history

✓ GOOD: Verify-then-commit workflow
───────────────────────────────
1. Write fix
2. Run tests locally → fails
3. Fix the issue
4. Run tests locally → passes
5. Commit
6. Push → CI passes
Result: 1 clean commit

Rule: If CI or local tests are red, you're not done. Fix first, verify, then commit.

TDD Pattern

test(auth): add failing test for validation  # RED
feat(auth): implement validation             # GREEN
refactor(auth): extract to helper            # REFACTOR

Examples

See references/examples.md for comprehensive examples. Quick reference:

# Feature with context
feat(auth): add password strength indicator

Users lacked feedback on password quality during signup.
Add real-time strength meter, requirements checklist, submission block.

Closes #234
# Bug fix with root cause
fix(api): handle null response from payment gateway

Gateway returns null on timeout. Add null check with retry logic.

Fixes #567
# Simple changes (no body needed)
docs(readme): add Docker installation steps
test(utils): add edge case tests for date parser
chore(deps): update lodash to 4.17.21
BadProblemGood
fix bugNo contextfix(cart): prevent duplicate items
update codeMeaninglessrefactor(api): simplify errors
WIPIncompleteFinish work, then commit
misc fixesMultiple changesSplit into separate commits

Integration

WhenSkillWhy
Before committingcode-qualityEnsure checks pass
After committingdocs-checkCheck if docs need update
After PR reviewpr-reviewgit-commitResolve then commit

References

  • references/examples.md - Extended examples by scenario

Output

Git commits created via standard git commands. No files saved. Commit history visible via git log.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

04

需要参考平台分布和安装热度时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Claude Code

30.72%
按下载量换算31

kilo

24.78%
按下载量换算25

Gemini CLI

19.65%
按下载量换算20

Antigravity

11.6%
按下载量换算12

mcpjam

7.97%
按下载量换算8

command-code

3.56%
按下载量换算4

安全审计

暂无安全审计结果可展示。

权限和风险

敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

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

来源信息

继续浏览同类 Skills