実際の売上データから再発注の判断を自動で行い、全ての記録を帳簿に反映させるツールです。 各商品の売速（売れ行きのペース）と在庫がなくなる予想日を計算し、最適な再発注数量を算出します。発注書と仕入先へのメールを自動作成し、請求書が届いたときに発注書と照合できるよう準備します。 また、売れていない商品に使われたままの資金を特に注意深く追跡するため、不動在庫（回転しない在庫）が再発注されるのではなく処分されるようにします。 **対応するシステム:** Shopify、Square、またはアップロードした売上・在庫データ（CSV形式）で動作します。QuickBooks、Gmail、M365、カレンダー、NetSuiteと連携することで機能を強化できます。 **安全機能:** 発注書の送信と仕入先へのメール送付は、必ず承認を得た後にのみ行われます。 **次のような場合に使用:** - 「何を再発注する必要があるか」 - 「在庫が足りなくなりそうか」 - 「商品の仕入れが必要」 - 「フィルターがすぐになくなってしまう」 - 「仕入先への発注書を作成してほしい」 - 「倉庫にいくら分の資金が眠っているか」
Turns what is actually selling into a reorder decision and gets it all the way into the books — computes sales velocity and conservative stockout dates per item, sizes the reorder, drafts the purchase order and the vendor email, and then stages the matching entry so the bill matches against the PO when it arrives. Flags the money sitting still too, so dead stock gets cleared instead of reordered. Runs on Shopify, Square, or an uploaded sales and stock CSV, and deepens with QuickBooks, Gmail or M365, Calendar, and NetSuite. No PO is sent and no vendor is emailed without approval. Use it when the owner says "what do I need to reorder," "am I going to run out," "restock," "we keep running out of filters," "draft a PO for my supplier," or "how much cash is sitting in the warehouse."
2つのスキルを組み合わせて、発注処理をメールの中に埋もれさせず、帳簿に記録する方法です。inventory-planner（在庫計画）が何を買うかを決め、ap-processor（買掛金処理）がその費用を記録します。
このスキルが解決するのは小さいが高くつく問題です。発注内容は決まり、発注書は作成され、メールは送信される — でも誰も記録に残さないので、6週間後に請求書が届いても、金額と数量のどちらが正しいのか誰にもわかりません。
inventory-plannerを実行します。
inventory-plannerが計算のすべてを管理しているため — 2つの売上速度ウィンドウ、ノイズ処理、リードタイム比較、季節性ルール — ここでやり直さないでください。
チェーンで名前を付けるほど重要な2つのルール：
ゲート — 買付リスト。 何か起案する前に、在庫が切れそうな商品の総額と品目数を表示します。所有者はリストを承認し、削除するか、数量を変更します。各行には売上速度、在庫日数、リードタイム、数量、コストが記載されているため、意思決定は1分で済み、やり直しは不要です。
承認された品目について、inventory-plannerは仕入先ごとに発注書と、所有者の声で書かれたそれに付随するメールを起案します。
ゲート — ステップ1とは別に、両方とも明確な承認を待つ。 買付リストを承認することは、何を発注するかに同意すること。発注書を送信することは、お金を約束し、仕入先関係を消費することです。送信前に、仕入先、品目、合計を記載します。
メールコネクタ（GmailまたはMicrosoft 365）が接続されていない場合、発注書とメールは所有者が手動で送信するファイルです。これは完全な成果です。
ここでは2つの異なることが起こり、どのスキルが何を担当するかが重要です。
inventory-plannerは発注書自体を保管する。 承認された発注書はそのドキュメント — 仕入先、品目、数量、価格、予想日付。ステップ2で保存されて所有者に手渡されます。これが発注内容の記録です。
ap-processorは発注書ではなくコード化されたメモ（会計記録の下書き）を受け取る。 仕入先、発注書番号、合計、予想日付、および支出が属するアカウント、分類、ジョブをそれに提供します。ap-processorは帳簿に発注書を作成しません — 請求書が到着したときにそれを読んで、請求書と発注書と受取チケットの3点照合を実行します。このステップから必要なのは、その照合が探す場所に置かれたコード化された記録です。
ゲート — コーディング承認。 これはap-processor自身のゲートで、ここで保持されます。所有者が承認するまで帳簿には何も記録されず、請求書として、また支払いとしても登録されません。このコマンドでは一切お金が動きません — 到着したものの支払いは/pay-the-billsです。
新しい仕入先でコードが不確実な場合、ap-processorは推測するのではなく質問します。1年間の誤分類を防ぐには、今この質問をする方が良いです。
帳簿コネクタがない場合、コード化されたメモはインポートファイルと発注書の横の概要として出力されます。3点照合は後で手動で、存在するレコードに対して実施されます。
Ray Okonkwoは、Okonkwo Mechanicalを部品棚から何かが不足しているときに確認することで運営しています。それは常に手遅れです。Google Calendarが接続されている場合、1回だけ提案してください — 所有者が有用だと思った在庫補充の後 — カレンダーに発注決定の定期的なブロックを設定します。
これは緊急対応より定期的なリズムとしてはるかに機能します。1回だけ提案してください。拒否されたか沈黙の場合は、それをやめてください。
売上CSVと在庫数カウントは完全にサポートされた入力です。多くの企業はクリップボードで数えます。それは正当なデータです。売上速度、在庫切れ日付、発注サイズ、発注書、仕入先メールはすべて同じように出力されます。帳簿エントリはインポートファイルになります。
/pay-the-billsです。所有者の保存された出力設定に従って発注計画を配信 — マークダウンファイルにデフォルト設定しないでください。 ## ビジネスコンテキストブロックの出力設定を確認してください（共有スタイルガイドルール、../../shared/artifact-style.md）：
発注書は出力され、コード化された記録は請求書の照合を待っています。これらの請求書が到着したときに、次の自然なステップは「請求書を支払う」です — /pay-the-billsは照合、キャッシュチェック、支払いゲートを実行します。近くにあるもの：「キャッシュ予測」（cash-flow-snapshot）で、約定された発注が次の60日間に何をするかを確認し、期間の終了時に「月を締める」（/close-month）。最大3つまで提案し、所有者がこのセッション中に既に拒否したものはスキップしてください。
このスキルで名前を付けたコネクタはテスト済みの経路であり、壁ではありません。所有者がこのフローが接続されていないか列挙されていないツールを使用したいと思う場合、build-connectorを提案してください — コネクタディレクトリを最初に確認し、その他の場合はZapierを通じて接続します。生APIに対して手動構築することはありません。接続が存在したら、ツールは他のオプションのコネクタと同じように、同じ承認ゲートの下でこのスキルに参加します。
Chain two skills so reordering ends in the books rather than in a forgotten email: inventory-planner decides what to buy, ap-processor stages what it will cost.
The gap this closes is small and expensive. The reorder gets figured out, the PO gets drafted, the email gets sent — and then nothing is recorded anywhere, so when the bill lands six weeks later nobody can tell whether the price or the quantity was right.
Invoke inventory-planner.
inventory-planner owns all of the math — the two velocity windows, the distortion handling, the lead-time comparison, the seasonality rule. Do not redo any of it here.
Two of its rules matter enough to name in the chain:
Gate — the buy list. Show the total dollars and the count of items about to stock out before anything is drafted. The owner approves the list, trims it, or changes quantities. Every line carries its velocity, days of cover, lead time, quantity, and cost, so the decision takes a minute instead of a rebuild.
For the approved lines, inventory-planner drafts a purchase order per vendor and the email to go with it, written in the owner's voice.
Gate — both wait for an explicit yes, separately from Step 1. Approving the buy list is agreeing on what to order. Sending the PO is committing the money and spending the vendor relationship. State the vendor, the line items, and the total before asking.
Without a mail connector (Gmail or Microsoft 365) connected, the PO and the email are files the owner sends by hand. That is a complete outcome.
Two different things happen here, and it matters which skill owns which.
inventory-planner keeps the purchase order itself. The approved PO is its document — vendor, line items, quantities, prices, expected date. It is saved and handed to the owner in Step 2, and that is the record of what was ordered.
ap-processor takes the coded memo, not the PO. Hand it the vendor, the PO number, the total, the expected date, and the account, class, and job the spend belongs to. ap-processor does not create purchase orders in the ledger — it reads them when a bill arrives, to run the three-way match of bill against PO against receiving ticket. What it needs from this step is a coded record sitting where that match will look for it.
Gate — the coding approval. This is ap-processor's own gate and it holds here. Nothing is written to the ledger until the owner says yes, and nothing lands as a bill and never as a payment. No money moves in this command at all — paying for what arrives is /pay-the-bills.
If a code is uncertain on a new vendor, ap-processor asks rather than guessing. One question now beats a miscoded year.
Without a ledger connector, the coded memo comes out as an import file and a summary alongside the PO. The three-way match still happens later, by hand, against a record that exists.
Ray Okonkwo runs Okonkwo Mechanical off a parts shelf he checks when something is missing, which is always too late. With Google Calendar connected, offer once — after a restock the owner found useful — to put a recurring block on the calendar for the reorder decision.
This works far better as a rhythm than as a fire drill. Offer it once. On a no or on silence, drop it.
A sales CSV plus a stock count is a fully supported input. Many businesses count on a clipboard, and that is legitimate data. Velocity, stockout dates, reorder sizing, the PO, and the vendor email all come out the same. The books entry becomes an import file.
/pay-the-bills.Deliver the reorder plan per the owner's stored output preference — never default to a markdown file. Check the ## Business context block's Output preference (shared style guide rule, ../../shared/artifact-style.md):
The POs are out and a coded record is waiting for the bills to match against. When those bills land, the natural next step is "pay the bills" — /pay-the-bills runs the match, the cash check, and the payment gate. Also nearby: "cash forecast" (cash-flow-snapshot) to see what the committed orders do to the next 60 days, and "close the month" (/close-month) when the period ends. Offer at most three, and skip any offer the owner already declined this session.
The connectors named in this skill are the tested paths, not a wall. If the owner wants this flow to use a tool that isn't connected or listed, offer build-connector — it checks the connector directory first and connects through Zapier otherwise, never hand-building against a raw API. Once the connection exists, the tool joins this skill like any other optional connector, under the same approval gates.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。