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チャンネルのアクセスを管理 — ペアリングの承認、許可リストの編集、DM/グループポリシーの設定。ユーザーがペアリングを依頼したり、誰かを承認したり、誰が許可されているかを確認したりする際に使用します。
official
session-report
anthropic
~/.claude/projectsのトランスクリプトから、Claude Codeセッションの使用状況(トークン、キャッシュ、サブエージェント、スキル、高コストなプロンプト)を探索可能なHTMLレポートとして生成します。
official
build-mcp-server
anthropic
このスキルは、ユーザーが「MCPサーバーを構築する」「MCPを作成する」「MCP統合を行う」「Claude用のAPIをラップする」「ツールを公開する…」と依頼した場合に使用します。
official
cookbook-audit
anthropic
ルーブリックに基づいてAnthropic Cookbookのノートブックを監査します。ノートブックのレビューや監査が依頼されたときに使用してください。
official
handle-complaint
anthropic
顧客からのクレームをエンドツーエンドで処理します — コンテキストを取得し、返信を作成し、運用上の修正案を提案します。オプションでメールやチケットIDを受け付けます…
official
use-case-triage
anthropic
処理活動がPIA、必須のGDPR DPIAを必要とするか、またはそのまま進められるかを迅速に判断し、プライバシーポリシーの競合を表面化させて適切なルートへ導きます…
official
board-minutes
anthropic
取締役会や委員会の議事録を自社のフォーマットで草稿します。カレンダーから今後の取締役会や委員会の会議を自動検出し、議題などを尋ねます…
official
renewal-tracker
anthropic
維持された更新登録簿をもとに、キャンセル期限が迫っている契約を表示し、通知期間が終了する前に警告します。ユーザーが尋ねたときに使用します…
official