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

git-commit-granularity

スター3

フォーク0

更新日2026年4月7日 14:33

Gitコミットの粒度（サイズ・単位）ベストプラクティスに従い、アトミックで単一概念のコミットへ分割・整形するガイドを提供する。git add -pによるハンクステージング、セマンティックギャップの回避、クリーンな履歴の構築手順をカバーする。コミット作成時、既存コミットのリファクタリング前、コードレビューでのコミット単位の見直し時に使う。コンフリクト解消、PRマージ、リポジトリの初期セットアップには使わない。

インストール

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

Manusで実行

ソース

53able

53able/skills

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

ダウンロード

Manusで実行

Git コミット粒度ガイド

手順

Step 1: 現在の差分を把握する

作業ツリーの変更全体を確認する:
```
git status
git diff --stat
```
ステージ済みの変更を確認する:
```
git diff --cached --stat
```
変更が複数の目的・概念を含む場合は Step 2 へ進む。単一概念であれば Step 4 へスキップする。

Step 2: 差分を論理グループへ分類する

差分を論理グループ（バグ修正・機能追加・リファクタリング・タイポ修正など）へ分類する。
セマンティックギャップ（コードが壊れた中間状態）が生じないかを確認する。判断基準はスキル同梱の references/granularity-rules.md を読む。
各グループが「関数の移動」を伴う場合は、削除と追加を必ず同一コミットに含める（セマンティックギャップ防止）。

Step 3: ハンク単位でステージングする（git add -p）

インタラクティブなハンクステージングを起動する:
```
git add -p
```
各ハンクに対してキーを入力する:
- y — 現在のグループに属するハンクを採択
- n — 次のコミットに回す
- s — ハンクをさらに分割（より細かい粒度が必要な場合）
- e — ハンクを手動編集（行単位の選択が必要な場合）
- q — ステージング終了
ステージ内容を確認する:
```
git diff --cached
```
意図した変更のみが含まれていることを確認する。含まれていない場合は git restore --staged <file> でアンステージし直す。

Step 4: コンパイル／テストの通過確認

ステージ済みの差分のみで、コードが動作する状態を維持しているか確認する。

テストスイートまたはビルドを実行する:

# プロジェクトに合わせて選択
npm test / yarn test / pnpm test
go test ./...
pytest
make build

ビルドまたはテストが失敗した場合は Step 2 へ戻り、セマンティックギャップが生じていないか再確認する。

Step 5: コミットメッセージを作成する

コミットメッセージの書式を確認する: スキル同梱の references/granularity-rules.md

Conventional Commits 形式で書く:

<type>(<scope>): <概要>（50文字以内）

[本文: 変更した理由、背景（任意）]

[フッター: BREAKING CHANGE / 関連 issue 番号（任意）]

type の選択例:
- fix — バグ修正
- feat — 機能追加
- refactor — 振る舞いを変えないリファクタリング
- chore — ビルド・設定変更
- docs — ドキュメントのみの変更
- style — フォーマット・タイポ修正

Step 6: コミットを実行する

コミットを実行する:
```
git commit
```
複数のグループが残っている場合は Step 3 へ戻り、次のグループをステージして繰り返す。
すべてのグループをコミットし終えたら、履歴を確認する:
```
git log --oneline -n 10
```

Step 7: 既存コミットの整理（Push 前のみ）

リモートへの Push 前で、かつローカル履歴が冗長な場合はインタラクティブリベースで整理する:
```
git rebase -i HEAD~<対象コミット数>
```
pick を squash（s）または fixup（f）へ変更して論理的にまとめる。
reword（r）でコミットメッセージを修正する。
注意: すでに Push 済みのコミットには rebase -i を使わない。

エラーハンドリング

git add -p でハンク分割後にビルドが壊れる場合は、セマンティックギャップが発生している。削除と追加が分離されていないかスキル同梱の references/granularity-rules.md を再確認する。
コミット単位の判断が難しい場合はスキル同梱の scripts/check_granularity.py を実行して差分の概要を得る。
git rebase -i で競合が発生した場合は git rebase --abort で中断し、安全な状態へ戻す。
Conventional Commits の type 選択が迷う場合はスキル同梱の references/granularity-rules.md の判定フローを参照する。

このリポジトリの他の Skills

同じリポジトリ

sentence-logic-guard

53able/skills

日本語の文章で文と文のつながりを点検し、直前の文の不足、常識的な連続性、読者視点から論理のほころびを防ぐ。エッセイ、記事、レポート、解説文の執筆・推敲・レビューで使う。法的判断、数学的証明、事実確認のみ、文法校正のみ、意図的なシュール表現や断片的表現の矯正には使わない。

2026-07-043

natural-expression-refiner

53able/skills

日本語の文章を、誇張、借り物の美辞麗句、過剰な謙遜を避け、実感に近い等身大な表現へ整える。エッセイ、プロフィール、商品説明、自己紹介、note、スピーチ、振り返り文の推敲で使う。法的文書、逐語訳、意図的に言葉を高める詩、学術的な出典確認、事実検証には使わない。

2026-06-273

macos-screenshot-capture

53able/skills

macOSのスクリーンショットを、screencaptureと補助CLIで取得する。画面全体、ウィンドウ指定、選択範囲、タイマー撮影、クリップボード保存に対応する。macOS上でエージェントが再現可能なパスへスクリーンショットを保存したい場合に使う。OCR、画像編集、動画収録、macOS以外のスクリーンショット取得には使わない。

2026-06-253

logical-consistency-reviewer

53able/skills

文章、記事、レポート、企画書の論理破綻をレビューし、論点、必要情報、推論、結論と根拠の構造を確認する。Why So、So What、MECEの観点で飛躍、矛盾、論点ずれ、根拠不足を検出する。公開前や改稿前に文章の筋道を点検するときに使う。単なる校正、文体調整、事実確認のみ、法的助言、数学的証明の厳密検証には使わない。

2026-06-243

pr-evidence-capture

53able/skills

UI 変更や状態遷移を伴う PR に、E2E テスト計画・操作後スクリーンショット・検証結果・検証データの副作用を確認エビデンスとして残す。 gh image で画像をアップロードし、Chrome DevTools MCP で画面を操作・撮影し、gh でテスト計画と結果を PR コメントへ投稿する際に使用。「PR にスクショを貼る」「UI エビデンスを残す」「E2E 確認結果を PR にまとめる」「レビュー用に画面の証跡を添付」と依頼された時に適用。内部ロジックのみの変更や、既存の自動テストで担保できる変更には使わない。コミット作成や PR 本体の作成フローには使わない。

2026-06-243

wxt-extension-development

53able/skills

WXTを使ったブラウザ拡張開発を支援する。プロジェクト調査、entrypoint設計、manifestと権限変更、content script UI、storage、messaging、build、zip、ブラウザ検証を扱う。WXTプロジェクトの作成、変更、監査、デバッグ時に使う。非WXT拡張、汎用フロントエンド、拡張ストア審査には使わない。

2026-06-203

name

git-commit-granularity

description

Git コミット粒度ガイド

手順

Step 1: 現在の差分を把握する

作業ツリーの変更全体を確認する:
```
git status
git diff --stat
```
ステージ済みの変更を確認する:
```
git diff --cached --stat
```
変更が複数の目的・概念を含む場合は Step 2 へ進む。単一概念であれば Step 4 へスキップする。

Step 2: 差分を論理グループへ分類する

差分を論理グループ（バグ修正・機能追加・リファクタリング・タイポ修正など）へ分類する。
セマンティックギャップ（コードが壊れた中間状態）が生じないかを確認する。判断基準はスキル同梱の references/granularity-rules.md を読む。
各グループが「関数の移動」を伴う場合は、削除と追加を必ず同一コミットに含める（セマンティックギャップ防止）。

Step 3: ハンク単位でステージングする（git add -p）

インタラクティブなハンクステージングを起動する:
```
git add -p
```
各ハンクに対してキーを入力する:
- y — 現在のグループに属するハンクを採択
- n — 次のコミットに回す
- s — ハンクをさらに分割（より細かい粒度が必要な場合）
- e — ハンクを手動編集（行単位の選択が必要な場合）
- q — ステージング終了
ステージ内容を確認する:
```
git diff --cached
```
意図した変更のみが含まれていることを確認する。含まれていない場合は git restore --staged <file> でアンステージし直す。

Step 4: コンパイル／テストの通過確認

ステージ済みの差分のみで、コードが動作する状態を維持しているか確認する。

テストスイートまたはビルドを実行する:

# プロジェクトに合わせて選択
npm test / yarn test / pnpm test
go test ./...
pytest
make build

ビルドまたはテストが失敗した場合は Step 2 へ戻り、セマンティックギャップが生じていないか再確認する。

Step 5: コミットメッセージを作成する

コミットメッセージの書式を確認する: スキル同梱の references/granularity-rules.md

Conventional Commits 形式で書く:

<type>(<scope>): <概要>（50文字以内）

[本文: 変更した理由、背景（任意）]

[フッター: BREAKING CHANGE / 関連 issue 番号（任意）]

type の選択例:
- fix — バグ修正
- feat — 機能追加
- refactor — 振る舞いを変えないリファクタリング
- chore — ビルド・設定変更
- docs — ドキュメントのみの変更
- style — フォーマット・タイポ修正

Step 6: コミットを実行する

コミットを実行する:
```
git commit
```
複数のグループが残っている場合は Step 3 へ戻り、次のグループをステージして繰り返す。
すべてのグループをコミットし終えたら、履歴を確認する:
```
git log --oneline -n 10
```

Step 7: 既存コミットの整理（Push 前のみ）

リモートへの Push 前で、かつローカル履歴が冗長な場合はインタラクティブリベースで整理する:
```
git rebase -i HEAD~<対象コミット数>
```
pick を squash（s）または fixup（f）へ変更して論理的にまとめる。
reword（r）でコミットメッセージを修正する。
注意: すでに Push 済みのコミットには rebase -i を使わない。

エラーハンドリング

git add -p でハンク分割後にビルドが壊れる場合は、セマンティックギャップが発生している。削除と追加が分離されていないかスキル同梱の references/granularity-rules.md を再確認する。
コミット単位の判断が難しい場合はスキル同梱の scripts/check_granularity.py を実行して差分の概要を得る。
git rebase -i で競合が発生した場合は git rebase --abort で中断し、安全な状態へ戻す。
Conventional Commits の type 選択が迷う場合はスキル同梱の references/granularity-rules.md の判定フローを参照する。