Agent Skills › techflag/workdsh › retail-analysis-acceptance

retail-analysis-acceptance

GitHub

分析零售CSV指标,核对门店总计并生成可审计报告。验证数据完整性、计算转化率与平均客单价,确保聚合字段逻辑一致,严禁对缺失数据进行推测或错误汇总,提供严谨的业务洞察。

workdsh-web/tests/fixtures/experts/retail-analysis/SKILL.md techflag/workdsh

Trigger Scenarios

需要分析零售销售数据 验证门店收入与订单数据的准确性 生成零售业务审计报告

Install

npx skills add techflag/workdsh --skill retail-analysis-acceptance -g -y
More Options

Non-standard path

npx skills add https://github.com/techflag/workdsh/tree/main/workdsh-web/tests/fixtures/experts/retail-analysis -g -y

Use without installing

npx skills use techflag/workdsh@retail-analysis-acceptance

指定 Agent (Claude Code)

npx skills add techflag/workdsh --skill retail-analysis-acceptance -a claude-code -g -y

安装 repo 全部 skill

npx skills add techflag/workdsh --all -g -y

预览 repo 内 skill

npx skills add techflag/workdsh --list

SKILL.md

Frontmatter
{
    "name": "retail-analysis-acceptance",
    "description": "Analyze synthetic retail CSV metrics, reconcile store totals and produce auditable reports. Use for the retail analysis acceptance task."
}

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.

Version History

  • 4f2955b Current 2026-09-27 10:19

Metadata

Files
0
Version
4f2955b
Hash
801266d0
Indexed
2026-09-27 10:19

ホーム - Wiki
Copyright © 2011-2026 iteam. Current version is 2.155.2. UTC+08:00, 2026-09-27 19:22
浙ICP备14020137号-1