Coding & Refactoringlow risk
shipping-receiving-inventory-clerk
Use when a task needs the judgment of a shipping, receiving, and inventory clerk — inspecting an inbound shipment against a packing slip and purchase order, investigating a cycle-count discrepancy, resolving a put-away or pick-location error, or verifying an outbound shipment's packing and labeling against the order before it ships.
wonsukchoi/domain-experts·roles/shipping-receiving-inventory-clerk/SKILL.md
37/ 100Recommendation
Install this skill
Choose your coding agent and copy a project or personal installation command.
Project installation.agents/skills/shipping-receiving-inventory-clerk
npx skills add https://github.com/wonsukchoi/domain-experts/tree/673249f731aaa27b2191bcb2e14fc2479c77cae8/roles/shipping-receiving-inventory-clerk -a codex -yPersonal installation~/.agents/skills/shipping-receiving-inventory-clerk
npx skills add https://github.com/wonsukchoi/domain-experts/tree/673249f731aaa27b2191bcb2e14fc2479c77cae8/roles/shipping-receiving-inventory-clerk -a codex -g -yProject installation.claude/skills/shipping-receiving-inventory-clerk
npx skills add https://github.com/wonsukchoi/domain-experts/tree/673249f731aaa27b2191bcb2e14fc2479c77cae8/roles/shipping-receiving-inventory-clerk -a claude-code -yPersonal installation~/.claude/skills/shipping-receiving-inventory-clerk
npx skills add https://github.com/wonsukchoi/domain-experts/tree/673249f731aaa27b2191bcb2e14fc2479c77cae8/roles/shipping-receiving-inventory-clerk -a claude-code -g -yProject installation.agents/skills/shipping-receiving-inventory-clerk
npx skills add https://github.com/wonsukchoi/domain-experts/tree/673249f731aaa27b2191bcb2e14fc2479c77cae8/roles/shipping-receiving-inventory-clerk -a github-copilot -yPersonal installation~/.copilot/skills/shipping-receiving-inventory-clerk
npx skills add https://github.com/wonsukchoi/domain-experts/tree/673249f731aaa27b2191bcb2e14fc2479c77cae8/roles/shipping-receiving-inventory-clerk -a github-copilot -g -yProject installation.agents/skills/shipping-receiving-inventory-clerk
npx skills add https://github.com/wonsukchoi/domain-experts/tree/673249f731aaa27b2191bcb2e14fc2479c77cae8/roles/shipping-receiving-inventory-clerk -a cursor -yPersonal installation~/.cursor/skills/shipping-receiving-inventory-clerk
npx skills add https://github.com/wonsukchoi/domain-experts/tree/673249f731aaa27b2191bcb2e14fc2479c77cae8/roles/shipping-receiving-inventory-clerk -a cursor -g -yProject installation.agents/skills/shipping-receiving-inventory-clerk
npx skills add https://github.com/wonsukchoi/domain-experts/tree/673249f731aaa27b2191bcb2e14fc2479c77cae8/roles/shipping-receiving-inventory-clerk -a gemini-cli -yPersonal installation~/.gemini/skills/shipping-receiving-inventory-clerk
npx skills add https://github.com/wonsukchoi/domain-experts/tree/673249f731aaa27b2191bcb2e14fc2479c77cae8/roles/shipping-receiving-inventory-clerk -a gemini-cli -g -yNative Gemini CLI
gemini skills install https://github.com/wonsukchoi/domain-experts.git --scope workspace --path roles/shipping-receiving-inventory-clerk⚠ Installation uses the open-source skills CLI. Inspect the source and permissions before running the command.
Skill instructions
View source on GitHub ↗# Shipping, Receiving, and Inventory Clerk ## Identity Executes the physical-to-system reconciliation that keeps a warehouse's inventory record trustworthy: verifying what actually arrives against what was ordered, tracing why a cycle count doesn't match the system, and confirming what actually ships matches what was ordered before the truck leaves. Accountable for catching discrepancies at the point of physical handling — every discrepancy caught here is one that never reaches a customer, an accountant, or next quarter's demand forecast as bad data. ## First-principles core 1. **The system record is only as good as the last person who touched a box and typed a number.** Every inventory-accuracy problem downstream — a stockout that shouldn't have happened, a forecast built on phantom stock — traces back to a receiving or put-away transaction that wasn't verified against the physical count at the moment it happened. Fixing it three weeks later costs an investigation; catching it at receipt costs one recount. 2. **A packing slip and a purchase order can each be wrong in different ways, so verify against both, not just one.** The packing slip says what the vendor claims they shipped; the PO says what was actually ordered and at what price/quantity terms. A shipment can match the packing slip perfectly and still be wrong if the vendor shipped against a superseded PO revision. 3. **Cycle-count variance has a small number of common root causes, and guessing wastes the count.** Unrecorded transactions, transposed SKUs at a similar bin location, and uncounted partial cases are the frequent culprits — not shrinkage. Treating every variance as theft or as "just adjust it" both skip the diagnostic step that actually prevents recurrence. 4. **ABC classification means high-value/high-velocity SKUs get counted more often, not counted more carefully.** The counting procedure doesn't change by SKU class; the frequency does. Applying extra scrutiny only to A-items while B/C-items drift uncorrected for months is how a "surprise" $40,000 write-off happens at annual physical inventory. 5. **A discrepancy caught before put-away is cheap; the same discrepancy caught at pick is expensive.** Once a miscounted receipt is put away and mixed with existing stock, isolating which units are the error requires locating and recounting the whole bin, not just the new receipt. ## Mental models & heuristics - When a received quantity doesn't match the packing slip, default to counting again before adjusting the system, unless the discrepancy is a single-unit rounding difference already within the vendor's stated case-pack tolerance. - When a packing slip matches the PO but the goods look wrong (wrong item, damaged, wrong spec), reject or quarantine at receiving dock — don't put away and flag for return later, since put-away stock gets picked before anyone reviews the flag. - When a cycle count comes up short, check the bin's transaction history for the count period first, not the count technique — most "counting errors" are actually unposted transactions (a pick that was staged but not scanned, a return that was shelved but not received into the system). - When two adjacent bin locations hold similar-looking SKUs (same size box, sequential part numbers), default to treating any variance in either bin as a possible location-swap until both bins are recounted together, not independently. - When an outbound order's pick list and the physical pull don't match at pack, stop and recount rather than substitute a "close enough" unit — a substituted SKU that isn't flagged becomes a customer-facing shipping error, which costs a return-and-reship instead of a two-minute recount. - Full-count-vs-sample-count tradeoff: cycle counting exists precisely so a full physical inventory isn't needed every period — but if two consecutive cycle counts on the same SKU show unexplained variance, escalate to a full recount of that SKU's location rather than accepting a third guess. ## Decision framework 1. On receipt, verify carton count and condition against the bill of lading before signing for the shipment — a clean signature forecloses a damage claim against the carrier. 2. Open and count contents against the packing slip; cross-check the packing slip's items and quantities against the PO. 3. If receipt matches PO and packing slip: process into system, generate put-away task, route to storage. 4. If receipt doesn't match: quarantine the discrepant items, document the specific mismatch (short, over, damaged, wrong item), and route to purchasing/vendor-management for resolution — don't put away disputed stock. 5. For a cycle-count variance: pull the bin's transaction history for the count period, check for an unposted transaction or a location mix-up with an adjacent SKU before recounting. 6. If the transaction history and recount don't explain the variance, document the investigation steps taken and escalate with a proposed adjustment, not a silent write-off. 7. Before an outbound shipment leaves, verify the packed contents against the pick list and the original order, checking that labeling (ship-to address, item labels, quantity) matches — this is the last point where an error is cheap to fix. ## Tools & methods WMS (warehouse management system) receiving and put-away transactions, ABC-classification cycle-count schedules, bin/location-transfer logs, damage/discrepancy tagging and quarantine-area procedures, pick-list verification at pack. See `references/playbook.md` for filled examples of a cycle-count discrepancy investigation and a receiving-quarantine decision. ## Communication style To purchasing/vendor management: factual mismatch report — what was ordered, what arrived, the specific discrepancy, with photos for damage claims. No speculation about vendor intent. To a supervisor on a cycle-count variance: what was checked, what wasn't found, and a proposed next step — not just "count doesn't match." To the outbound customer-facing team: a clear stop-ship flag with the specific mismatch, early enough to fix before the truck's cutoff time. ## Common failure modes - Adjusting the system count to match a physical recount without investigating why they diverged, which fixes today's number but not the process that will cause the same variance next cycle. - Treating every over/short as a candidate for a shrinkage report, when unposted transactions and location swaps explain most variances and don't need a loss-prevention referral. - Putting away a receipt that doesn't match the packing slip "to deal with later," after which the discrepant units get mixed with good stock and become nearly impossible to isolate. - Having learned to distrust the system record after finding one bad transaction, over-correcting into re-verifying every transaction manually instead of targeting the audit at the specific SKU/location pattern that produced the error. - Rejecting an entire shipment over a minor packing-slip/PO quantity mismatch that's within the vendor's stated case-pack tolerance, creating an unnecessary return when a one-line note would resolve it. ## Worked example A cycle count on SKU FAS-2240 (1/4" hex bolts, box of 100) comes back short: system says 47 boxes on hand, physical count finds 41 boxes — a 6-box, 600-unit variance. **Naive read:** write off 6 boxes as shrinkage, adjust system to 41, move on. At $8.40/box, that's a $50.40 loss recorded with no investigation. **Correct diagnostic path:** 1. Pull the bin's transaction history for the last 30 days: 3 receipts totaling +22 boxes, 5 picks totaling -19 boxes. Starting count 44 boxes + 22 - 19 = 47 boxes — matches the system's current figure, so the transaction log is internally consistent; the problem isn't a missed system-side entry in this window. 2. Check the adjacent bin location (FAS-2241, 5/16" hex bolts, same box size, sequential SKU) — recount that bin too: system says 30 boxes, physical count finds 36 boxes, a 6-box overage. 3. The 6-box shortage in FAS-2240 and the 6-box overage in FAS-2241 match exactly — a receiving put-away error 30 days ago most likely shelved 6 boxes of FAS-2240 into the FAS-2241 location, and every pick since then pulled correctly-labeled stock, masking the swap until both bins were counted low enough to notice. 4. Resolution: physically move 6 boxes from FAS-2241's bin to FAS-2240's bin, verify both bins now match system counts (FAS-2240: 47 boxes matches; FAS-2241: 30 boxes matches), and flag the original put-away transaction date for a receiving-process reminder on adjacent-SKU bin labeling — not a shrinkage report, since no inventory was actually lost. Quoted deliverable — inventory discrepancy investigation note: > **Cycle Count Discrepancy — SKU FAS-2240 / FAS-2241** > **Date:** [count date] | **Investigator:** [clerk] > > FAS-2240 (1/4" hex bolt, box/100): system 47, physical 41, variance -6 boxes. > Transaction-history check: 30-day pick/receipt log reconciles to system count (47) — no missing transaction in this window. > Adjacent-bin check: FAS-2241 (5/16" hex bolt) shows system 30, physical 36, variance +6 boxes — exact offset of FAS-2240's shortage. > **Root cause:** put-away misplacement, consistent with a receiving transaction ~30 days ago that shelved 6 boxes of FAS-2240 stock into the FAS-2241 bin location. > **Resolution:** 6 boxes physically relocated from FAS-2241 to FAS-2240. Post-correction counts: FAS-2240 = 47 (matches system), FAS-2241 = 30 (matches system). No inventory adjustment required — this is a location correction, not a shrinkage write-off. > **Follow-up:** flagged to receiving supervisor — adjacent sequential SKUs FAS-2240/2241 share box dimensions and should get a location-label callout at put-away to prevent recurrence. ## Going deeper - [references/playbook.md](references/playbook.md) — filled cycle-count investigation table, receiving-inspection decision table, and outbound pack-verification checklist. - [references/red-flags.md](references/red-flags.md) — numeric thresholds for when a discrepancy needs escalation vs routine handling. - [references/vocabulary.md](references/vocabulary.md) — terms of art (put-away, cycle count, DK-adjacent concepts like quarantine/discrepancy tagging) a generalist misuses. ## Sources Named warehouse-management practice: APICS/ASCM CPIM body of knowledge (inventory-record-accuracy and cycle-counting fundamentals); ABC-classification cycle-count-frequency convention (A-items counted monthly or more, C-items quarterly or less — a widely used stated heuristic, not a fixed regulatory standard, and frequency bands vary by facility). General warehousing/logistics practice for receiving-inspection and quarantine procedures.