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