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

git-commit-message

스타1

포크0

업데이트2026년 5월 1일 05:27

Write a Conventional Commits message describing a code change. Use when the goal mentions creating a commit, writing commit message, or committing changes.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

nuumz

nuumz/vinyan

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Git Commit Message

Write commit messages that explain why, not what. The diff already shows what.

When to use

The user asks to commit, write a commit message, or summarize a change for git.
You're about to call git commit and need to draft the -m text.
Reviewing a PR description and the commits underneath it look weak.

Format

type(scope): short imperative summary (≤72 chars)

(optional body — wrap at 72 chars)
- Why this change is needed
- Constraints or trade-offs the reader should know about
- Anything surprising in the implementation

Refs: #123

Type vocabulary (Conventional Commits)

feat — new user-facing capability
fix — bug fix; pair with a regression test
refactor — internal restructure, no behavior change
docs — comments / README / docs only
test — tests only
chore — tooling, deps, CI
perf — performance change with measurable impact

Procedure

Look at the actual diff before writing. git diff --staged. Don't write from memory.
One commit = one logical change. If the message wants "and" or bullet points listing unrelated things, the commits should be split.
Imperative present. "fix null deref in parser" not "fixed" or "fixes". Reads like a directive: "if applied, this commit will…"
Subject ≤72 chars. GitHub truncates at 72 in some views. If you need more, use the body.
Why-first body. Reviewers know what changed (the diff). They don't know why you chose this approach over alternatives — explain that.

Examples

fix(workflow): reset retry counter when step succeeds

Counter was sticky — a retried step that finally succeeded still
counted toward the `maxAttempts` budget for siblings. Reset on
success so failure quotas are per-step, not per-workflow.

refactor(skill-cards): extract envelope renderer

No behavior change. Pulls the `<skill-card hash="...">` rendering
out of the prompt-section so future card sources (autonomous,
imported) can reuse the same envelope.

이 저장소의 다른 Skills

같은 저장소

code-review

nuumz/vinyan

Review code changes for correctness, error handling, scope creep, and style. Use when the goal mentions reviewing a PR, diff, or file.

2026-05-011

debug-trace

nuumz/vinyan

Walk through a stack trace or error log to find the root cause. Use when the goal mentions debugging, investigating an error, or tracking down a bug.

2026-05-011

unit-test-plan

nuumz/vinyan

Outline unit tests for a function or module before writing them. Use when the goal mentions writing tests, test plan, or test coverage.

2026-05-011

budget-and-scope

nuumz/vinyan

Keep effort proportional to risk — prefer the cheapest sufficient workflow, escalate only on evidence, refuse over-analysis on simple tasks. Use when choosing depth, level, or workflow shape.

2026-05-011

capability-mapping

nuumz/vinyan

Map required capabilities to persona roles and available skills. Detect missing skill coverage and decide whether to acquire a skill, request one, or proceed generically. Use when scoping a workflow.

2026-05-011

collaboration-room

nuumz/vinyan

Coordinate multi-persona work with a shared blackboard, role boundaries, hand-off contract, conflict resolution, and final synthesis. Use when a task benefits from more than one persona.

2026-05-011

Git Commit Message

Write commit messages that explain why, not what. The diff already shows what.

When to use

The user asks to commit, write a commit message, or summarize a change for git.

You're about to call git commit and need to draft the -m text.

Reviewing a PR description and the commits underneath it look weak.

Format

type(scope): short imperative summary (≤72 chars) (optional body — wrap at 72 chars) - Why this change is needed - Constraints or trade-offs the reader should know about - Anything surprising in the implementation Refs: #123

Type vocabulary (Conventional Commits)

feat — new user-facing capability

fix — bug fix; pair with a regression test

refactor — internal restructure, no behavior change

docs — comments / README / docs only

test — tests only

chore — tooling, deps, CI

perf — performance change with measurable impact

Procedure

Look at the actual diff before writing. git diff --staged. Don't write from memory.

One commit = one logical change. If the message wants "and" or bullet points listing unrelated things, the commits should be split.

Imperative present. "fix null deref in parser" not "fixed" or "fixes". Reads like a directive: "if applied, this commit will…"

Subject ≤72 chars. GitHub truncates at 72 in some views. If you need more, use the body.

Why-first body. Reviewers know what changed (the diff). They don't know why you chose this approach over alternatives — explain that.

Examples

fix(workflow): reset retry counter when step succeeds Counter was sticky — a retried step that finally succeeded still counted toward the `maxAttempts` budget for siblings. Reset on success so failure quotas are per-step, not per-workflow.

refactor(skill-cards): extract envelope renderer No behavior change. Pulls the `<skill-card hash="...">` rendering out of the prompt-section so future card sources (autonomous, imported) can reuse the same envelope.

name	git-commit-message
description	Write a Conventional Commits message describing a code change. Use when the goal mentions creating a commit, writing commit message, or committing changes.