client-report-from-commits

client-report-from-commits

指定した日付範囲の Git 履歴を、機能ごとにまとめた、コピーしてそのまま使える非技術者向けのクライアント報告に変換します。

判断フロー

すでに分かっていることは何ですか？

• YYYY-MM-DD 形式の正確な開始日が分かっていて、現在の作業ディレクトリが対象の Git リポジトリである場合：続行します。
• YYYY-MM-DD 形式の正確な開始日が分かっているものの、対象のリポジトリが別の場所にある場合：明示されたリポジトリのパスを使って続行します。
• 信頼できる時計、タイムゾーン、関連する文脈に基づいて、相対的な日付が明確に定まる場合：日付を確定し、履歴を収集する前に正確な YYYY-MM-DD の境界とタイムゾーンを伝えます。重複する確認は不要です。
• 「最近」や、週の開始日の指定がない場合、既知のイベント境界がない「最後のプッシュ以降」など、範囲が本当に曖昧な場合：要点を絞って質問します。コミットのタイムスタンプからプッシュ日やデプロイ日を推測しないでください。
• 現在の作業ディレクトリに読み取り可能な Git リポジトリがなく、リポジトリのパスも指定されていない場合：処理を中止し、読み取り可能な Git リポジトリのパスを尋ねます。
• エンジニアリング向けのリリースノート、開発者向けの変更履歴、またはコードレビューが求められている場合：このスキルは使用しません。

クイックリファレンス

タスク	操作
リポジトリを確認する	現在のディレクトリで git rev-parse --show-toplevel を実行します。リポジトリのパスが指定されている場合は、git -C /path/to/repo rev-parse --show-toplevel を実行します。
コミットのコンテキストを収集する	Git の履歴と差分を直接確認するか、構造化された一覧を作成するために python3 scripts/collect_git_changes.py --repo /path/to/repo --since YYYY-MM-DD を実行します。
詳細を確認する	references/workflow.md を読み、その後 git show <commit> で対象のコミットを確認します。
クライアント報告をまとめる	依頼された形式に従います。templates/client-report-template.md は任意の出発点として、references/output-format.md は文章作成のガイドとして利用できます。
例外的なケースに対処する	references/gotchas.md を読みます。

運用ルール

1. 依頼または信頼できる文脈に基づいて、実際の暦上の日付境界を確定します。このヘルパーが受け付けるのは YYYY-MM-DD のみです。厳格なパーサーを変更せずに、実行前に相対的な日付表現を確定してください。
2. リポジトリのコンテキストを確認します。現在の作業ディレクトリが読み取り可能な Git リポジトリではない場合は、明示的なリポジトリのパスが必要です。
3. 関連する履歴と差分に基づいて報告を作成します。役立つ場合は scripts/collect_git_changes.py を使用します。タスクに十分な証拠がすでにある場合は、再収集しないでください。
4. 作業は機能、ワークフロー、または製品領域ごとにまとめます。コミット、ファイル、ブランチ、エンジニアごとにまとめないでください。
5. 非技術者のクライアント向けに作成します。ハッシュ、ファイル名、コード用語、リファクタリングの専門用語、社内ツール名は、クライアントにとって本当に重要な場合を除いて削除します。
6. 依頼された形式で簡潔にまとめます。見出し、段落、箇条書きの数は、決まった数に合わせるのではなく、内容に応じて選びます。
7. 裏付けのある変更のみを記載します。コミットだけではデプロイ、導入、ビジネスへの影響は証明されません。控えめな表現の主張にも根拠が必要です。

推奨ワークフロー

1. 対象のリポジトリを特定します。
2. 正確な YYYY-MM-DD の境界と、重要なタイムゾーンの前提を確定して伝えます。
3. 履歴を直接収集するか、python3 scripts/collect_git_changes.py --repo /path/to/repo --since YYYY-MM-DD を使って、JSON の出力を確認します。
4. 機能ごとの分類が明らかでない場合は、代表的なコミットや差分をいくつか確認します。
5. まず機能ごとの概要を作り、その後、クライアント向けの箇条書きを作成します。
6. 依頼された形式で報告を作成します。特に指定がなければ、コピーしてそのまま使える Markdown を使用します。

レポートの基本方針

ユーザーが別の形式を求めない限り、次のデフォルトを使用します。

• 2026-04-01 以降に完了した作業の概要をお知らせします。のような、1 行の導入文から始めます。
• 読者に伝わりやすい短い見出しを付け、機能ごとにセクションを分けます。
• 意味のある変更を区別するために必要な数だけ、箇条書きや文を使用します。数を満たすために内容を水増ししたり、根拠を省いたりしないでください。
• 各箇条書きは、成果を先に示し、技術的な表現を避けます。
• 出力はそのままコピーして使える形にします。分析メモや開発者向けの前置きで囲まないでください。
• 指定された期間に、クライアントにとって意味のある変更がなかった場合は、レポートを水増しせず、その旨を明確に伝えます。

読み方ガイド

必要な情報	参照先
リポジトリの確認、コマンドの流れ、Git の収集手順	references/workflow.md
トーン、グループ分け、箇条書きの作成ルール	references/output-format.md
失敗につながるケースと避けるべきこと	references/gotchas.md
クライアント向けレポートの空のひな形	templates/client-report-template.md

注意点

1. 相対日付を確定するのは、時刻、タイムゾーン、期間の意味が信頼できる場合に限ります。境界の不足によってレポートが変わる可能性がある場合は、確認してください。
2. 長い Git ログはクライアント向けレポートではありません。機能ごとに要約し、クライアントにとって有用でない限り、重要度の低い内部の変更は省きます。
3. 技術的なコミットメッセージは、技術に詳しくない読者向けの説明として誤解を招くことがよくあります。クライアント向けの箇条書きに書き換える前に、差分や関連ファイルを確認してください。
4. 複数のコミットがひとつの成果を表す場合があります。同じ内容を繰り返すのではなく、ひとつの機能セクションにまとめてください。
5. インフラのみの変更を誇張しないでください。重要な場合は、安定性や基盤の改善として控えめに表現します。

ガイダンスが不十分な場合

収集手順が古い場合やリポジトリと矛盾する場合は、リポジトリの履歴、差分、設定、最新の公式 Git ドキュメントを使って、該当する動作を確認してください。タスクの読み取り専用の範囲内で、検証済みのコマンドを使用します。アクセスできない履歴や不完全な履歴があれば、その旨を明記してください。インストール済みのコピーを黙って編集するのではなく、根拠となる情報源と再現可能な Git の例または確認手順を添えて、標準的なスキルの修正案を提示してください。通常のレポートでは、ウェブ閲覧は必要ありません。