Inventory Planner
AnthropicOfficialPublished by Anthropic
- Skill
- Workflow
- Business and productivity
- Apache-2.0
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
Inventory Planner helps businesses optimize stock levels by analyzing sales history and current inventory. It calculates sales velocity over 7-day and 28-day windows to project stockout dates and determine appropriate reorder quantities. The skill distinguishes between items that need replenishment and those that are stagnant, providing clear visibility into cash tied up in overstock or dead stock. It supports data ingestion from major platforms like Shopify, Square, and NetSuite, or via CSV, and ensures all purchase orders and vendor communications are reviewed and approved by the user before execution.
What it does
- Computes 7-day and 28-day sales velocity to identify trends.
- Projects conservative stockout dates based on current inventory and demand.
- Sizes 60-day reorder quantities while accounting for lead times and inbound stock.
- Flags overstock, dead stock, and zero-velocity items to improve cash flow.
- Drafts professional purchase orders and vendor emails for user approval.
- Applies seasonal adjustments only when sufficient historical data is available.
When to use it
- When you need to determine which items to reorder to prevent stockouts.
- When you want to identify stagnant inventory that is tying up cash.
- When preparing to place orders with suppliers and needing draft documentation.
- When you need a clear report on warehouse cash value and stock health.
Advantages
- Prevents lost sales by identifying items nearing stockout status.
- Reduces capital tied up in dead or slow-moving inventory.
- Ensures reorder quantities are based on actual sales data rather than guesswork.
- Provides transparency into the reasoning behind every reorder recommendation.
- Maintains control by requiring explicit approval for all financial commitments.
Usage examples
- “What do I need to reorder this month?”
- The agent analyzes your sales history and current stock to present a prioritized list of items to reorder, including quantities and estimated costs.
- “How much cash is sitting in the warehouse?”
- The agent identifies slow-moving and dead stock, calculating the total dollar value of items that are not currently generating sales.
- “Draft a PO for my supplier.”
- The agent generates a purchase order and a corresponding vendor email based on your current stock needs for your review and approval.
- “Am I going to run out of filters?”
- The agent checks the sales velocity and current stock of your filters to report if you are at risk of a stockout and if there is still time to reorder.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/anthropics/inventory-planner/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip inventory-planner.zip -d .agents/skills
Documentation by Anthropic
Inventory Planner
Buy what sells, before it runs out, and stop buying what doesn't.
Stock is cash the owner already spent. Two things go wrong: running out of the item customers came for, and sitting on a pallet of something nobody wants. Both are visible in the sales history well before they become a problem, which is what this skill reads for.
Step 1 — Get sales and stock
Preferred: Shopify for sales and inventory levels. Square and NetSuite work the same way.
Fallback, fully supported: a CSV of sales history plus a stock-on-hand count. Two files, or one with both. This path works with zero connectors and gives the same output. Many businesses count on a clipboard, and that is a legitimate input.
You need, per item: SKU, name, units sold by date, current stock on hand, unit cost, unit price, vendor, and lead time if known. Missing lead time is asked for once and remembered — see reference/data_sources.md.
Say what the count is as of. A stock figure two weeks old produces a stockout date two weeks wrong.
Step 2 — Compute velocity, both windows
For every item, compute:
7-day velocity — units per day over the last week. Catches what is happening now.
28-day velocity — units per day over four weeks. The stable baseline.
Both matter, and disagreement between them is information. An item selling three times its 28-day rate this week is either trending or had one bulk order, and those need different responses. reference/velocity_and_reorder.md covers how to tell them apart.
Exclude one-off distortions from the baseline where you can identify them: a single wholesale order, a returned batch, a stockout period where the item could not sell. A period of zero sales because there was no stock is not zero demand, and treating it as such is how an item gets under-ordered forever.
Step 3 — Project stockout dates, conservatively
Stockout date is stock on hand divided by the daily velocity you trust least — the higher of the two windows. Being early is cheap; being late loses the sale.
Then compare against lead time. The number that matters is not when it runs out, it is whether there is still time to order:
Past the point of no return — lead time exceeds days of cover. Already going to stock out. Say so plainly.
Order now — cover is within lead time plus a safety buffer.
Order soon — comfortable, but on the next cycle.
Fine — no action.
Never state a stockout date for an item with no reliable velocity. New items with two weeks of history and items whose sales were interrupted get flagged as "not enough history," by name.
Step 4 — Size the reorder
Default target is 60 days of cover plus the lead time, sized on the 28-day rate — not on the faster of the two. The stock has to last from the day it lands until the next order lands, so leaving the lead time out runs the item short by exactly that many days every cycle. Then adjust for pack size, minimum order quantity, and what is already on order.
The two rates do different jobs and both get named on the line: the higher one says when it runs out, the 28-day one says how much to buy. Sizing a 60-day order off a one-week spike is how cash ends up in a pallet.
Never size a reorder without subtracting inbound stock. Double-ordering a slow item is how a business ends up with three years of it.
Round to the vendor's pack size and say which direction you rounded. Show the dollar cost of every recommendation — the owner is deciding about cash, not units.
Step 5 — Handle the items that are not moving
Zero-velocity and very slow items are a separate list with a separate purpose. They are never reorder candidates.
Zero velocity — no units in 28 days. Report as a slow mover with the cash tied up in it. Never compute days of cover for these — nothing is selling, so nothing is running out, and the number is either an error or nonsense. The one exception is an item inside a season the owner has named, which goes on a dated watch list instead of the clear-out list.
Overstock — more than 120 days of cover. Report the excess units and the dollars.
Dead stock — no movement in 90 days. Suggest clearing, bundling, or discounting.
Total the cash sitting in these. That figure is usually the most surprising number in the whole report and often the most useful one.
Step 6 — Apply seasonality only where history supports it
With at least a year of history, compare the coming period against the same period last year and adjust.
With less than a year, say so and do not adjust. A seasonal multiplier invented from nine months of data is a guess wearing a suit. Ask the owner instead — they know their season better than a short history does. reference/seasonality.md covers both paths.
Step 7 — Present the buy list
Lead with the total dollar amount and the count of items about to stock out. Then: order now, order soon, slow movers, and anything with too little history to judge.
Every line carries the numbers behind it — velocity, days of cover, lead time, quantity, cost. An owner who can see the reasoning approves in a minute; one who cannot rebuilds the whole thing by hand.
Render the buy list as an HTML artifact using the house artifact style (../../shared/artifact-style.md): a stockout table sorted by stockout date with mono tabular-nums numerals, urgency status pills (order now / order soon / fine / past the point of no return), a reorder panel with quantities and dollar totals, and a slow-movers section with the cash tied up in it. The chat summary stays — the artifact is the full picture, not the only one.
Step 8 — Draft POs and vendor emails, with approval
Purchase orders commit money and vendor emails go out under the owner's name, so both wait for an explicit yes.
State the vendor, the line items, and the total before asking. Draft the vendor email in the owner's voice per the shared voice profile. If no profile exists yet, follow that file's "When there is no sample" instruction — ask for three emails they have already sent a supplier. If they would rather not, write the email plain and neutral and say it is not in their voice. Never invent a personality for someone's vendor relationship.
With Google Calendar connected, offer a recurring block for the restock decision — this works far better as a rhythm than as a fire drill. Keep the approved PO document here — this skill owns it. With QuickBooks or NetSuite connected, hand ap-processor the coded memo for each one (vendor, PO number, total, expected date, and the account, class, and job), so the bill three-way-matches against a real record when it arrives. ap-processor reads POs; it does not create them.
Closing offer
Close with one line on what was decided — the total buy and the items about to run out. Then offer the most relevant next step with its exact trigger phrase: "reorder" (/restock) when the owner wants the POs drafted and sent end to end. Up to two more from the router's table, such as "cash forecast" (cash-flow-snapshot) or "pay the bills" (/pay-the-bills). Three offers at most, and never repeat one the owner already declined this session.
What not to do
Do not invent a velocity, a lead time, or a stockout date. Too little history is reported by SKU, not smoothed over.
Do not treat an out-of-stock period as zero demand. It is suppressed demand and it biases everything downstream.
Do not recommend reordering a zero-velocity item. No sales means stop buying, not buy more.
Do not size a reorder without subtracting what is already inbound.
Do not apply seasonality without a year of history. Ask the owner instead.
Do not send a PO or a vendor email without approval. Both spend money or spend goodwill.
Do not report units without dollars. The owner thinks in cash.
Reference files
reference/data_sources.md— Shopify, Square, NetSuite, and the CSV path, with required fieldsreference/velocity_and_reorder.md— the 7/28-day math, distortion handling, and reorder sizingreference/seasonality.md— when to adjust, when to ask, and how to say which you didreference/po_drafting.md— purchase order structure and vendor email draftingreference/gotchas.md— the mistakes that stock out a bestseller or bury cash in a pallet
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.
Files
- ATTRIBUTION.mdAdded by AutoGineer915 B
- LICENSELicence file added by AutoGineer11.3 KiB
- SKILL.md9.7 KiB
- reference/data_sources.md4.3 KiB
- reference/gotchas.md4.4 KiB
- reference/po_drafting.md3.8 KiB
- reference/seasonality.md5.3 KiB
- reference/velocity_and_reorder.md8.4 KiB
reference/gotchas.md
Gotchas
The mistakes that stock out a bestseller or bury cash in a pallet. Inventory errors are slow and expensive — they show up as a missed sale or a shelf nobody touches for two years.
Gotcha: counting a stockout as zero demand
Why it matters: This is the most damaging error in the whole skill, and it is self-reinforcing. The item ran out because it sells. The zero-sales days drag the velocity down. The next order is smaller. It runs out sooner. Repeat.
Bad
Merv 11 filter: 12 units sold in 28 days = 0.43/day. Slow mover, no reorder.(the shelf was empty for 20 of those 28 days)
Good
Merv 11 filter: 12 units in the 8 days it was actually in stock = 1.5/day.
Out of stock 20 of the last 28 days — that is suppressed demand, not slow sales.
Planning on 1.5/day.Gotcha: ordering into a one-week spike
Why it matters: A single bulk order makes an ordinary item look like a runaway for exactly seven days. Sixty days of cover sized off that number is a pallet the owner paid for and will look at for a year.
Bad
7-day velocity 5.8/day vs 28-day 0.4/day. Size 60 days at 5.8/day.
Good
7-day rate is 14x the 28-day rate. Looking at the orders: one sale of 40 units
on the 9th. That is a job, not a trend. Sizing on the 28-day rate and noting
it in case that customer comes back.Gotcha: recommending a reorder for a zero-velocity item
Why it matters: Zero sales in 28 days means stop buying. A reorder point set years ago in the ERP will happily say otherwise, and following it converts working capital into shelf decoration.
Bad
NetSuite reorder point says 24, on hand is 6, so order 18.
Good
Zero units sold in 28 days. The stored reorder point says 24 — that is stale.
Not a reorder. Six units, USD 340 tied up. Worth clearing.Gotcha: forgetting what is already on order
Why it matters: Two orders for the same item three weeks apart is the classic double-buy, and it usually happens right after a stockout scare when the owner is paying attention.
Bad
On hand 38, target 258, order 240.
Good
On hand 38, 160 already inbound from the 3/2 order, target 258 total.
That leaves 60 — 2 cases of 40, so 80 units. If that inbound number is
wrong tell me, it changes this.Gotcha: a stock count with no as-of date
Why it matters: Everything downstream is stock divided by velocity. A two-week-old count on a fast mover produces a stockout date that has already passed.
Bad
Take the uploaded count at face value and project from today.
Good
Ask when it was counted. If the count is from the 1st and today is the 15th, either net out two weeks of sales or ask for a fresh count on the fast movers, and say which you did.
Gotcha: seasonality invented from partial history
Why it matters: A multiplier computed from nine months looks exactly like one computed from three years. It gets used to buy real stock, and nobody can tell later which kind it was.
Bad
June factor: 1.6x (computed)(from 120 days of data that do not include a June)
Good
120 days of history — no June in there, so I cannot compute a season.
You know this better than the data does. Roughly how much heavier is June?Gotcha: velocity at the product level instead of the variant
Why it matters: A product that sells well in one size and never in another looks healthy in aggregate. The good size stocks out while the bad size accumulates, and the product-level number shows neither.
Bad
Filter, 20x25: 4.1/day, 38 on hand, healthy.
Good
Split by variant. The 1-inch is running out in four days; the 4-inch has nine months of cover. Two different problems, one product line.
Gotcha: reporting units without dollars
Why it matters: Owners decide about cash. "Order 240 filters" is not a decision they can make; "USD 888" is.
Bad
A buy list of quantities with no cost column.
Good
Every line costed, every vendor subtotaled, and the total stated before the approval question.
Gotcha: quietly accepting a vendor substitution
Why it matters: A different part number goes onto a customer's equipment. That is the owner's call and sometimes a warranty question, never a shipping detail.
Bad
Vendor swaps a compatible capacitor, order updated, nothing said.
Good
Report the substitution, the part numbers both ways, and the effect on cover if the owner rejects it. Then let them decide.
Requirements and compatibility
Written for: Claude Code, Claude apps
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Declares allowed tools
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- Anthropic
- Publisher
- Anthropic (Official)
- Source
- anthropics/knowledge-work-plugins · small-business/skills/inventory-planner · commit e050c2e
- Licence
- Apache License 2.0 (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Anthropic.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download inventory-planner.zip