Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

Comenzar

$pwd:

commit

Name: Commit
Author: DavidVujic

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

Ejecutar en Manus

$ git log --oneline --stat

stars:11

forks:1

updated:25 de marzo de 2026, 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

mismo repositorio

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"

Abrir repositorio de GitHub Ver repositorios del creador

$ install --global

$ download --local

Ejecutar en Manus

$ useful --forSOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas15-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

Más de este repositorio

Más de este repositorio

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