# Retail Analysis Acceptance

> Analyze synthetic retail CSV metrics, reconcile store totals and produce auditable reports. Use for the retail analysis acceptance task.

- Skill: `techflag/retail-analysis-acceptance` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add techflag/retail-analysis-acceptance`
- Raw SKILL.md: https://api.skillmd.com/api/skills/techflag/retail-analysis-acceptance/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Data & Analytics
- Author: techflag (https://skillmd.com/u/techflag)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/techflag/retail-analysis-acceptance

---

# Retail analysis method
Read the CSV with file tools, then calculate with Python or another available local runtime. Never estimate totals mentally. No package installation or network access is necessary.
Check duplicate store/month keys, nulls, numeric types, currency and revenue = orders × average_order_value. Do not change the input. For unit changes explain normalization; do not silently impute missing data.
Compare requested months. Reconcile store revenue changes to total change. Conversion = orders / visitors; average order value = revenue / orders. Percentage change is (target/base - 1) × 100; distinguish relative percent from percentage points.
Average order value is revenue per order, not an SKU unit price. Stable store-level average order value establishes neither unchanged individual product prices nor unchanged within-store product/order mix; describe aggregate changes as order mix effects without claiming item-level price facts. Unknown requested JSON fields must be null with an explanation in inputIssues, never invented.
Arithmetic consistency alone cannot determine a currency unit: interpreting both revenue and AOV in the same alternative unit still preserves revenue = orders × AOV. Prefer the labeled unit while recording any required business confirmation; never reject a counterfactual by claiming a mathematically valid identity fails. An unchanged observed subset does not establish an unchanged total when another store has missing data.
Completeness is required for aggregate visitor fields: if any included store lacks visitors, baseVisitors or targetVisitors for that month MUST be null, not the sum of the observed stores. Keep observed-subset visitor sums only in a clearly labeled report subsection; never divide all-store orders by subset visitors or present that ratio as a conversion metric, even with an "incomparable" footnote. With B missing, write "A+C observed conversion is unchanged; B and overall conversion changes remain unknown." Do not write "no store improved", "the entire increase is an artifact", or "no real improvement": these claims exclude possibilities in the unobserved store. Recommendations must withhold judgment pending data rather than assert the missing store's performance.
Final delivery review: compare every aggregate field's coverage against the stores list; search the executive summary, tables and recommendations for assertions about unknown totals. A null JSON value must stay unknown in prose. Label revenue calculations as conditional on the supplied currency unit when business confirmation is pending, including in the headline; arithmetic reconciliation does not independently confirm that unit.
Evaluate completeness separately for each month: a missing target-month visitor count does not erase a fully observed base-month total (baseVisitors remains 2500 in this fixture; targetVisitors is null). Base conversion can be reported as 350/2500=14%; target and the change remain unknown. "No comparable change" is not "both levels unknown".
For unit sensitivity, describe the alternative precisely as "counterfactual: the fen label is wrong and the raw C-store amounts mean CNY", never as "following the fen label without normalization". Recalculate all store contributions under that counterfactual: C changes from 15000 to 1500000 (+1485000), total target revenue=1531000, total change=1476000; C is not unchanged, and the total direction reverses. Distinguish unit conversion under a supplied label from an unsupported assumption about a mistaken label.
A metric decomposition is evidence about the arithmetic drivers; it does not prove operational causes. Separate supplied facts, plausible hypotheses, needed evidence and follow-up actions.
Produce analysis-results.json with baseMonth, targetMonth, baseRevenue, targetRevenue, change, changePercent, baseVisitors, targetVisitors, baseOrders, targetOrders, stores (array of {storeId, baseRevenue, targetRevenue, change}), inputIssues (array). All amounts use CNY, percentages use percent units (not ratios).
Produce analysis-report.md with verified metrics, store decomposition, method, limitations and practical next actions. Before delivery check every copied formula against the actual row, and reconcile all prose/table values with the computed JSON. A higher aggregate average order value must first be decomposed by store order weights; do not recommend protecting it as an improvement without evidence of actual within-store improvement. For insufficient data explain missing fields and ask necessary questions; do not invent a breakdown.