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

git-commit

スター25

フォーク0

更新日2026年7月8日 15:32

Stage meaningful diffs and create Conventional Commits with WHY-focused messages. Use whenever making git commits, grouping changes, choosing commit types, or separating structural and behavioral work.

インストール

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

Manusで実行

ソース

atusy

atusy/dotfiles

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

ダウンロード

Manusで実行

INSTRUCTIONS

Create small, cohesive commits that explain why the change exists.

Commit Discipline

Only commit when:
1. ALL tests are passing
2. ALL compiler/linter warnings have been resolved
3. The change represents a single logical unit of work
4. Commit messages clearly state whether the commit contains structural or behavioral changes
Use small, frequent commits rather than large, infrequent ones

Workflow

Inspect context:
- git status --short
- git diff --stat
- git diff --cached --stat
- git log --oneline -10
Review detailed diffs for files being considered.
Identify logical groups. Keep unrelated changes in separate commits.
Stage intentionally with git add <file> or git add -p <file>.
Verify staged content with git diff --cached.
Choose the commit type from the staged diff.
Commit with a message whose body explains WHY.

Conventional Commits

Use Conventional Commits 1.0.0:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Common types:

fix: bug fix
feat: user-visible feature
build: build system or dependency change
chore: maintenance without production-code behavior
ci: CI configuration
docs: documentation only
style: formatting or whitespace only
refactor: structural change without behavior change
perf: performance improvement
test: adding or correcting tests

Use feat!: or fix!: for breaking changes. If behavior changes, do not label the commit as refactor:, style:, docs:, or chore:.

WHY-Focused Messages

Follow t-wada's division of responsibility:

Code describes HOW
Tests describe WHAT happens
Commit log describes WHY
Code comments describe WHY NOT

The body should explain motivation and reasoning instead of repeating the diff:

What problem does this solve?
Why is this change needed now?
Why this approach over plausible alternatives?

Keep the subject imperative and concise, ideally under 50 characters.

このリポジトリの他の Skills

同じリポジトリ

lsmcp

atusy/dotfiles

Query code semantics (symbols, hover, definitions, references, diagnostics) across any language via the lsmcp MCP server, which bridges through kakehashi to real language servers (lua_ls, basedpyright, rust_analyzer, r_language_server, nixd, …). Use when exploring or analyzing a codebase, finding/understanding symbols, or when the first project-wide search misses a language. Prefer these tools over Grep/Read for code analysis.

2026-07-1325

revise

atusy/dotfiles

Run the full multi-stage review pipeline on the current branch — /review (multi-perspective subagents) → codex MCP → PR → Copilot/Gemini bots — fixing findings at each stage until convergence. Use when the user asks to "revise", run the review pipeline, or prepare a branch/PR for merge review.

2026-07-0825

review

atusy/dotfiles

Run a strict multi-perspective review with fact-checked findings. Use when the user asks for a review, code review, design review, risk review, or wants independent reviewer perspectives before merging or shipping.

2026-07-0825

ultrathink

atusy/dotfiles

Perform deep multi-perspective analysis with problem-specific analytical lenses, cross-validation, and a final recommendation. Use when the user asks to ultrathink, deeply analyze a complex problem, compare strategic options, expose risks, or make a high-impact technical decision.

2026-07-0825

tidying

atusy/dotfiles

Guide structural code improvements using Kent Beck's Tidy First methodology. Use when seeing messy code, before making behavioral changes, after completing features, documenting deferred cleanup, or discussing when to clean up code.

2026-07-0825

tdd

atusy/dotfiles

Guide Test-Driven Development using Kent Beck's Red-Green-Refactor cycle. Use when writing tests, implementing features via TDD, entering RED/GREEN/REFACTOR phase, or following plan.md test instructions.

2026-07-0825

INSTRUCTIONS

Create small, cohesive commits that explain why the change exists.

Commit Discipline

Only commit when:

ALL tests are passing
ALL compiler/linter warnings have been resolved
The change represents a single logical unit of work
Commit messages clearly state whether the commit contains structural or behavioral changes

Use small, frequent commits rather than large, infrequent ones

Workflow

Inspect context:

git status --short
git diff --stat
git diff --cached --stat
git log --oneline -10

Review detailed diffs for files being considered.

Identify logical groups. Keep unrelated changes in separate commits.

Stage intentionally with git add <file> or git add -p <file>.

Verify staged content with git diff --cached.

Choose the commit type from the staged diff.

Commit with a message whose body explains WHY.

Conventional Commits

Use Conventional Commits 1.0.0:

<type>[optional scope]: <description> [optional body] [optional footer(s)]

Common types:

fix: bug fix

feat: user-visible feature

build: build system or dependency change

chore: maintenance without production-code behavior

ci: CI configuration

docs: documentation only

style: formatting or whitespace only

refactor: structural change without behavior change

perf: performance improvement

test: adding or correcting tests

Use feat!: or fix!: for breaking changes. If behavior changes, do not label the commit as refactor:, style:, docs:, or chore:.

WHY-Focused Messages

Follow t-wada's division of responsibility:

Code describes HOW

Tests describe WHAT happens

Commit log describes WHY

Code comments describe WHY NOT

The body should explain motivation and reasoning instead of repeating the diff:

What problem does this solve?

Why is this change needed now?

Why this approach over plausible alternatives?

Keep the subject imperative and concise, ideally under 50 characters.

name	git-commit
description	Stage meaningful diffs and create Conventional Commits with WHY-focused messages. Use whenever making git commits, grouping changes, choosing commit types, or separating structural and behavioral work.