mcpField
M
monthly-invoice-summary

monthly-invoice-summary

github.com/steveclarkeドキュメント36123 回インストール今日更新
リポジトリ

monthly-invoice-summary について

Git のコミットと作業時間のメモを、顧客向けの簡潔な月次請求メモにまとめるスキルです。情報収集から作業の分類、業務成果を重視した表現までを案内します。

主な機能

  1. 01プロジェクト名と請求期間の確認
  2. 02git log によるコミットの確認
  3. 03作業メモと前月の要約の反映
  4. 04作業を分類した簡潔な顧客向け項目
  5. 05成果重視で専門用語を抑えた表現

活用シーン

  1. 01リポジトリ履歴から月次請求メモを作成
  2. 02コミットにない会議や計画を追加
  3. 03毎月の継続項目と表現を統一

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/steveclarke/dotfiles --skill monthly-invoice-summary

インストール後、Claude Code で/monthly-invoice-summaryを入力して読み込まれたか確認します。

詳細

月次請求サマリー

目的

技術的な Git コミットとタイムシートのメモ（会議、計画など）をまとめ、 クライアントに伝わる、簡潔で価値を重視した説明にします。技術的な作業を ビジネス上のコミュニケーションに置き換えることが目的です。

必要な情報

  1. プロジェクト名 — 例：「Acme Project」または「Client Portal App」
  2. 対象期間 — 例：「2025年8月」「2025年第3四半期」
  3. 前月のサマリー（任意）— 表現を統一し、継続的な項目を引き継げます
  4. タイムシートのメモ（任意）— 会議、計画、話し合いなど、Git コミット以外の作業
  5. Git リポジトリの場所 — または、現在のディレクトリを使用することを確認してください

不足している情報を確認します。すべて最初に提供された場合は、ステップ 2 に進みます。

例

  • /monthly-invoice-summary for Acme Project, August 2025
  • /monthly-invoice-summary I need to bill the client for last month
  • /monthly-invoice-summary（必要な情報を確認します）

ステップ 1：情報を収集する

上記の項目を収集します。

ステップ 2：Git コミットデータを収集する

対象期間の git log を実行します：git log --since="2025-08-01" --until="2025-08-31"。 コミットメッセージと日付を含め、開発者が複数いる場合は作成者も記録します。

コミットの傾向を分析して、機能開発、バグ修正、依存関係の更新、 ドキュメントの変更、テストの改善、設定の変更を特定します。

ステップ 3：追加の情報を確認する

タイムシートのメモを確認し、コミットに記録されていない作業を把握します。クライアントとの会議や 進捗確認の電話、計画や設計のセッション、コードレビューやペアプログラミング、 調査や検証、メールでのやり取りなどが該当します。

前月のサマリーを参照して、継続的な項目を特定し、書式とトーンを合わせ、 複数月にわたる進行中の作業を記載します。

ステップ 4：内容をまとめる

関連する作業を論理的なカテゴリに分類します。よく使われるカテゴリは次のとおりです。

  • 進捗会議とプロジェクト管理 — 毎月の定例項目
  • バージョンリリース — 各リリースの主な改善点を強調する
  • インフラストラクチャ／依存関係の更新 — まとめて記載し、技術的な詳細は最小限にする
  • 主要な機能開発 — ビジネス上の価値とユーザー向けの改善
  • バグ修正 — 重要なもののみ記載し、軽微な修正はまとめる
  • セキュリティの改善
  • パフォーマンスの最適化 — ページ読み込みの高速化など、ビジネスへの影響を記載する
  • ドキュメントの更新 — ユーザーガイド、API ドキュメント、セットアップ手順
  • 計画と設計作業 — 要件の調査、リサーチ、アーキテクチャの計画

関連するコミットは、ひとつの箇条書きにまとめます。依存関係に関する 20 件のコミットは 「プロジェクトの依存関係とセキュリティパッチを更新」とし、5 件のバグ修正は 「レポートの問題を解決し、ユーザー通知のエッジケースを修正」とします。 クライアントが一目で確認できるよう、項目数を抑えてください。

ステップ 5：提示する

プレーンテキストを Markdown のレンダリングなしでコピーできるよう、フェンス付きコードブロックで出力します。

Project Notes:
Acme Client Portal - August 2025:
- Status meetings & project management
- Released version 2.3 with improved dashboard performance and new reporting features
- Resolved authentication issues and fixed edge cases in notification delivery
- Updated security patches and project dependencies
- Documented API endpoints for third-party integrations

文体

  • 簡潔で行動を重視する — 「包括的な」「強化された」「堅牢な」は避ける
  • ビジネスを重視する — 技術的な実装ではなく、成果と価値を伝える
  • 専門用語は最小限にする — クライアントに依存関係について説明する必要はありません
  • 文頭のみ大文字にする — 固有名詞を除き、最初の単語だけを大文字にする

❌「包括的なエラー処理システムを実装」→ ✅「決済処理のエラー復旧機能を追加」 ❌「データベースのパフォーマンスを強化」→ ✅「レポート生成を高速化」 ❌「レガシーコードをリファクタリング」→ ✅「ユーザー認証システムを最新化」 ❌「さまざまな依存関係を更新」→ ✅「セキュリティパッチとプロジェクトの依存関係を更新」

コメント

Markdown 対応