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

시작하기

commit

스타11

포크1

업데이트2026년 3월 25일 13:27

Create a conventional commit from staged changes, with a diff-derived description body.

설치

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

Manus에서 실행

출처

DavidVujic

DavidVujic/my-eca-config

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

다운로드

Manus에서 실행

Commit Skill

Purpose

Produce a single, well-formed conventional commit from the currently staged changes. The commit message follows the format:

<type>(<scope>): <subject>

<body>

This skill MUST be used whenever a task depends on creating a commit.

Procedure

Follow these steps strictly and in order.

Step 1 — Check for staged changes

Run:

git diff --cached --stat

If the output is empty, stop immediately and inform the user:

"No staged changes found. Stage files with git add before committing."

Do not auto-stage files. Do not proceed.

Step 2 — Obtain the diff context

Load and execute the git-changes-context skill to obtain diff_context.

If the skill returns "error": "NO_DIFF_FOUND", fall back to using the staged diff:

git diff --cached

Capture whichever diff is available as diff.

Step 3 — Analyse the diff and build the commit message

Using diff, determine:

type — one of: feat, fix, refactor, docs, style, test, chore, perf, ci, build, revert.
scope (optional) — the primary module, file, or area affected. Omit parentheses entirely if no clear scope exists.
subject — a short imperative summary (lowercase, no period, max ~72 chars).
body — a concise description (1–3 sentences) of what changed and why, derived from the diff. Focus on intent, not low-level line changes.

If the user provided a hint (passed as $ARGUMENTS), use it as the subject line. Still generate the body from the diff. If the hint already contains a type prefix (e.g. fix: correct null check), honour it and do not override the type.

Step 4 — Execute the commit

Construct the full commit message and run:

git commit -m "<full message>"

Use a HEREDOC to preserve newlines:

git commit -m "$(cat <<'EOF'
<type>(<scope>): <subject>

<body>
EOF
)"

Step 5 — Confirm

Show the user:

The commit hash (short form).
The full commit message that was used.

Rules

Never fabricate changes not present in the staged diff.
Never auto-stage files — only commit what is already staged.
Keep the subject line under 72 characters.
Use imperative mood in the subject (e.g. "add", not "added" or "adds").
The body should add value beyond the subject; do not simply repeat it.
If the diff is trivial (e.g. a single typo fix), the body may be a single sentence.

이 저장소의 다른 Skills

같은 저장소

explaining-code-health

DavidVujic/my-eca-config

Use when a user asks what Code Health means, how to interpret scores, or why Code Health matters in daily development.

2026-05-2111

guiding-refactoring-with-code-health

DavidVujic/my-eca-config

Use when refactoring unhealthy code and needing Code Health findings to choose small safe steps and verify improvement.

2026-05-2111

making-the-business-case-for-code-health

DavidVujic/my-eca-config

Use when a user asks for ROI, stakeholder justification, delivery impact, or defect-risk reduction from improving Code Health in a file.

2026-05-2111

safeguarding-ai-generated-code

DavidVujic/my-eca-config

Use when AI-generated or AI-modified changes need a Code Health gate before commit, handoff, or pull request.

2026-05-2111

qa-check

DavidVujic/my-eca-config

Run linting and unit tests against the current repository, auto-discovering the correct commands from Justfile, Makefile, pyproject.toml, or package.json.

2026-03-2511

git-changes-context

DavidVujic/my-eca-config

Reliably obtain a non-empty unified git diff for the current branch using safe fallbacks (origin/HEAD...HEAD, origin/main...HEAD, origin/master...HEAD) and return structured JSON containing the diff and the command used.

2026-03-0311

name	commit
description	Create a conventional commit from staged changes, with a diff-derived description body.

Commit Skill

Purpose

Produce a single, well-formed conventional commit from the currently staged changes. The commit message follows the format:

<type>(<scope>): <subject>

<body>

This skill MUST be used whenever a task depends on creating a commit.

Procedure

Follow these steps strictly and in order.

Step 1 — Check for staged changes

Run:

git diff --cached --stat

If the output is empty, stop immediately and inform the user:

"No staged changes found. Stage files with git add before committing."

Do not auto-stage files. Do not proceed.

Step 2 — Obtain the diff context

Load and execute the git-changes-context skill to obtain diff_context.

If the skill returns "error": "NO_DIFF_FOUND", fall back to using the staged diff:

git diff --cached

Capture whichever diff is available as diff.

Step 3 — Analyse the diff and build the commit message

Using diff, determine:

type — one of: feat, fix, refactor, docs, style, test, chore, perf, ci, build, revert.
scope (optional) — the primary module, file, or area affected. Omit parentheses entirely if no clear scope exists.
subject — a short imperative summary (lowercase, no period, max ~72 chars).
body — a concise description (1–3 sentences) of what changed and why, derived from the diff. Focus on intent, not low-level line changes.

Step 4 — Execute the commit

Construct the full commit message and run:

git commit -m "<full message>"

Use a HEREDOC to preserve newlines:

git commit -m "$(cat <<'EOF'
<type>(<scope>): <subject>

<body>
EOF
)"

Step 5 — Confirm

Show the user:

The commit hash (short form).
The full commit message that was used.

Rules

Never fabricate changes not present in the staged diff.
Never auto-stage files — only commit what is already staged.
Keep the subject line under 72 characters.
Use imperative mood in the subject (e.g. "add", not "added" or "adds").
The body should add value beyond the subject; do not simply repeat it.
If the diff is trivial (e.g. a single typo fix), the body may be a single sentence.