commit-staged

ステージ済みの変更をコミット

プロジェクトの規約に沿ってコミットを作成するための完全なワークフローです。

追加のテキストを明示的に指定して実行した場合は、そのテキストを変更に関する追加のコンテキストとして扱い、コミットの計画とコミットメッセージに含めます。 セッション履歴に調査結果、動機、根拠が含まれている場合は、差分だけに頼らず、その中から特に重要な点をコミットメッセージの本文に含めます。

プロセス

まず、ステージ済みの差分に対して /simplify スキルを実行し、コミット前にその指摘を反映します。ドキュメントのみの差分の場合は何もしません。

1. 優先する実行方法

   • サブエージェントを利用できる場合は、ワークフロー全体で github-dev:commit-creator を使用します。
   • 追加の実行テキストがあれば、追加のコンテキストとして渡します。
   • それ以外の場合は、以下の手動手順に従います。

2. ステージ済みファイルのみを分析

   • ステージ済みのファイルをすべて確認します：git diff --cached --name-only
   • 差分を読みます：git diff --cached
   • ステージされていない変更は完全に無視します

3. コミットメッセージの形式

   • 1行目：{type}: 簡潔な説明（最大50文字）
   • タイプ：feat、fix、refactor、docs、style、test、build
   • 平易な言葉を使います。正確なコマンド名やツール名が必要な場合を除き、専門用語、流行語、リポジトリ内の略語は避けます。
   • セッション履歴に調査結果や動機がある場合は、それを活用します。
   • 「何を」ではなく「なぜ」に焦点を当てます
   • 可能であれば、標準的な形式の1文と、動機や調査結果を示す短い文を1〜2文にします
   • 複雑な変更では、空行の後に箇条書きを追加します

4. メッセージの例

   • feat: add sign-in flow
   • fix: stop duplicate jobs on save
   • docs: add skills install snippets

5. ドキュメントの更新

   • README.md を確認し、以下に該当するものがないか調べます：
     • ドキュメントに記載すべき新機能
     • 実装と一致しなくなった古い説明
     • 新しい依存関係に必要なセットアップ手順の不足
   • ステージ済みの変更に応じて、必要な更新を行います

6. 実行

   • 適切な書式を保つため、コミットでは HEREDOC 構文を使用します
   • コミットメッセージの形式が正しいことを確認します
   • コミットメッセージにテスト計画を追加しないでください

ベストプラクティス

• メッセージを書く前に、ステージ済みのファイルを分析します
• 1行目は50文字以内にします
• 能動態でメッセージを書きます
• 正確さを保ちつつ、簡単な言葉を使います
• 差分の内容をそのまま繰り返すより、セッションで得られた知見を優先します
• 1つのコミットには、論理的にまとまった変更を1つだけ含めます
• README が実装内容を反映していることを確認します