ワンクリックでManusで任意のスキルを実行

始める

$pwd:

commit

Name: Commit
Author: DavidVujic

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

Manusで実行

$ git log --oneline --stat

stars:11

forks:1

updated:2026年3月25日 13:27

SKILL.md

readonly

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.

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.

related-skills.json

同じリポジトリ

safeguarding-ai-generated-code.md

from "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.md

from "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.md

from "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

planning-style.md

from "DavidVujic/my-eca-config"

Produce an implementation plan with a functional-leaning, idiomatic style mindset; prefers lightweight data structures over dataclasses/pydantic unless justified.

2026-03-0211

fp-idiomatic-style.md

from "DavidVujic/my-eca-config"

Coding style policy for generated code: prefer idiomatic language conventions with a functional-leaning approach (pure-ish functions, composability), and prefer lightweight data structures over heavy schema/class abstractions unless clearly justified.

2026-03-0211

package.json

"author": "DavidVujic"

"repository": "DavidVujic/my-eca-config"

GitHub リポジトリを開く Creator のリポジトリを見る

$ install --global

$ download --local

Manusで実行

$ useful --forSOC

ソフトウェア開発者コンピュータ・数学職15-1252L4

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.

commit

Commit Skill

Purpose

Procedure

Step 1 — Check for staged changes

Step 2 — Obtain the diff context

Step 3 — Analyse the diff and build the commit message

Step 4 — Execute the commit

Step 5 — Confirm

Rules

このリポジトリの他の Skills

このリポジトリの他の Skills

Commit Skill

Purpose

Procedure

Step 1 — Check for staged changes

Step 2 — Obtain the diff context

Step 3 — Analyse the diff and build the commit message

Step 4 — Execute the commit

Step 5 — Confirm

Rules