一键在 Manus 中运行任何 Skill

commit

星标3

分支0

更新时间2026年5月31日 19:51

Generate a commit message that explains WHAT changed and WHY in plain language. No code references. Humans read these, not machines.

安装

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

在 Manus 中运行

来源

MinutHQ

MinutHQ/huxflux

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

下载

在 Manus 中运行

commit

The user has staged changes and wants a commit message. This skill reads the diff and produces a message that a human can understand without looking at the code.

Arguments

None. Operates on whatever is currently staged.

Steps

Read the staged diff: git diff --cached. If empty, refuse and tell the user to stage something first.
Read the staged file list: git diff --cached --name-only.
Read recent commit messages for tone: git log --oneline -20 plus git log -5 --format='%s%n%n%b'.
Classify the dominant change type: feat / fix / refactor / chore / docs / test.
Compose the message following the rules below.
Output in a fenced block. Do NOT run git commit unless the user says to.
If the user says "commit it", run it using the HEREDOC form:
```
git commit -m "$(cat <<'EOF'
<subject>

<body>
EOF
)"
```

Message rules

Subject line:

Format: <type>: <imperative summary>
72 characters or fewer
Lowercase after the prefix
Imperative mood ("add", "fix", "remove", not "added" or "adds")
Describe the user-facing or system-level change, not the code change
Good: feat: auto-connect desktop to local server on first launch
Bad: feat: add tryAutoConnectSync to _app.tsx beforeLoad

Body:

1 to 3 sentences explaining WHY this change was made and WHAT it does for users or the system
Write for someone who will never read the diff
No file paths, function names, or variable names
No line-by-line restating of the diff
Use plain language: "The desktop app now finds and connects to the local server automatically" not "Added useEffect in __root.tsx that invokes read_local_connection"
Group related changes with bullets when the commit spans multiple areas
No em dashes. Use commas, periods, or parentheses.

Skip the body for genuinely trivial commits (typo, version bump). A bare subject is fine.

Do not

Do not reference code, paths, functions, or types in the message
Do not run git add. The user controls staging.
Do not run git commit unless explicitly told to.
Do not amend unless the user says --amend.
Do not skip hooks (--no-verify).
Do not invent issue numbers.

同仓库更多 Skills

同仓库

pr-description

MinutHQ/huxflux

Generate a PR description that explains WHAT is being built, WHY, and the high-level approach. Written for humans who will not read the code.

2026-05-313

scaffold-domain

MinutHQ/huxflux

Create a new domains/<name>/ folder following the Huxflux domain pattern. Targets web, server, mobile, or shared. For server domains, also creates the routes plugin and registers it.

2026-05-313

check-domain

MinutHQ/huxflux

Run the structural check (check-domains) against the monorepo or a specific domain. Use after editing a domain to verify it still conforms.

2026-05-313

discuss

MinutHQ/huxflux

Enter discussion mode. No code is written, no files are created or edited. Read the codebase to ground the conversation, reason through trade-offs, surface edge cases, brainstorm. Use when the user wants to think before building.

2026-05-313

kickoff

MinutHQ/huxflux

Establish shared understanding of a task before writing any code. Restate the ask, surface ambiguity, ask 1-3 structured questions, propose an approach with trade-offs, get sign-off. Use at the start of any non-trivial task.

2026-05-313

scaffold-component

MinutHQ/huxflux

Create a new domain-internal React component inside an existing domain. Produces a file that passes lint by construction (size cap, allowed icons, design-system colors).

2026-05-313

commit

The user has staged changes and wants a commit message. This skill reads the diff and produces a message that a human can understand without looking at the code.

Arguments

None. Operates on whatever is currently staged.

Steps

Read the staged diff: git diff --cached. If empty, refuse and tell the user to stage something first.

Read the staged file list: git diff --cached --name-only.

Read recent commit messages for tone: git log --oneline -20 plus git log -5 --format='%s%n%n%b'.

Classify the dominant change type: feat / fix / refactor / chore / docs / test.

Compose the message following the rules below.

Output in a fenced block. Do NOT run git commit unless the user says to.

If the user says "commit it", run it using the HEREDOC form:

git commit -m "$(cat <<'EOF'
<subject>

<body>
EOF
)"

Message rules

Subject line:

Format: <type>: <imperative summary>

72 characters or fewer

Lowercase after the prefix

Imperative mood ("add", "fix", "remove", not "added" or "adds")

Describe the user-facing or system-level change, not the code change

Good: feat: auto-connect desktop to local server on first launch

Bad: feat: add tryAutoConnectSync to _app.tsx beforeLoad

Body:

1 to 3 sentences explaining WHY this change was made and WHAT it does for users or the system

Write for someone who will never read the diff

No file paths, function names, or variable names

No line-by-line restating of the diff

Use plain language: "The desktop app now finds and connects to the local server automatically" not "Added useEffect in __root.tsx that invokes read_local_connection"

Group related changes with bullets when the commit spans multiple areas

No em dashes. Use commas, periods, or parentheses.

Skip the body for genuinely trivial commits (typo, version bump). A bare subject is fine.

Do not

Do not reference code, paths, functions, or types in the message

Do not run git add. The user controls staging.

Do not run git commit unless explicitly told to.

Do not amend unless the user says --amend.

Do not skip hooks (--no-verify).

Do not invent issue numbers.

name	commit
description	Generate a commit message that explains WHAT changed and WHY in plain language. No code references. Humans read these, not machines.