report-pack

レポートパック

2つのスキルを連携させ、オーナーが定期的に確認する数値を、行動に移せるだけの背景情報とともに自動で届けます。パック自体には report-builder、全体像の把握には business-pulse を使います。

オーナーは、欲しいレポートをすでに頭の中に描いています。足りないのは、催促しなくても月曜日に届くことです。ここで行うのは、それだけです。

ステップ 1 — レポートパック（report-builder）

report-builder を呼び出します。仕様、データ取得、計算、ワークブックのすべてを担当するため、ここでそれらを作り直さないでください。

• 入力： オーナーによるパックの説明、または保存済みパックの名前です。
• 出力： チャットでの要約、XLSX ワークブック、保存済みの定義です。

report-builder は、まず保存済みの定義を確認します。パックがすでに存在する場合は、オーナーに再度ヒアリングせずに再実行します。存在しない場合は仕様を作成し、一度だけ確認します。

確認ゲート — 仕様の確認。 新規パックの場合、実行前にオーナーから一度確認を得ます。保存済みの定義があるパックでは確認は不要です。先月定義したレポートの説明を再び求めるのは、このコマンドを使いにくいと感じさせる最短の方法です。

ステップ 2 — コンテキストのスナップショット（business-pulse）

パックの実行後、同じ期間について business-pulse を呼び出します。

• 入力： パックの対象期間です。
• 出力： 現金、売上の推移、パイプライン、注意事項、そして対応が必要な最重要事項です。

パルスは、2つ目のレポートではなく、背景情報です。パックを見るたびに浮かぶ疑問に答えます。数値は動いているけれど、事業は大丈夫なのか？

ここにゲートはありません。 どちらのステップも読み取り専用です。送信、投稿、台帳への書き込みは行わないため、ステップ間でオーナーの承認を得る必要はありません。

ステップ 3 — 1つにまとめて届ける

1つのメッセージで、次の順に届けます。パックの要約、続いて2～3行のパルス、最後にワークブックです。

Okonkwo Mechanical の Ray Okonkwo に、月曜日のパックが届きます。前年と比較したクルー別の売上、売掛金の滞留期間、売上に占める人件費の割合が含まれています。その下には、現金が USD 61,400、60日を超えて未払いの請求書が2件、まだ動かないバンが1台とあります。90秒で両方に目を通し、月曜日に何があるかを把握できます。

成果物を2つに分けて送ってはいけません。パックとパルスが別々に届けば、読むものは2つになります。まとめれば、1つのブリーフィングになります。

そのブリーフィングを、標準のアーティファクトスタイル（../../shared/artifact-style.md）を使った1つの HTML アーティファクトとして表示します。これはチャットの要約とワークブックに追加するものであり、置き換えるものではありません。パックの主要指標は比較情報を補足行に添えた統計タイルにします。グループ化されたレポート行は、桁を揃えた数値の表にします。パルスのコンテキストは、その下の専用パネルに配置し、注意事項にはステータスピル（warn または critical）を付けます。利用できないデータソースは、目立たないフッターの1行にまとめます。

ステップ 4 — 定期実行を一度だけ設定する

オーナーが実行内容に価値を感じた後に、一度だけスケジュールを提案します。 その前ではありません。まだ見たことのないパックについて定期実行を提案すると、サブスクリプションの売り込みのように感じられます。

簡潔に尋ねます。「毎週月曜日の朝にお届けしましょうか？」承諾されたら、レポート定義とともに report-builder に定期実行を保存し、「保存しました。毎週月曜日の朝に実行されます。」と1行で確認します。

その後は、設定どおりに実行します。スケジュール実行のたびに、質問も再確認も定期実行の提案もせず、ステップ 1 から 3 を繰り返します。オーナーに何かを尋ねるスケジュールレポートは、もはやスケジュール実行ではありません。

断られた場合、または返答がない場合は、そのまま取り下げ、二度と尋ねません。

対話形式での実行に限り、スケジュール実行ではない場合にのみ、最後に届けた内容を1行で伝え、最も関連性の高い次のステップを1つ、そのほかに関連する候補を最大2つ添えます。

• パックで現金に関する疑問が生じた場合：「現金予測」で cash-flow-snapshot を実行します。
• パルスで期限超過の売掛金が示された場合：「誰から入金されていないか」で invoice-chase を実行します。
• パックの追跡項目を変更する場合：「レポートを作成して」で report-builder を実行します。

提案は最大3つです。このセッション中にオーナーが断った提案を繰り返してはいけません。

ステップ 5 — データが不足していても実行を止めない

スケジュールされた実行は、すべてのコネクターが正常かどうかにかかわらず行われます。ソースがダウンしている場合、report-builder はその指標を「n/a」とし、ソース名を明記します。パックは引き続き送付します。

データが不完全だからといって、スケジュールされた配信を決して見送らないでください。 1つの欠落と注記があるパックでも役に立ちます。月曜日に何も届かなければ、プラグインが壊れていると思われ、オーナーは届くことを期待しなくなります。

オーナーがコネクターを1つも持っていない場合は、CSV がパックになります。エクスポートを一度だけ依頼し、そのファイルから同じレポートを実行して、定期実行を続けます。

してはいけないこと

• 保存済みのパックについて、オーナーに再度ヒアリングしないでください。 実行のたびに、まず保存済みの定義を確認します。
• ここでレポートのロジックを作り直さないでください。 仕様、計算、ワークブックは report-builder が管理します。
• パルスの数値を再計算しないでください。 数値は business-pulse が管理するため、数値セットは1つに保たれます。
• 配信頻度を2回提案しないでください。 役に立つ実行の後に一度だけ提案し、その後は二度と提案しません。
• スケジュールされた実行時に、何も質問しないでください。 スケジュール実行とは、オーナーが関与しなくても届くものです。
• コネクターが失敗したからといって、実行を見送らないでください。 欠落箇所を明記して送付します。
• パックとパルスを別々のメッセージで配信しないでください。 1つのブリーフィングで、まとめて確認できるようにします。

一覧にないツールを使う場合

このスキルで指定されているコネクターは、テスト済みの接続方法であり、制限ではありません。オーナーが、未接続または未掲載のツールをこのワークフローで使いたい場合は、build-connector を提案します。これはまずコネクターディレクトリを確認し、該当するものがなければ Zapier 経由で接続します。生の API を使って手作業で構築することはありません。接続が確立したら、そのツールもほかの任意のコネクターと同様に、同じ承認ゲートのもとでこのスキルに加わります。