restock
依銷售速度算補貨量，起草 PO 與廠商信並對上帳務
中文翻譯
--- name: restock description: 把實際賣得動的東西轉成補貨決策，並一路走進帳裡：算出每個品項的銷售速度和保守的缺貨日期、決定補貨量、起草採購單（PO）和給廠商的 email，再建立對應的帳務條目，讓帳單到貨時可以對上 PO。同時標出卡住不動的資金，讓滯銷品被清掉而不是被再次補貨。可以在 Shopify、Square 或上傳的銷售與庫存 CSV 上運作，接上 QuickBooks、Gmail 或 M365、Calendar 和 NetSuite 會更完整。沒有經過核准，不會送出任何 PO、也不會寄信給任何廠商。當老闆說「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」或「how much cash is sitting in the warehouse」時使用。 allowed-tools: Read, WebFetch --- # Restock 把兩個 skill 串起來，讓補貨最後落在帳裡，而不是落在一封被遺忘的 email：`inventory-planner` 決定要買什麼，`ap-processor` 建立這些東西要花多少錢的條目。 這個流程補的缺口很小，但代價很高。補貨算好了、PO 起草了、email 寄出去了，然後什麼都沒記在任何地方，六週後帳單來了，沒人說得出價格或數量對不對。 ## Step 1 — 算出要買什麼（inventory-planner） 呼叫 `inventory-planner`。 - **輸入：** 來自 Shopify、Square 或 NetSuite 的銷售歷史和現有庫存，或是兩者都有的上傳 CSV。 - **輸出：** 每個品項的 7 天和 28 天銷售速度、保守的缺貨日期、附金額成本的 60 天補貨量，以及另外一份滯銷品清單。 `inventory-planner` 負責所有的計算：兩個速度時間窗、扭曲值的處理、和前置時間的比較、季節性規則。這裡不要重做任何一項。 它有兩條規則重要到值得在串接流程裡點出來： - **零銷售速度的品項絕對不是補貨候選。** 它們會以滯銷品的身分出現，並附上卡在裡面的資金。沒有銷售代表停止購買，不是多買。 - **缺貨期間不等於零需求。** 那是被壓抑的需求，把它當成零，這個品項就會永遠少訂。 **關卡：採購清單。** 在起草任何東西之前，先秀出總金額和即將缺貨的品項數。老闆核准清單、刪減，或是改數量。每一行都要附上銷售速度、庫存可撐天數、前置時間、數量和成本，讓決定只花一分鐘，不用重做。 ## Step 2 — 起草 PO 和給廠商的 email（inventory-planner） 針對核准的品項，`inventory-planner` 依廠商各起草一份採購單，以及配套的 email，用老闆的口吻寫。 **關卡：兩者都要等明確的同意，和 Step 1 分開。** 核准採購清單是同意要訂什麼。送出 PO 是把錢承諾出去，也是在消耗和廠商的關係。詢問之前，先說清楚廠商、品項明細和總金額。 沒有連接郵件 connector（Gmail 或 Microsoft 365）時，PO 和 email 就是老闆自己手動寄的檔案。這是完整的結果。 ## Step 3 — 留下未來的帳單可以對上的紀錄 這裡發生兩件不同的事，哪個 skill 負責哪件很重要。 **`inventory-planner` 保管採購單本身。** 核准後的 PO 是它的文件：廠商、品項明細、數量、價格、預計到貨日。它會在 Step 2 儲存並交給老闆，那就是「訂了什麼」的紀錄。 **`ap-processor` 拿的是編碼過的備忘，不是 PO。** 把廠商、PO 編號、總額、預計日期，以及這筆支出所屬的科目、class 和 job 交給它。`ap-processor` 不會在帳務系統裡建立採購單，它是在帳單到達時讀取採購單，來做帳單、PO、收貨單的三方比對（three-way match）。它從這一步需要的，是一份編碼過的紀錄，放在比對時會去找的地方。 - **輸入：** 廠商、PO 編號、總額、預計日期，以及編碼。 - **輸出：** 一份歸在該廠商底下、編碼過的備忘，這樣六週後帳單到的時候，價格和數量可以和實際核准的內容核對。 **關卡：編碼核准。** 這是 `ap-processor` 自己的關卡，在這裡照樣適用。在老闆說好之前，不會有任何東西寫進帳務系統，而且寫進去的只會是帳單，絕對不是付款。**這個指令完全不會動到任何錢**，付錢給到貨的東西是 `/pay-the-bills` 的事。 如果新廠商的某個編碼不確定，`ap-processor` 會問，而不是猜。現在問一個問題，勝過整年編錯碼。 沒有帳務 connector 時，編碼過的備忘會以匯入檔和摘要的形式，跟 PO 放在一起。三方比對之後還是會發生，只是手動做，對著一份確實存在的紀錄。 ## Step 4 — 變成固定節奏 Ray Okonkwo 的 Okonkwo Mechanical 靠一個零件架運作，他是缺東西的時候才去看，而那永遠太晚。如果有連接 Google Calendar，在老闆覺得有用的那次補貨之後，提議一次：在行事曆上排一個週期性的時段來做補貨決策。 這樣做當成固定節奏，遠比當成救火有效。只提議一次。對方說不要或沒回應，就放掉。 ## 備案路徑 銷售 CSV 加上庫存盤點，是完全支援的輸入。很多生意是用寫字板盤點的，那也是正當的資料。銷售速度、缺貨日期、補貨量、PO 和給廠商的 email 全部都會一樣產出來。帳務條目則變成匯入檔。 ## 不要做的事 - **沒有核准，不要送 PO 或廠商 email。** 一個花的是錢，另一個花的是人情。 - **不要把採購清單的核准當成送出的核准。** 兩道關卡，兩個決定。 - **不要補零銷售速度的品項。** - **決定補貨量時，不要沒扣掉已經在途的數量。** 重複訂購滯銷品，會把資金埋好幾年。 - **不要編造銷售速度、前置時間或缺貨日期。** 歷史資料太少，就依 SKU 回報。 - **不要在這裡付任何款。** PO 只是建立條目，不是付款。付款是 `/pay-the-bills`。 - **不要只報數量不報金額。** 老闆在決定的是現金，不是件數。 ## 輸出 **依老闆儲存的輸出偏好交付補貨計畫，絕對不要預設成 markdown 檔。** 檢查 `## Business context` 區塊裡的 `Output preference`（共用風格指南規則，`../../shared/artifact-style.md`）： - **Visual artifact（預設）：** 把計畫渲染成符合 house style 的 HTML 頁面：承諾的總額用金額當作最前面的 stat tile，每個 SKU 一列，銷售速度、缺貨日期、補貨量用等寬數字，已經在途的東西加一個 pill。PO 文件和任何匯入檔當作工作檔一起附上，不算第二份成品。 - **docx / md / notion / canva 偏好：** 用該格式交付同樣的內容：DOCX 或 markdown 檔、透過 connector 建立的 Notion 頁面（指定目的地，絕對不覆寫），或透過 Canva connector 建立的 Canva Doc（每次執行建立新設計，用日期命名；表格改成清單）；如果沒連 Notion 或 Canva，就退回 visual artifact，並說明這是原因。 - **Best for skill：** 用 visual artifact，因為這個輸出是一個採購決策，不是文章。 ## 執行之後 PO 已經送出，一份編碼過的紀錄在等帳單來對。那些帳單到的時候，自然的下一步是「pay the bills」：`/pay-the-bills` 會做比對、現金檢查和付款關卡。附近還有：「cash forecast」（`cash-flow-snapshot`），看已承諾的訂單對未來 60 天的影響；以及期間結束時的「close the month」（`/close-month`）。最多提供三個，這個 session 裡老闆拒絕過的就跳過。 ## 使用沒列在清單上的工具 這個 skill 裡提到的 connector 是測試過的路徑，不是一道牆。如果老闆想讓這個流程用一個沒連接或沒列出的工具，就提供 `build-connector`：它會先查 connector 目錄，找不到再透過 Zapier 連接，絕對不會對著原始 API 手刻。連線建立之後，這個工具就像其他可選的 connector 一樣加入這個 skill，並受相同的核准關卡約束。
英文原文
--- name: restock description: 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." allowed-tools: Read, WebFetch --- # Restock 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. ## Step 1 — Work out what to buy (inventory-planner) Invoke `inventory-planner`. - **Goes in:** sales history and stock on hand from Shopify, Square, or NetSuite, or an uploaded CSV of both. - **Comes out:** 7-day and 28-day velocity per item, conservative stockout dates, a sized 60-day reorder with dollar costs, and a separate slow-mover list. `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: - **Zero-velocity items are never reorder candidates.** They come through as slow movers with the cash tied up in them. No sales means stop buying, not buy more. - **An out-of-stock period is not zero demand.** It is suppressed demand, and treating it as zero under-orders the item forever. **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. ## Step 2 — Draft the PO and the vendor email (inventory-planner) 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. ## Step 3 — Leave a record the future bill can match against 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. - **Goes in:** vendor, PO number, total, expected date, and the coding. - **Comes out:** a coded memo filed against the vendor, so when the bill lands in six weeks the price and the quantity can be checked against what was actually approved. **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. ## Step 4 — Make it a rhythm 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. ## Fallback path 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. ## What not to do - **Do not send a PO or a vendor email without approval.** One spends money, the other spends goodwill. - **Do not treat the buy-list approval as approval to send.** Two gates, two decisions. - **Do not reorder a zero-velocity item.** - **Do not size a reorder without subtracting what is already inbound.** Double-ordering a slow item buries cash for years. - **Do not invent a velocity, a lead time, or a stockout date.** Too little history is reported by SKU. - **Do not pay anything here.** POs are staged, not paid. Payment is `/pay-the-bills`. - **Do not report units without dollars.** The owner is deciding about cash, not pieces. ## Output **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`): - **Visual artifact (the default):** render the plan as an HTML page in the house style — total committed as the lead stat tile in dollars, each SKU a row with velocity, stockout date, and reorder size in tabular-nums, and a pill on anything already inbound. The PO documents and any import file ride along as working files, not second deliverables. - **docx / md / notion / canva preference:** deliver the same content in that form — a DOCX or markdown file, a Notion page created via the connector (named destination, never overwriting), or a Canva Doc created via the Canva connector (a new design each run, named with the date; tables become lists); fall back to the visual artifact if Notion or Canva is not connected — and say that is why. - **Best for skill:** use the visual artifact — this output is a buy decision, not prose. ## After the run 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. ## Using a tool that isn't listed 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.