reorder-policy

作者: anthropic

如何決定是否以及多少數量重新訂購一個SKU。每當任務涉及補貨建議、採購訂單或「我們應該補貨嗎」…時,請載入此項。

npx skills add https://github.com/anthropics/cwc-workshops --skill reorder-policy

Reorder Policy

This skill encodes StockPilot's reorder rules. Use it whenever you need to decide whether to reorder a SKU and how many units to order.

Inputs you need

ValueWhere to get it
on_handLatest row for the SKU in /mnt/user/data/stock_levels.csv (sum across warehouses unless the task is warehouse-specific)
reorder_point/mnt/user/data/products.csv
avg_daily_salesMean of units_sold over the last 14 days in /mnt/user/data/sales_history.csv
lead_time_daysFrom the chosen supplier (see the supplier-selection skill)
forecast_qty, confidence, flagsFrom the forecasting skill, only if the task looks forward more than 14 days or mentions a promo/season

Decision rules

  1. Do we reorder at all? Reorder if on_hand < reorder_point. If on_hand ≥ reorder_point, the answer is "no reorder needed" — stop here.

  2. How much? The target order quantity is 30 days of cover plus safety stock, minus what's already on hand:

    safety_stock = 1.5 × avg_daily_sales × lead_time_days
    order_qty    = (avg_daily_sales × 30) + safety_stock − on_hand
    

    Round up to the supplier's min_order_qty multiple.

  3. Confidence guard. If you obtained a forecast and confidence < 0.6, do not place a PO automatically. Instead:

    • Write an escalation to /mnt/user/sinks/outbox.jsonl using the notify-templates skill (escalation template), including the flags from the forecast.
    • In your final answer, state the recommended quantity and that it requires human review, with the reason.
  4. Expedite? If on_hand / avg_daily_sales < lead_time_days (you'll stock out before the order arrives), pick the supplier with the shortest lead time even if it's not the cheapest, and note "expedited" in the PO.

Worked example

SKU-0057: on_hand = 38, reorder_point = 120, avg_daily_sales = 18.2, chosen supplier lead_time_days = 7, min_order_qty = 50.

  • 38 < 120 → reorder.
  • safety_stock = 1.5 × 18.2 × 7 = 191.1
  • order_qty = (18.2 × 30) + 191.1 − 38 = 546 + 191.1 − 38 = 699.1 → round up to next 50 → 700
  • 38 / 18.2 = 2.1 days of cover, lead time is 7 → expedite.

Prioritization (when many SKUs are at risk)

Sort by tier, then by days-of-cover ascending within a tier:

  1. Stockoutson_hand = 0 at any warehouse. Always first.
  2. Will stock out before PO arrivesdays_of_cover < lead_time_days. Expedite or transfer.
  3. High-velocity below reorder — top-100 sellers below reorder point.
  4. Routine replenishment — everything else below reorder point.
  5. Trending toward reorder — note only, no action.

If you can't action every SKU in one pass, say how many you handled, how many remain, and list the remaining SKU IDs so the next run picks them up.

Transfer vs reorder

When one warehouse is low and another has surplus:

  • Transfer when the surplus warehouse has >30 days cover for itself, the 3–5 day transfer beats the best supplier lead, and the qty needed is ≲200 units. WH-CENTRAL is the default source.
  • Reorder when no warehouse has surplus, the qty is large, or supplier lead is comparable to transfer lead anyway.
  • Both when the shortage is urgent and large — transfer a bridge qty now, PO the remainder.

State which path you chose and why.

Compliance

  • Any single PO over $10,000 needs a one-line rationale included with the PO so ops can copy it into the ERP.
  • If you place more than five POs in one task, end with a one-line total committed spend.
  • Do not place a second PO for a SKU that already has an open PO covering the need.

Output

When you act, append to /mnt/user/sinks/purchase_orders.jsonl:

{"sku": "SKU-0057", "supplier_id": "SUP-03", "qty": 700, "expedite": true, "reason": "below reorder point; 2.1d cover"}

When you only recommend (no side-effect requested), return a structured ReorderDecision:

{"sku": "...", "reorder": true, "qty": 700, "supplier_id": "SUP-03", "expedite": true, "confidence": 0.85, "notes": "..."}

來自 anthropic 的更多技能

access
anthropic
管理 Discord 頻道存取權限 — 核准配對、編輯允許清單、設定私訊/群組政策。當使用者要求配對、核准某人、查詢誰被允許時使用…
official
session-report
anthropic
從 ~/.claude/projects 的對話記錄中,生成一份可探索的 HTML 報告,內容涵蓋 Claude Code 工作階段的使用情況(包含 token、快取、子代理、技能及高成本提示)。
official
build-mcp-server
anthropic
當使用者要求「建立 MCP 伺服器」、「建立 MCP」、「製作 MCP 整合」、「為 Claude 包裝 API」、「暴露工具給…」時,應使用此技能。
official
cookbook-audit
anthropic
根據評分標準審核 Anthropic Cookbook 筆記本。每當要求進行筆記本審查或審核時使用。
official
handle-complaint
anthropic
處理進線客戶投訴的完整流程——提取背景資訊、草擬回覆,並建議營運改善方案。可接受選填的電子郵件或工單編號……
official
use-case-triage
anthropic
快速判斷某項處理活動是否需要PIA、強制性的GDPR DPIA,或可直接進行——揭露隱私政策衝突,並引導至正確的…
official
board-minutes
anthropic
根據您指定的格式,自動草擬董事會或委員會會議記錄。自動從您的日曆中偵測即將召開的董事會及委員會會議,詢問議程及…
official
renewal-tracker
anthropic
顯示即將到來的取消截止日期的合約,並在通知窗口關閉前發出警告,依據維護中的續約登記表進行操作。當用戶詢問時使用…
official