mcpField
C
cost-estimate

cost-estimate

github.com/ulpi-io開発5300 回インストール9 週間前に更新
リポジトリ

cost-estimate について

cost-estimateは、リポジトリの開発工数、コスト、期間、Claude ROIを根拠に基づいて見積もるスキルです。リポジトリ全体、ブランチ、コミットを評価するチーム向けで、ヘルパースクリプトと明示的な前提からレポートを作成します。

主な機能

  1. 01ヘルパースクリプトで対象コードを計測
  2. 02ソース行を生産性カテゴリに分類
  3. 03工数、コスト、期間を算出
  4. 04利用可能な場合はGit履歴からClaude ROIを推定
  5. 05制約事項を含む構造化レポートを生成

活用シーン

  1. 01リポジトリ全体の開発工数を見積もる
  2. 02ブランチやコミットのコストを評価
  3. 03関係者向けの開発見積もりを作成

インストール

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

$npx skills add https://github.com/ulpi-io/skills --skill cost-estimate

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

helpers/
cost_calculator.py
git_session_analyzer.py
loc_counter.py
report_generator.py
references/
estimation-rates.md
report-contract.md

詳細

このスキルは、エビデンスに基づく見積もりワークフローです。

必須ルール:

  1. LOC、セッション、コストの計算を手作業でやり直さず、.agents/skills/cost-estimate/helpers/ 内のヘルパースクリプトを使用してください。
  2. 対象範囲を明確にしてください:リポジトリ全体、branch:<name>、または commit:<hash>。
  3. エンジニアリングの実作業時間と、組織的なオーバーヘッドおよびチーム乗数を分けてください。
  4. 料金の基準とレポートのスキーマは、呼び出し経路に直接記述せず、references に置いてください。
  5. 外部の市場価格調査は任意です。ユーザーが特定の市場または地域を明示的に指定しない限り、組み込みの料金を使用してください。

コスト見積もり

入力

  • $request:任意の対象範囲や見積もりの指針。例:branch:feat/foo、commit:abc1234、地域のヒント、希望する対象読者

目標

以下を満たす、信頼性の高い見積もりを作成します。

  • ヘルパースクリプトを使用して、指定されたコード範囲を測定する
  • コードを適切な生産性カテゴリに分類する
  • オーバーヘッドを二重計上せずに、エンジニアリングの作業時間とコストを算出する
  • 見積もりを現実的なカレンダー期間とチームコストの観点に置き換える
  • 前提条件、信頼度、Claude の ROI を明確に報告する

ステップ 0:対象範囲とモードを決定する

リクエストを以下のいずれかに分類します。

  • リポジトリ全体
  • branch:<name>
  • commit:<hash>

リクエストが曖昧な場合は、デフォルトでリポジトリ全体を対象とします。ユーザーが地域または市場のヒントを指定している場合は、最終的な料金の説明に反映してください。それ以外の場合は、組み込みの基本料金を使用します。

成功基準:スクリプトを実行する前に、見積もりの対象と料金の基準が明確になっていること。

ステップ 1:ヘルパースクリプトを使用して実際のコード範囲を測定する

.agents/skills/cost-estimate/helpers/ 内のヘルパーツールチェーンを使用します。

  • loc_counter.py
  • git_session_analyzer.py
  • cost_calculator.py
  • report_generator.py

対象範囲を指定して loc_counter.py を実行し、以下を取得します。

  • 総行数
  • ファイル数
  • 言語別の内訳
  • ディレクトリ別の内訳
  • ソースコード、テスト、設定、ドキュメントの内訳
  • ファイルごとのカテゴリ候補(all_files から取得)

Git の履歴が利用できる場合は git_session_analyzer.py を実行し、Claude の ROI の算出に、LOC による代替値ではなく、実際のセッション見積もりを使用できるようにします。

ルール:

  • 場当たり的な find、wc、またはインラインの計算よりも、スクリプトの出力を優先する
  • 対象範囲がブランチまたはコミットの場合は、リポジトリ全体ではなく差分を測定する
  • Git の履歴が存在しない、または有用でない場合は、後で Claude の作業時間を LOC に基づいて見積もる

成功基準:対象範囲の規模を示す構造化 JSON と、可能な場合はアクティブセッションの見積もりがあること。

ステップ 2:コードを生産性カテゴリに分類する

loc_counter.py の出力を確認し、該当するすべてのソースコード行を、いずれか 1 つのカテゴリに割り当てます。

以下の情報には references/estimation-rates.md を使用します。

  • カテゴリキー
  • 生産性の範囲
  • オーバーヘッドの範囲
  • 市場料金の基本値
  • 役割ごとの乗数
  • 組織の効率性を示す定数
  • Claude の ROI 定数

分類ルール:

  • 各ソースコード行は一度だけ割り当てる
  • テスト、設定/ビルド、ドキュメントはプロダクトコードと分ける
  • GPU、ネイティブ相互運用、音声/動画、システム拡張機能、オンデバイス ML などの専門的な作業を検出する
  • ファイル単位の根拠なしに複雑さを過大に見積もらない
  • ディレクトリ内で明らかに同じカテゴリに属するファイルはまとめる。ただし、例外的なファイルは個別に明記する

成功基準:計算ツールに渡す、カテゴリごとの行数を網羅した JSON ペイロードがあること。

ステップ 3:計算を実行し、出力の妥当性を確認する

カテゴリ別の合計を cost_calculator.py に渡します。

計算ツールでは、次の項目が出力されます。

  • コーディングの基本時間
  • オーバーヘッド時間
  • 推定総時間
  • 妥当性確認用の実効行数/時間
  • カレンダー時間の表
  • エンジニアリングのみのコスト
  • チーム全体のコスト
  • Claude の時間が算出可能な場合の Claude ROI 項目

ルール:

  • カテゴリの割り当てにオーバーヘッドを含めないでください。計算ツールがすでにオーバーヘッドを加算します。
  • 妥当性確認の値が目標範囲を外れる場合は、カテゴリの割り当てを調整するか、このリポジトリが標準から外れていても妥当である理由を説明してください。
  • ユーザーが別の市場基準を明示的に指定していない限り、デフォルトの市場料金を使用してください。

成功基準:計算ツールの出力に矛盾がなく、妥当性確認が完了していること。

ステップ 4:Claude ROI と信頼度を調整する

セッションデータがある場合は内容を確認し、デフォルトのコミット密度に基づくヒューリスティックが大規模な作業を明らかに過小評価している場合に限り調整してください。セッションデータがない場合は、references/estimation-rates.md に記載されている Claude のフォールバック生産性定数を使用してください。

次の項目を報告してください。

  • 推定 Claude アクティブ時間
  • 人間の基準レートに対する速度倍率
  • Claude の 1 時間あたりの価値
  • ROI と節約額の概要

あわせて、信頼度も示してください。

  • 高:スコープ、カテゴリ構成、履歴が明確な場合
  • 中:履歴またはカテゴリ分けが不完全な場合
  • 低:意図的に概算している場合、またはリポジトリの一部しか利用できない場合

成功基準:ROI の説明が明確で、範囲が適切に限定され、過大な主張がないこと。

ステップ 5:レポート本文を生成する

report_generator.py を使用して Markdown の骨格を生成し、必要に応じて説明を整えてください。

必須のレポート構成と最低限必要なセクションについては、references/report-contract.md を読み込んでください。

最終的な見積もりには、次の項目を含めてください。

  • エグゼクティブサマリー
  • コードベースの指標
  • 開発時間の見積もり
  • カレンダー時間の見通し
  • エンジニアリングのみのコスト
  • チーム全体のコスト
  • Claude ROI
  • 前提と注意事項

ルール:

  • エグゼクティブサマリーと Claude ROI を最初に記載してください。
  • ツールの出力を羅列するのではなく、関係者にとって読みやすいレポートにしてください。
  • スコープの根拠を明示してください。
  • 説明文を手作業で編集する際は、通貨表記のエスケープを維持してください。

成功基準:見積もりが読みやすく、構成が整っており、レポート契約に沿っていること。

ガードレール

  • disable-model-invocation を追加しないでください。これは読み取り中心の分析ワークフローです。
  • paths: を追加しないでください。これは汎用的な見積もりスキルです。
  • 料金表、役割マトリックス、レポートテンプレート全体を SKILL.md にインラインで記載しないでください。
  • ヘルパースクリプトの連携が利用できない場合を除き、ヘルパースクリプトの出力を手作業の計算で置き換えないでください。
  • スコープ、前提、信頼度を示さずにコストの数値を提示しないでください。
  • ユーザーが明示的に依頼し、実際に調査を行った場合を除き、地域固有の市場検証を行ったと主張しないでください。

参照資料を読み込むタイミング

  • references/estimation-rates.md 生産性の区分、オーバーヘッド率、市場料金の基準、チーム倍率、効率定数、Claude ROI のフォールバック定数に使用します。

  • references/report-contract.md 必須のセクション順、レポートの要件、必要な注意事項に使用します。

ヘルパースクリプト

  • .agents/skills/cost-estimate/helpers/loc_counter.py

    • リポジトリ全体:フラグなし
    • ブランチ差分:--branch <name>(任意で --base <base>)
    • 単一コミット:--commit <hash>
    • 出力:totals、by_language、by_directory、all_files を含む JSON
  • .agents/skills/cost-estimate/helpers/git_session_analyzer.py

    • すべてのコミット:フラグなし
    • 特定のブランチ:--branch <name>
    • 出力:total_commits、total_sessions、estimated_active_hours、sessions[] を含む JSON
  • .agents/skills/cost-estimate/helpers/cost_calculator.py

    • 入力:パイプ経由で標準入力に渡すカテゴリ JSON
    • フラグ:--rate <hourly>、--claude-hours <N>
    • 有効なカテゴリキー:simple_crud_ui_boilerplate、standard_views、complex_ui、business_logic、database_persistence、audio_video_processing、gpu_shader、native_interop、system_extensions、on_device_ml、tests、config_build、documentation
    • 出力:base_coding、overhead、total_estimated_hours、sanity_check、calendar_time、engineering_cost、team_costs、claude_roi を含む JSON
  • .agents/skills/cost-estimate/helpers/report_generator.py

    • フラグ:--calc <costs.json>、--sessions <sessions.json>、--project <name>、--scope <desc>
    • 単一セクション:--section <name>
    • 利用可能なセクション:executive_summary、development_time、calendar_time、engineering_cost、team_cost、grand_total、claude_roi、assumptions
    • 出力:そのまま貼り付けられる Markdown

これらを直接使用してください。このスキルで必要な判断作業は、分類、調整、説明であり、スクリプトを再実装することではありません。

出力仕様

次の項目を報告してください。

  1. 確定した対象範囲と料金算定の基準
  2. リポジトリの主要な指標と複雑さの要因
  3. エンジニアリング工数と妥当性チェックの結果
  4. エンジニアリングのみの場合とチームコストの範囲
  5. Claude の ROI と確信度
  6. 前提、注意事項、不足データによる制約

コメント