一键在 Manus 中运行任何 Skill

commit

星标1

分支0

更新时间2026年2月22日 05:10

Generate a Conventional Commit message and perform a git commit for staged changes. Use when the user asks to commit changes, wants a commit message, or needs Conventional Commits guidance.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

madflojo

madflojo/dotfiles

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Perform a Git Commit for Staged Changes

Tooling

Viewing Staged Changes

Use:

git --no-pager diff --staged

If changes are not staged, ask the user to stage them or if they want to stage all changes with:

git add .

Committing Changes

Commit non-interactively by reading the message from stdin (safe with !, quotes, backticks, and newlines):

git commit -F - <<'EOF'
<type(scope): subject>

<body (optional)>
EOF

Avoid passing commit messages via -m when the message may contain !, quotes, backticks, backslashes, or newlines.

Rules

If change is trivial (e.g., <100 lines changed, small edits), generate a single-line commit.
If change is non-trivial, allow a concise multi-line commit.
Always follow Conventional Commits format including adding issues, user stories, tasks, or defects references if available.
Limit subject line to 100 characters max.

Style

Never start with an emoji; one emoji at the end of the subject is OK.
Add a touch of contextual humor (just enough for a chuckle, but still relevant and professional).
Title/subject: optionally append a single emoji at the end; Body: keep total emojis subtle (generally ≤2).
If you’re forced to inline a message in a shell command, avoid shell-problematic characters (especially !). Otherwise prefer the stdin-based commit flow above.

同仓库更多 Skills

同仓库

learn-this

madflojo/dotfiles

Learn a project quickly by reading docs, code, configs, and tests to summarize purpose, architecture, tech stack, and conventions. Use at the start of a task or when the user asks for a repo overview.

2026-02-221

open-pr

madflojo/dotfiles

Review current-branch changes and open a GitHub pull request using gh. Use when the user asks to open/create a PR, prepare a PR title/body, or summarize changes for review.

2026-02-221

go-style-guide

madflojo/dotfiles

Go engineering style guide for designing packages, services, and CLIs. Use for any Go work creating or reviewing packages/APIs, PR reviews, refactors/restructures, error/logging patterns, config/constructors, testing, and benchmarks.

2026-02-221

init-readme

madflojo/dotfiles

Generate a polished, accurate README.md from a repository by inspecting code, config, and structure. Use when bootstrapping a README, refreshing docs, or the user asks for project overview/getting started instructions.

2026-02-221

gen-godocs

madflojo/dotfiles

Generate missing idiomatic Go doc comments (godoc) for packages, types, funcs, methods, vars/consts, and struct fields, and output a unified diff patch. Use when improving Go documentation coverage.

2026-02-221

review-godocs

madflojo/dotfiles

Review Go packages for missing or non-idiomatic godoc comments and produce a concise coverage report and findings without modifying files. Use when auditing Go documentation quality.

2026-02-221

name	commit
description	Generate a Conventional Commit message and perform a git commit for staged changes. Use when the user asks to commit changes, wants a commit message, or needs Conventional Commits guidance.
license	Apache-2.0
compatibility	Requires git.
metadata	{"source":".prompts/commit.md","version":"1.0"}

Perform a Git Commit for Staged Changes

Tooling

Viewing Staged Changes

Use:

git --no-pager diff --staged

If changes are not staged, ask the user to stage them or if they want to stage all changes with:

git add .

Committing Changes

Commit non-interactively by reading the message from stdin (safe with !, quotes, backticks, and newlines):

git commit -F - <<'EOF'
<type(scope): subject>

<body (optional)>
EOF

Avoid passing commit messages via -m when the message may contain !, quotes, backticks, backslashes, or newlines.

Rules

If change is trivial (e.g., <100 lines changed, small edits), generate a single-line commit.
If change is non-trivial, allow a concise multi-line commit.
Always follow Conventional Commits format including adding issues, user stories, tasks, or defects references if available.
Limit subject line to 100 characters max.

Style

Never start with an emoji; one emoji at the end of the subject is OK.
Add a touch of contextual humor (just enough for a chuckle, but still relevant and professional).
Title/subject: optionally append a single emoji at the end; Body: keep total emojis subtle (generally ≤2).
If you’re forced to inline a message in a shell command, avoid shell-problematic characters (especially !). Otherwise prefer the stdin-based commit flow above.