Build a shipping rate calculator around the rules your store actually uses. Give your assistant parcel dimensions, weight, destinations, rates and free-shipping conditions; this Skill guides the implementation and tests so operators can check billable weight and checkout charges before a developer connects live carrier pricing.
Shipping Rate Calculator is implementation guidance rather than a finished calculator app. It includes shipping configuration concepts, a TypeScript EasyPost example and evaluation tasks that an assistant can use to build code for your units and destination rules.
Use it to translate merchant policy into executable calculations and boundary checks. The worked example calculates parcel weights and tests US and Canada checkout charges from supplied store tariffs. Those tariffs are customer-facing rules, not live carrier quotes; a carrier account and integration are needed for current service prices.
Shipping Rate Calculator suits a store building custom checkout or shipping logic with a developer. It helps turn packaging, destination and free-shipping rules into code and repeatable tests. If standard flat-rate settings already cover your store, configure those settings first instead of maintaining a separate calculator.
Supply dimensions, weight units, the dimensional divisor and rounding rules so the generated utility can compare actual and dimensional weight. This is especially useful for bulky, light products where the scale weight alone does not explain the charging basis.
Test amounts just below and exactly at the free-shipping threshold, including the effect of discounts and destination exclusions. The example verifies those boundaries separately from parcel calculations, making the store's commercial rules easier to inspect.
Use the carrier integration guidance when the task requires current quotes rather than a merchant-defined tariff. Live pricing needs service credentials and implementation work; label purchasing and order synchronization are additional workflows, not automatic results of calculating a rate.
Prepare the following business inputs and software before starting the workflow.
Prepare package dimensions, units, scale weight and the carrier’s applicable DIM and rounding rules.
Prepare a developer-capable agent and a test project, separate from live checkout.
For rate integrations, prepare a provider account, sandbox credentials and current platform eligibility.
Install the complete Skill package, then start with the merchant inputs listed above.
Copy this request into Codex or Claude Code. The assistant downloads the original repository at the specified commit, installs the complete files and checks required dependencies.
Install shipping-rate-calculator in the app I am using and carry out the file installation, not just explain it.
Original repository: https://github.com/finsilabs/awesome-ecommerce-skills.git
Commit: fa38550a7fa27626246146dd856a5c4775fb3254
Skill folder: skills/fulfillment-shipping/shipping-rate-calculator
1. Download this exact source into a new directory. Read SKILL.md and its setup references before running any bundled scripts. Do not substitute another author’s package.
2. For Codex, use ~/.agents/skills/shipping-rate-calculator; for Claude Code, use ~/.claude/skills/shipping-rate-calculator. Install only for my current app. Install the complete Skill folder, including scripts, references, assets and bundled notices. Keep any root license with the installed folder. Check all destination folders first; if any already exist, report differences before replacing them.
3. Compare the source and installed file lists and hashes. Inspect documented runtimes, dependencies and required connections. Configure only the local dependencies needed for this Skill; use an isolated environment when appropriate. Ask me to complete any account login locally, without putting credentials in chat.
4. Report the source commit, actual installation path, file-check results and any remaining runtime setup. Explain how to invoke shipping-rate-calculator in this app. Check discovery separately from file copying; start a new session if needed. Do not run production tasks or claim a successful business outcome from installation alone.Starter prompts for the main use cases—copy and use them directly.
Implement billable-weight calculation to produce a tested utility selecting the applicable greater weight. Dimensions, unit, scale weight, DIM factor and rounding rule.
Use shipping-rate-calculator with [INPUT] to implement a local billable-weight utility. Make the carrier factor explicit, normalize units, reject non-positive dimensions and test both actual-weight and DIM-weight dominance. Do not treat 139 as universal.[INPUT]Prepare a rate-shopping integration to produce an integration plan with authentication, timeout and failure cases. Test addresses, parcel data and a chosen provider’s current API docs.
Review the EasyPost example against [INPUT]. Identify required SDK changes, address fields, units and error handling. Produce a sandbox-only implementation plan; do not create live shipments or buy labels.[INPUT]Check checkout shipping rules to produce test cases for thresholds, empty results and fallback behavior. Rate fixtures, free-shipping threshold and supported destinations.
Use [INPUT] to test shipping options around the free-shipping threshold, an unsupported destination and an API timeout. Keep estimated delivery times distinct from guarantees and identify any missing fallback implementation.[INPUT]The sample store charges $5.95 for US orders below $75 and $18 for Canada. Test parcels include 20 × 16 × 12 inches at 5 lb, and 50 × 40 × 30 cm at 2,000 g.
Case input files: business-inputs.zip
Use the shipping-rate-calculator Skill.
Our packing team needs to understand why large lightweight parcels cost more and our checkout team needs clear shipping rules. Calculate dimensional and billable weight for 20×16×12 inches at 5 lb, 6×6×6 inches at 160 oz, and 50×40×30 cm at 2000 g. Use our planning factors of 139 in³/lb and 5000 cm³/kg and round billable pounds up. Apply the supplied US and Canada store tariffs to the three basket examples, and produce a calculator plus a table the team can check. These are our planning assumptions, not live carrier quotes.
The attached business materials are:
- inputs/baskets.csv
- inputs/merchant.json
- inputs/parcels.csv
Deliver a complete result.md report that the operations team can read, plus any finished files needed for this task. Keep supporting calculations and evidence with the deliverables. Write the report in English; use the requested target language for customer-facing copy. The business datasets are fictional examples unless the brief explicitly names a live public website.The primary file produced by this prompt is shown below in its original language.
The large lightweight box has a planning billable weight of 28 lb even though it weighs 5 lb. Package volume drives this example. These calculations apply the supplied planning divisors; they are not carrier quotes.
| Parcel | Actual pounds | Dimensional pounds | Rounded billable pounds |
|---|---|---|---|
| 20 × 16 × 12 in; 5 lb | 5.0000 | 27.6259 | 28 |
| 6 × 6 × 6 in; 160 oz | 10.0000 | 1.5540 | 10 |
| 50 × 40 × 30 cm; 2000 g | 4.4092 | 26.4555 | 27 |
Imperial dimensional pounds = length × width × height ÷ 139. Metric dimensional kilograms = length × width × height ÷ 5000, then convert kilograms to pounds. Billable pounds = ceiling of the larger actual or dimensional weight. The small box weighs 160 oz ÷ 16 = 10 lb, so actual weight controls that example.
| Destination | Discounted merchandise | Shipping | Merchandise + shipping | Service |
|---|---|---|---|---|
| contiguous US | $74.99 | $5.95 | $80.94 | USPS Ground Advantage |
| contiguous US | $75.00 | $0.00 | $75.00 | USPS Ground Advantage |
| Canada | $100.00 | $18.00 | $118.00 | UPS Standard |
The free-shipping threshold applies only to contiguous-US discounted merchandise totals of at least $75. Canada remains $18 even when the merchandise subtotal is $100. Sales tax, if applicable, is a separate checkout calculation. Do not apply the US threshold to Canada.
Keep shipping-calculator.mjs and shipping-config.json together. Import billableWeight(parcel) for packing estimates and shippingCharge(destination, discountedSubtotal) for checkout rules. Amounts are processed as integer cents to avoid threshold rounding mistakes. Unsupported destinations return unavailable rather than a misleading zero price. Invalid or nonpositive measurements are rejected.
The downloadable package includes the calculator, merchant configuration, machine-readable calculations and seven executable checks. Run node --test shipping-calculator.test.mjs to verify all three parcel examples, both US boundary values, Canada eligibility, unsupported destinations and invalid inputs. All seven checks passed during this execution.
Measure the packed outer dimensions before comparing cartons. For the 20 × 16 × 12 inch box, reducing empty space could change the weight basis, but the team should request an actual carrier quote before choosing a service. The store tariff is a customer-facing commercial rule and does not represent the carrier charge or prove fulfillment profitability.
Merchant business data is synthetic. Website observations, when present, come from the public URLs listed in the report.
Review these limits before using generated files or estimates in your store.
The package contains guidance and evaluation cases, not a ready-made calculator application.
Carrier DIM factors, rounding and rates vary; provide the rules applicable to your contract.
Live carrier APIs and labels were outside this local test.
Resolve the calculation choices behind dimensional weight, free-shipping thresholds, carrier quotes and checkout failures.
A light but bulky parcel can have a higher billable weight than its scale weight. The dimensional calculation uses the packed box's length, width and height with a carrier-specific divisor; the applicable service determines the comparison and rounding rules. FedEx's current US guidance explains this distinction, but do not reuse one divisor for every carrier and unit system.
In our simulated test, a 20×16×12-inch parcel weighing 5 lb used a divisor of 139 and rounded to 28 billable pounds. Supply packed dimensions, units and the intended service when asking the Skill to implement the rule. A calculated weight still needs a rate table or carrier quote to become a price.
Not from the local example alone. The Skill helped generate working calculation code, but the tested carrier responses came from a mock adapter. To obtain live rates, a developer must connect an authenticated carrier or shipping-platform API, pass the actual origin, destination and parcel details, and handle the returned currency and service information.
EasyPost distinguishes purchasable, list and retail rate fields, so choose the value your checkout should show rather than copying the first number. Confirm the connected carrier accounts and test versus production mode. Retrieving a rate and buying a shipping label are separate actions; this example did not purchase labels or test a live account.
Implement the rule your checkout and published policy actually use. Our fixture explicitly uses discounted merchandise subtotal: a US cart at $74.99 pays $5.95, while $75 qualifies for free shipping. Tax, shipping and destination eligibility must be defined separately rather than hidden inside a generic “order total” variable.
Shopify's free-shipping discount documentation counts products at their discounted price for combinable discounts. If you are building a custom calculator, test the exact threshold, a cart reduced below it by a coupon and a destination excluded from the offer. Preserve amounts in consistent currency units and check the displayed result against a real checkout before enabling the rule.
A checkout rule may charge a fixed customer-facing amount while the carrier bills the shipment's actual service, measured parcel and applicable surcharges. Those are different numbers with different purposes. Compare the same carrier, service, currency, account and parcel data before treating a difference as a calculation error.
Keep the quote response alongside the package measurements and inspect any listed surcharges, insurance or international cost fields. The Skill can help you build that comparison, but our local tests cover rule logic and simulated failure states, not invoice reconciliation. If a carrier corrects the dimensions after collection, update the packaging data that caused the mismatch instead of merely adjusting the formula.
It can help a developer implement selection rules, but “cheapest” needs an eligibility filter first. Exclude services that cannot deliver to the address, handle the package or meet the customer's selected option, then compare the available quotes. Keep unknown delivery estimates visible rather than treating a missing estimate as fast delivery.
Ask the assistant to return the chosen service plus the alternatives and the reason for each exclusion. Decide whether the store prioritizes cost, delivery speed or a customer-paid upgrade. The local case verified calculation behavior with fixtures; it did not prove that a multi-carrier live integration consistently picks the lowest final billed cost.
Return a distinct state for an unsupported destination, invalid parcel data, an empty rate response and a temporary timeout. Do not turn every failure into zero shipping: that could offer an unintended free delivery promise. The example specifically tests unavailable destinations, missing rates and timeouts.
Agree on a fallback before deployment. That may be a confirmed flat rate for a covered region, a retry with a clear message, or asking the customer to contact the store for a quote. Log enough non-sensitive context to reproduce the issue, then test the visible checkout message and recovery path. Any fallback price must come from a business rule the merchant has actually approved.
No reviews yet.