ワンクリックで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.