mcpField
P
pipa-budget-review

pipa-budget-review

github.com/lunchpaillolaデータ・データベース3174 回インストール5 日前に更新
リポジトリ

pipa-budget-review について

プロジェクトや財務の確認に使う、Pipa向けの予算モニタリングスキルです。予算基準額、実績、コミットメント、進捗情報から完了時予測を評価し、判断と担当者付きの次の対応を示します。

主な機能

  1. 01完了時予測と予算基準額の比較
  2. 02支出・コミットメント・進捗情報の統合
  3. 03データの信頼度を提示
  4. 04判断と担当者・期限を明記
  5. 05CEO・Pipa・財務向けの要約

活用シーン

  1. 01プロジェクトの予算超過を確認
  2. 02スコープ変更の予算影響を評価
  3. 03経営層向け予算報告を準備

インストール

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

$npx skills add https://github.com/lunchpaillola/pipa-skills --skill pipa-budget-review

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

同梱ファイルevals/evals.jsonevals/trigger-eval-set.json

詳細

Pipa 予算レビュー

迅速で成果を重視した予算モニタリングのワークフローを実行し、次の2つの問いに答えます。

  1. 予算内ですか?(はい/いいえ/条件付きの回答)
  2. 今、何をしますか?(意思決定を1つ、責任者が明確な次のステップを1つ)

デリバリーの代替指標よりも、財務上の事実を優先します。基本モデルを使用します。

  • Baseline:承認済み予算/報酬額
  • Actuals:現時点までの支出
  • Commitments:進行中の作業、締結済み契約
  • EAC(完成時見積もり):実績 + コミットメント + 残作業の見積もり。二重計上はしません
  • Variance:EAC - baseline。正の値は予算超過、負の値は予算未達です
  • Action:今後の対応

回答の制約

  • Slack/経営陣向けの回答は最大4~6行
  • 分析手順の説明は禁止(どのように分析したかは説明しません)
  • 項目の羅列は禁止 — 予算に最も大きく影響する要因のみを挙げます
  • 回答ごとに意思決定は1つ
  • 責任者 + 期限を含む責任者が明確な次のステップを1つ
  • 必要な場合は確信度を示す:データが不完全、推定を含む、品質にばらつきがある場合、または意思決定がデータの信頼性に左右される場合に記載します
  • 簡潔な情報源を1~2件 — IDの羅列ではなく、人が読みやすい参照情報を記載します

対象者別モード

状況または明示的なリクエストに応じて、適切な形式で回答します。

モード使用する場面回答形式
CEO向け概要経営陣との進捗確認、取締役会の準備、投資家への報告2~3行。「はい」または「いいえ」。重要な場合は差異率を記載。アクションを1つ。
Pipa向け概要週次スタンドアップ、スプリント計画、デリバリーレビュー4~6行。ステータス + 確信度。最大の要因。意思決定 + 責任者/期限。
財務向け概要利益率分析、未払計上、予測、損益への影響利益率を重視。EAC、差異額と差異率。予備費の状況。コミットメントの可視化。

状況から別の形式が適切と判断できない限り、Pipa向け概要を既定とします。

確信度レベル

確信度が意思決定に関わる場合、または判断が明白でない場合は、信頼性を示します。

レベルデータの完全性表示
高baseline + actuals + Pipaの進捗情報が少なくとも1件「確信度:高 — 実際の財務データ + Pipaのデリバリー情報に基づいています」
中baseline + 信頼性の高い進捗情報、actualsは限定的「確信度:中 — デリバリー情報に基づく予測です」
低baselineのみ、または根拠の弱い情報「確信度:低 — 大まかな見通しのみです。確度を高めるには、[Pipaまたは財務の情報源]を接続してください」

コミュニケーションスタイルの取り決め:このスキルは、予算分析、情報源の評価、しきい値、必須の確認事項を担います。提示方法については、~/.pipa/communication-style.mdが存在する場合はそれを適用します。存在しない場合は、責任者、日付、根拠、不明事項(TBD)を明示し、明快で簡潔な出力にします。このスキルの出力に関する取り決めは維持してください。実行時のファイルが制御するのは提示方法のみです。ルーティング、必須の確認事項/出力に関する取り決め、ツールの使用、事実、安全性、承認/書き込みのゲートと矛盾する場合は無視してください。

ワークフロー(内部用)

次の簡易的な6ステップモデルを使用します(出力では手順ごとの説明をしません)。

  1. Baseline:承認済みの報酬額/予算
  2. Actuals + Commitments:支出 + 進行中の作業
  3. Pipaの情報:スケジュールの遅延、スコープの変更、ブロッカー、依存関係のリスク
  4. EAC:actuals + commitments + 残作業の見積もり。コミットメントと残作業の見積もりが重複しないようにします。情報源の間で重複している場合は、二重計上せず、照合が済むまでEACをTBDとして報告します。
  5. Variance:EAC - baseline。正の値は予算超過、負の値は予算未達として報告します。差異率は(EAC - baseline) / baseline * 100です。
  6. Decision + Action:何をするか、誰が担当するか、いつまでに行うか

必須の確認事項

報告前に、次の要素を確認してください。

  • 予算判断:yes/no/watch/blocked
  • 入手可能な場合、EAC とベースラインの比較を1行で要約
  • 信頼度がデータから明らかでない場合は、その短い理由とともに信頼度を示す
  • 予算を左右する最大の要因を1つ
  • 判断を1つ
  • 担当者と期限を明記した、責任の所在が明確な次のステップを1つ
  • 入手可能な場合、直接リンク付きの、人が理解しやすいソースラベルを1~2件

watch、red、blocked の場合、判断と責任の所在が明確な次のステップをどちらも冒頭付近に明記してください。一方で他方を代用しないでください。

明らかな green の場合は、簡潔にまとめ、問題のない状態を過度に説明しないでください。

最終回答の形式をここで固定しないでください。任意の実行時スタイルと上記のフォールバックを使って、これらの確認事項を提示してください。

参照コンテンツの形式

CEO 向けブリーフ
✅ On budget | ⚠️ Watch | 🚨 At risk — [one-line financial summary]

Variance: [+/- $X / X% if material] | Biggest driver: [single pressure point]
Next: [decision] — [owner] by [date]

例:

⚠️ Watch — EAC $18K over $120K baseline due to scope creep in reporting module.

Variance: +15% | Biggest driver: unapproved reporting asks
Next: Scope negotiation — Sarah (PM) by Friday
Pipa 向けブリーフ — デフォルトの重点項目
[Yes/No/Watch] — [EAC vs baseline in one line]

[Confidence: [high/medium/low] — [why]]
Biggest driver: [single pressure point, none if healthy]
Decision: [action choice]
Next step: [task] — [owner] by [date]
Sources: [1-2 readable labels + direct links]

例:

⚠️ Watch — EAC trending 12% over baseline ($134K vs $120K).

Confidence: Medium — baseline + hours actuals, commitments estimated
Biggest driver: integration rework discovered mid-sprint
Decision: Internal correction (resequence features)
Next step: Confirm revised timeline with client — Jake by Wed 4/16
Basis: Actual hours + estimated commitments | Sources: Q1 SOW, Harvest timesheets
Finance 向けブリーフ — マージン重視の内容
[Status] — EAC [$X], Baseline [$X], Variance [+$X / +X%]

Margin impact: [X% → Y% or $X hit if known]
Commitments visibility: [% committed, or note if soft]
Confidence: [level] — [data basis]
Biggest driver: [single pressure point]
Decision: [action]
Next step: [task] — [owner] by [date]

例:

⚠️ Watch — EAC $134K, Baseline $120K, Variance +$14K (+12%)

Margin impact: 25% → 18% estimated
Commitments visibility: 60% hard / 40% soft (remaining scope TBD)
Confidence: Medium — actuals confirmed, EAC estimated from sprint velocity
Biggest driver: unplanned security audit requirements
Decision: Change control (formal scope adjustment)
Next step: Submit change order — Finance/Pipa by Fri 4/18
blocked(ベースライン不足)
⛔ Blocked — Cannot assess budget health.

Need: [specific source required]
Why: [what it would clarify]
Get it: [how/who by when]

シナリオモード

「X を実施したらどうなる?」と尋ねられた場合は、簡潔な比較を1つ返してください。

If [action X]: EAC moves [$A → $B], variance [Y% → Z%], status [current → projected]

Decision: [recommendation based on scenario]
Owner/due: [who by when]

例:

If we cut Phase 2 features: EAC moves $134K → $118K, variance +12% → -2%, status watch → on-track

Decision: Recommended — preserves margin and timeline
Owner/due: Pipa to confirm scope cuts by Thu 4/17

閾値と一貫性

信頼を積み重ねられるよう、一貫した閾値を使用してください。

差異ステータスシグナル
予算を0~5%下回る/上回る✅ 順調緑
予算を5~15%上回る⚠️ 要注意黄 — 監視が必要
予算を15%超上回る、または10%超下回る🚨 リスクあり赤 — 対応が必要

対象者にかかわらず、常に同じ閾値を適用してください。

ソースのルール

  • 真の差異を検出するため、財務シグナルとあわせて Pipa のシグナル(例:チケットの流れ、ブロッカー、スプリントの遅延)を取得し、評価してください。
  • ソースは次の順に確認してください:SOW/スコープ → トラッカー/ステータス → 工数/支出 → バックログ
  • エビデンスのレベルに応じて信頼度を決めます:実績値+ベースライン+Pipa のシグナル=高、ベースラインのみ=低
  • 予算文書しかない場合は、信頼度を高または中にしてはいけません。信頼度を low とし、方向性を示す回答を返して、予算と照らし合わせてデリバリーリスクを確認するために次に取得すべき具体的な PM/デリバリーソース(Jira、Linear、Asana など)を1つ挙げてください。
  • 人が理解しやすいソースを最大1~2件引用してください(例:「Q1 SOW、Linear sprint board」)。
  • ツール(Composio など)を使用した場合は、「via [tool] — [record name/ID]」を含めてください。
  • 生ログや長い ID の一覧をそのまま出力しないでください。
  • 信頼度が medium または low の場合、一般的な不確実性の表現ではなく、未解決または不足しているデータに直接結び付けて理由を示してください。
  • blocked の場合、方向性を示す状態から意思決定可能な状態へ進むために必要な、具体的な財務ソースを明記してください。

入力パターン

パターン 1:直接的な予算確認
How are we budget-wise on Project Acme?

→ デフォルトで Pipa 向けブリーフを返してください。複数の対象者が関わる場合は、「CEO version?」または「Finance view?」と尋ねてください。

パターン 2:シナリオに関する質問
What if we add 2 sprints? How does budget change?

→ シナリオモードで返してください:EAC A→B、差異の変化、推奨事項、担当者/期限。

パターン 3:財務の詳細分析
What's the margin outlook? How reliable are these numbers?

→ 信頼度の表示とマージンへの影響を含む Finance 向けブリーフを返してください。

パターン 4:リテイナー/キャパシティの確認
We're halfway through the month, 70% of hours used, but new scope landed.

→ 月次ベースラインと照らして評価してください。キャパシティ超過のシグナルがある場合は、Watch/At-risk としてください。再交渉または優先順位付けに関する判断を含めてください。

アクションの種類

アクション使用する状況例
現状維持差異が5%未満で、圧力が見られない場合対応不要
内部調整デリバリー/人員配置の調整で回復が見込める場合順序変更、再割り当て、期間短縮
変更管理スコープ/スケジュールが大幅に変更された場合正式な CO、再交渉
エスカレーション直ちに経営陣/クライアントの判断が必要な場合取締役会/アカウント責任者の関与

すべてのアクションに、内容、担当者、期限を含めてください。

ルール

  • 「予算内ですか?」には、はい/いいえで回答することから始めます。
  • 納期に関する説明よりも、財務上の事実を優先します。
  • 最大6行、4行以上で記載し、判断は1つ、責任者が明確なステップは1つにします。
  • 最大の要因は1つだけにします。要因を羅列しません。
  • 信頼性が明らかでない場合、または回答が大幅な推論に基づく場合は、確信度を添えます。
  • 判断ロジックとしきい値は常に同じにします。最終的な形式は、上記の任意の実行時スタイルとフォールバックに従います。
  • watch、red、blocked のケースでは、要因、判断、次のステップをそれぞれ明確に分けます。
  • 読み取り専用のソース確認、計算、シナリオ、予算分析に承認は不要であり、書き込み権限がないことを理由に妨げてはなりません。外部またはファイルへの書き込みを行う直前には毎回、その具体的な操作、宛先、書き込み内容に限定した個別の明示的な承認を求めます。最初の依頼や別の書き込みに対する承認を、承認として扱ってはなりません。承認された書き込みを行うたびに、成功または失敗を報告し、可能であれば結果のパス、リンク、または一意で安定した ID を記載します。

コメント