一键导入
git-commit-helper
Create well-structured git commits from analyzed changes. Use when the user asks to commit, save work, or create a commit.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Create well-structured git commits from analyzed changes. Use when the user asks to commit, save work, or create a commit.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Write, refactor, restructure, edit, or audit technical documentation using the Diátaxis framework (tutorials, how-to guides, reference, explanation). Produces clear, concise, scannable docs and fights the default tendency toward bloated, over-explained AI prose. Use this skill for ANY documentation work — README and CONTRIBUTING files, API/reference docs, runbooks, guides, getting-started pages, conceptual write-ups, docs-site content, or doc reviews — even when the user just says "document this," "write docs for X," "clean up these docs," "explain how this works in the docs," or "what's missing from our documentation." If the deliverable is documentation, reach for this skill rather than writing prose freehand.
Retroactively create Linear tickets and PRs from untracked commits. Use for commits without tickets, "founder mode", or formalizing experimental work.
Find architectural friction and propose deep-module refactors as RFC issues. Use to improve architecture, find refactoring opportunities, or deepen shallow modules.
Initialize the AI Engineering Harness (AGENTS.md + thoughts/ structure). Use on /init_harness or when setting up the harness in a repo.
Interview the user relentlessly to stress-test a plan or design. Use to validate design decisions, "drill in", or "ask me questions" before implementation.
Observability Driven Development (ODD) — design the trace before the feature. Use for "ODD", "instrument first", "telemetry-driven", or a local OTel feedback loop with the Aspire dashboard.
| name | git-commit-helper |
| description | Create well-structured git commits from analyzed changes. Use when the user asks to commit, save work, or create a commit. |
| allowed-tools | Read, Bash, Grep, Glob |
Run in parallel to understand the changes:
git status # changed files
git diff # unstaged modifications
git diff --staged # staged changes
git log --oneline -n 5 # recent commit style
Show the user before executing, then wait for confirmation:
I plan to create [N] commit(s) with these changes:
Commit 1:
Files: [specific files]
Message: [proposed message in imperative mood]
[Commit 2, 3, ... if multiple]
Shall I proceed?
# Add files explicitly by path — NEVER use `git add -A`, `git add .`, or `git commit -a`
git add path/to/file1.ts path/to/file2.ts
git commit -m "Add social login support"
git log --oneline -n [number of commits created]
Format: [Imperative verb] [what] [optional: why] with an optional detailed body.
Add user authentication to API endpoints, Fix race condition in event processingUpdated stuff, Fixed bug, Changes, WIPUse imperative mood ("Add", not "Added"/"Adding"). When the "what" isn't obvious from the diff, explain the "why" — e.g. Use Redis for rate limiting to support distributed deployment.
Multi-change example:
git add src/feature.ts src/feature.test.ts docs/feature.md
git commit -m "Add user analytics feature
- Implement tracking service
- Add unit tests
- Update documentation"
NEVER add co-author info, Co-Authored-By lines, or "Generated with Claude"-style messages. Write commit messages as if the user wrote them — authored solely by the user with no AI attribution.
You have full context of this session — use it to write meaningful messages. The user asked you to commit, so trust your judgment and don't ask unnecessary questions.
git status clean): tell the user there is nothing to commit.This skill does not push. It creates clean, atomic commits with the user's approval, and all git operations are shown transparently.