plan-payroll

給与計算の計画

3 つのスキルを順番に実行します。給与資金が確保されているかを把握し、不足していれば不足分を埋め、最後に給与計算を実行します。

オーナーはここで別々の質問を 2 つするわけではありません。「給与を支払えるか」と「給与計算を実行する」は 1 つの懸念事項であり、これを 2 回のセッションに分けると、誰も先に銀行残高を確認しないまま、午後 11 時に給与計算が入力されることになります。

引数を解析します。

• --horizon（デフォルトは 30）— 予測期間（日数）：30、60、または 90
• --payroll-date（任意）— 給与計算の実行日。デフォルトは次回の予定支払日です

ステップ 1 — 給与資金は確保できていますか？（cash-flow-snapshot）

cash-flow-snapshot を呼び出します。予測計算、信頼度の範囲、CSV へのフォールバックはこのスキルが担当します。ここで作り直してはいけません。

• 入力： 予測期間と給与計算の日付。
• 出力： 30／60／90 日の予測、名前付きのリスクフラグ、チャットの要約、XLSX。

ほかのことを伝える前に、判定を 1 行で述べます。資金は確保済み、余裕が少ない、または特定の日付に特定の金額が不足している、のいずれかです。

ゲート — 次に進む処理。 給与資金に十分な余裕がある場合は、回収ステップを省略して直接給与計算に進むかを尋ねます。不足がある場合は不足額を提示し、「回収できるか確認して」という明示的な指示を待ってからステップ 2 に進みます。

ステップ 2 — 不足分を埋める（invoice-chase）

invoice-chase を呼び出します。請求書の順位付け、相手に合わせた文面の調整、請求書の種類ごとの送信方法はこのスキルが担当します。

• 入力： ステップ 1 の不足額と、その不足が発生する日付。
• 出力： 優先順位を付けた期限超過請求書と、それぞれのリマインダーの下書き、PayPal 発行の請求書は PayPal からの送信としてキューに登録され、それ以外はメールの下書きとして登録されます。

順位付けをステップ 1 の結果と関連付けます。予測期間内に回収できる金額と、それで給与資金の不足が実際に解消するかを示します。金曜日の給与計算に対して、45 日後に支払われるリマインダーは役に立ちません。その点を明確に伝えます。

ゲート — 承認なしでは何も送信されません。 オーナーが個別に、または対象を指定した一括送信で送信を指示するまでは、下書きのままにします。

ステップ 3 — 給与計算を準備する（payroll-prep）

payroll-prep を呼び出します。給与期間の設定、労働時間の合計、異常値の確認、帳簿との同期はこのスキルが担当します。

• 入力： 給与期間、従業員名簿、ステップ 1 の資金判定。
• 出力： 従業員ごとの給与計算シート、該当する従業員に紐付けたすべての異常フラグ、合計値、支払日に必要な現金。

ステップ 1 の結果を引き継ぎ、再計算しないでください。payroll-prep が給与計算を実行できるかどうかを報告する際は、このチェーンで既に作成した予測と、ステップ 2 で回収が見込まれる金額を使います。

ゲート — フラグは 1 つずつ確認します。 payroll-prep は各異常を個別に確認します。それらを「問題なさそうですか？」という 1 つの確認にまとめてはいけません。どの異常も、従業員の給与に関わります。

ゲート — 給与計算そのもの。 Gusto が接続されている場合、Gusto で給与計算が準備されます（payroll-prep は承認済みの入力値を update_payroll で書き込み、run_payroll は決して呼び出しません）。QuickBooks Payroll が接続されている場合、コネクターは読み取りのみを行い、給与計算の準備に関する書き込みは行いません。そのため、オーナーが入力するのは検証済みの給与計算シートです。これは現在コネクターが対応している内容であり、劣った手順ではありません。準備が進むのは、データソースから従業員名簿と勤務スケジュールの両方が実際に返された場合に限られます。接続済みのデータソースが従業員の存在を報告しているのに名簿を返さない場合、payroll-prep は準備処理を停止し、チェーンは給与計算シートを明確に提示して終了します。送信するのはオーナーです。 どちらも接続されていない場合は、手入力用の検証済み給与計算シートを納品します。これは完全な結果であり、機能が劣るものではありません。Gusto がブロッカーを報告した場合も同様で、給与計算シートには payroll-prep が返したブロッカーの一覧が引き継がれます。

ステップ 4 — 最後にまとめる

1 回の要約を、次の順に伝えます。資金判定、送信した内容と送信先、リマインダーが支払いにつながった場合の予測残高、準備済みの給与計算（従業員数、総労働時間、総支給額、口座から出る現金額、支払日、未解決のフラグ）。

Ray Okonkwo には次の 4 行で伝えます。15 日に現金が 4,200 USD 不足。3 件のリマインダーを送信し、合計 6,800 USD を請求、そのうち 2 件は予測期間内に回収できる見込み。9 人分の給与計算を 18,340 USD で準備済み。Marcus の打刻漏れ 1 件は未解決。

出力

オーナーが保存した出力設定に従ってステップ 4 のまとめを提供してください。Markdown ファイルをデフォルトにしないでください。 ## Business context ブロックの Output preference（共通スタイルガイドのルール、../../shared/artifact-style.md）を確認してください。

• ビジュアルアーティファクト（デフォルト）： ハウススタイルに沿った HTML ページとしてまとめを表示します。先頭の統計タイルには現金の判定を配置し、送信したリマインダーの数と予測回収額には等幅数字を使用し、ステージング済みの実行の合計と、未解決のフラグがあればその内容をピル形式で表示します。予測される現金には「予測」と明記します。
• docx / md / notion / canva の設定： 同じ内容をその形式で提供します。DOCX または Markdown ファイル、コネクター経由で作成する Notion ページ（指定された保存先を使用し、上書きしない）、または Canva コネクター経由で作成する Canva Doc（実行ごとに新しいデザインを作成し、日付を名前に付ける。表はリストに変換）を使用します。Notion または Canva が接続されていない場合はビジュアルアーティファクトに切り替え、その理由を伝えます。
• このスキルに最適な形式： ビジュアルアーティファクトを使用します。この出力は、「給与を支払えるか」という問いに画面ひとつで答えます。

コネクターの失敗

台帳（オーナーが使用する MYOB、NetSuite、QuickBooks、Xero、Zoho Books のいずれか）に接続できない場合は、そこで停止し、カテゴリ別にその旨を伝えてください。予測は一連の処理の基盤です。決済コネクターまたはメールコネクター（Gmail または M365）に障害が発生した場合は、コネクター名を伝え、残りの処理を続けます。給与システムに障害が発生した場合は、中止せずに実行シートの手順に切り替えます。オーナーが実行できる給与処理を受け取れるようにします。処理をステージングできない場合、または会計システムに同期できない場合（ブロッカー、書き込みアクセス権の不足）は、ステップ 4 のまとめでその旨を伝え、実行シートと仕訳サマリーを提供して、帳簿担当者が入力できるようにします。どの手順を適用するかは、payroll-prep のブロッカーチェックで判断します。

してはいけないこと

• 給与処理を送信しないでください。 一連の処理ではステージングまで行い、送信するのはオーナーです。オーナーから実行するよう頼まれた場合も同じです。
• 承認なしにリマインダーを送信しないでください。 別途指示があるまで下書きにとどめます。
• オーナーから「給与処理だけ実行して」と頼まれた場合でも、ステップ 1 を省略しないでください。 現金確認は 30 秒で済み、この一連の処理が存在する理由でもあります。
• ステップ 3 で予測を再計算しないでください。 現金の数値はひとつの場所から取得した、ひと組だけを使用します。
• 異常のレビューをまとめて行わないでください。 問題ごとに、各担当者について個別に判断します。
• 給与コネクターがないことをブロッカーとして扱わないでください。 実行シートは想定された手順です。給与ソースがないと結論づける前に QuickBooks Payroll を確認してください。QuickBooks を使用している事業者は、Gusto を利用していなくても QuickBooks Payroll を利用していることがよくあります。
• 回収済みの現金として、まだ入金されていない金額を約束しないでください。 予測額はあくまで予測額です。明記してください。
• 一連の処理の出力内に、誰かの SSN、生年月日、自宅住所、または銀行口座番号を記載しないでください（../../shared/personal-data.md）。

一連の処理の後

給与の準備が整い、リマインダーを送信し、オーナーが送信できる状態で処理をステージングしました。次の自然なステップは「請求書の支払い」です。/pay-the-bills では、同じ現金状況を画面に表示しながら、仕入先側の処理を行います。関連する項目として、リマインダーによる回収状況を確認する「現金予測」（cash-flow-snapshot）と、会計期間の終了時に使う「月次締め」（/close-month）もあります。提案は最大 3 件までとし、このセッションですでにオーナーが断った提案は省きます。

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

このスキルで挙げているコネクターは、テスト済みの手順であり、利用できるツールを限定するものではありません。オーナーが、接続されていない、または一覧にないツールをこの手順で使いたい場合は、build-connector を提案してください。まずコネクターディレクトリを確認し、その後は Zapier 経由で接続します。生の API に対して手作業で構築することはありません。接続が確立されたら、そのツールは他の任意のコネクターと同様に、同じ承認ゲートのもとでこのスキルに追加されます。