원클릭으로 Manus에서 모든 스킬 실행

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 저장소 열기 Creator 저장소 보기

다운로드

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.