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

git-commit

スター10

フォーク1

更新日2026年7月25日 06:37

Create a safe Git commit with Conventional Commits format. Use when: committing changes, reviewing staged changes. Do not use: for commit history rewriting, interactive rebasing.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

woliveiras

woliveiras/geremmyas

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

ダウンロード

Manusで実行

Git Commit

Create a local Git commit after reviewing the exact changes that will be included.

Format

type(scope): description

Types

feat — new feature or capability
fix — bug fix
docs — documentation changes only
test — adding or updating tests
refactor — code change that neither fixes a bug nor adds a feature
chore — maintenance tasks (deps, CI, configs)
style — formatting, whitespace (no code logic change)
perf — performance improvement

Rules

Use lowercase for type and description
Scope is optional but recommended (e.g., feat(auth): add login)
Description is imperative mood: "add", not "added" or "adds"
Keep the first line under 72 characters
Breaking changes: add ! after type — feat!: remove legacy API

Procedure

Inspect the working tree with git status --short.
Inspect staged changes with git diff --cached --stat and git diff --cached.
If there are no staged changes, summarize the unstaged and untracked files from git status --short and ask the user which exact files should be staged.
Stage only files explicitly approved by the user. Never run git add . as the default action.
Re-read git status --short, git diff --cached --stat, and git diff --cached after staging.
Identify the primary type and optional scope from the staged diff.
Propose a Conventional Commit message. Add a body only when the "why" is not obvious from the subject line.
Ask for explicit confirmation before running git commit.
Run git commit only after confirmation, using only the currently staged changes.
Show the created commit with git rev-parse --short HEAD and git show --stat --oneline --no-renames HEAD.

Safety Rules

Do not push.
Do not amend or rewrite history unless the user explicitly asks for it.
Do not commit unrelated user changes without explicit approval.
Do not stage ignored files, secrets, local environment files, or generated artifacts unless the user explicitly confirms that exact path.
If the staged diff includes suspicious secrets or credentials, stop and ask the user how to proceed.
If tests or verification were expected but not run, say that before asking for commit confirmation.

このリポジトリの他の Skills

同じリポジトリ

skill-authoring

woliveiras/geremmyas

Create or revise coding-assistant skills that match this repository's structure and conventions. Use when: writing, renaming, or reviewing a skill. Do not use: for general writing or non-skill documentation.

2026-07-2510

android-ci-setup

woliveiras/geremmyas

Set up an Android CI/CD pipeline with lint, static analysis, unit tests, dependency review, and build verification. Use when: creating CI for Android, adding Gradle checks. Do not use: for local development setup, non-CI automation.

2026-07-2510

bugfix-loop

woliveiras/geremmyas

Run a disciplined bugfix loop with reproduction, hypotheses, regression test, fix, and cleanup. Use when: fixing bugs, debugging regressions, investigating failures. Do not use: for feature implementation, refactoring.

2026-07-2510

chromadb-rag-workflow

woliveiras/geremmyas

Design or review a ChromaDB-backed RAG workflow. Use when: creating collections, choosing embedding functions, chunking documents, writing retrievers. Do not use: for general LLM integration, non-RAG patterns.

2026-07-2510

ci-workflow

woliveiras/geremmyas

Create, review, or debug a CI/CD workflow. Use when: editing GitHub Actions, fixing CI failures, adding release/deploy automation. Do not use: for general DevOps, infrastructure as code.

2026-07-2510

code-review-requesting

woliveiras/geremmyas

Structured code review workflow ensuring context and clarity. Use when: implementation complete, tests verified, before merge request. Do not use: during active implementation, before verification checklist, or for design reviews.

2026-07-2510

Git Commit

Create a local Git commit after reviewing the exact changes that will be included.

Format

type(scope): description

Types

feat — new feature or capability

fix — bug fix

docs — documentation changes only

test — adding or updating tests

refactor — code change that neither fixes a bug nor adds a feature

chore — maintenance tasks (deps, CI, configs)

style — formatting, whitespace (no code logic change)

perf — performance improvement

Rules

Use lowercase for type and description

Scope is optional but recommended (e.g., feat(auth): add login)

Description is imperative mood: "add", not "added" or "adds"

Keep the first line under 72 characters

Breaking changes: add ! after type — feat!: remove legacy API

Procedure

Inspect the working tree with git status --short.

Inspect staged changes with git diff --cached --stat and git diff --cached.

If there are no staged changes, summarize the unstaged and untracked files from git status --short and ask the user which exact files should be staged.

Stage only files explicitly approved by the user. Never run git add . as the default action.

Re-read git status --short, git diff --cached --stat, and git diff --cached after staging.

Identify the primary type and optional scope from the staged diff.

Propose a Conventional Commit message. Add a body only when the "why" is not obvious from the subject line.

Ask for explicit confirmation before running git commit.

Run git commit only after confirmation, using only the currently staged changes.

Show the created commit with git rev-parse --short HEAD and git show --stat --oneline --no-renames HEAD.

Safety Rules

Do not push.

Do not amend or rewrite history unless the user explicitly asks for it.

Do not commit unrelated user changes without explicit approval.

Do not stage ignored files, secrets, local environment files, or generated artifacts unless the user explicitly confirms that exact path.

If the staged diff includes suspicious secrets or credentials, stop and ask the user how to proceed.

If tests or verification were expected but not run, say that before asking for commit confirmation.

name	git-commit
description	Create a safe Git commit with Conventional Commits format. Use when: committing changes, reviewing staged changes. Do not use: for commit history rewriting, interactive rebasing.