Install
openclaw skills install @lsypro/convbox-ecommerce-skillsConvbox Ecommerce Skills provides self-service analysis built on Convbox first-party attribution data, delivering diagnostics and reports for DTC storefronts across growth, paid media, creative, conversion, retention, attribution, profit, and related themes.
openclaw skills install @lsypro/convbox-ecommerce-skillsBefore doing any analysis, run this lightweight greeting once at the start of each session. It has two jobs:
Load memory → summarize as session context. Check for the store-profile memory (memory.md). If it exists, read it and briefly summarize it back to the user as the working context: business background (store URL, primary category, main objective), benchmarks (gross margin, target / breakeven ROAS, budget cap), and preferences (attribution model, report language, work role). Keep this to a few lines. If no memory exists, treat it as first-time setup and go to step 2.
Confirm default configuration. Ask the user to confirm the two defaults that drive everything downstream, showing what is currently on file (or "not set" for a first session):
Ask "Is this still correct?" If anything is wrong or missing, guide the user to fill in / correct it, then write the updated profile back to memory for reuse (see Section 2 for the field list and write rules).
Constraints: keep it brief — don't interrogate; group into at most a couple of questions; never request or echo the API Key. When memory is already complete and the user goes straight to a request, a one-line acknowledgement (e.g. "Using your saved profile: , ") is enough instead of a full re-confirmation, and you may proceed directly.
functions.md scenario matrix.Information needed (gather any missing pieces first):
First click), report language, report time window, and the requester's role (used to trim emphasis per the functions.md role focus).Reporting role (defaults to General):
functions.md scenario matrix.User input and credentials:
CONVBOX_API_KEY is already configured by the user in the environment (business prerequisite: the user has registered and configured Convbox and has generated a Key). Never request or echo this Key in conversation.Read memory: yes.
Dependencies:
functions.md — Data interface definitions + the analysis scenario matrix (atomic scenario × role × tier permission × development status) + the report assembly conventions (cadence / role trimming / tone / unified report template). It is the authoritative source for routing, permissions, and report assembly.access.yaml — Field definitions and samples for the 9 Convbox APIs (the data access dictionary).plans/{plan}.md — The analysis core blueprint for each atomic scenario (contains only data retrieval and "data → analysis → comparison → conclusion → next step" reasoning; report cadence / role trimming / tone / template live in functions.md, not here).utilities/ — On-demand toolset. Already developed:
utilities/config-health-check/ — Configuration and API health self-check (verifies CONVBOX_API_KEY and access.yaml readiness, probes all endpoints, and validates response schemas against their definitions; targets credentials and connectivity, distinct from store business health analysis).Can do:
utilities/ to synthesize on-demand artifacts (web pages / charts, etc.).Cannot do:
records may mean the tier is not open — see functions.md).functions.md role focus list. General presents all results with no trimming.Default routing: unless this SKILL.md describes it directly, always go to plans/ for the matching {plan}.md and execute it. Routing steps:
functions.md analysis scenario matrix.Tier — if it requires a higher tier than the current account holds, the relevant interfaces will return empty data; tell the user the required tier and do not force the analysis.code != 1 / you suspect a Key or connection issue, first call utilities/config-health-check/ to self-check and determine whether it's a configuration problem or a data problem before deciding whether to continue; Data Quality & Tracking Governance requests also use this as their connectivity / configuration checkpoint.plans/{scenario}.md and execute its analysis core per "data context preparation → data → analysis → comparison → conclusion → next step," producing that scenario's metric block / diagnostic block / recommendations.functions.md and assemble requests per access.yaml; follow the definition discipline (don't mix true roas with platform ad_roas, pass dimensions as a single-value string, compare within the same model, pair detail with summary, profit depends on cost configuration, margin/cvr are decimals).utilities/ when on-demand artifacts (web pages / charts, etc.) are needed.functions.md (cadence chooses the window / comparison period, trim by role, tone, unified template), filling in the metrics / diagnostics / recommendations produced by the plan; chain-trigger follow-up scenarios for cross-scenario issues per the blueprint.
Plans used: growth-health-diagnosis, roas-decline-diagnosis. This applies to both single-scenario reports and aggregated (daily / weekly / monthly / suite) reports.All channel / campaign / creative judgments share this four-quadrant framework (thresholds can be overridden by store benchmarks):
| Quadrant | Platform ROAS | True ROAS | Diagnosis | Action |
|---|---|---|---|---|
| Underrated gem | Low | High | Upper-funnel value underrated by the platform | Don't pause; consider scaling |
| False prosperity | High | Low | Platform over-attribution (brand / retargeting) | Cap budget; check incrementality |
| True winner | High | High | Genuinely efficient | Scale, +20% every 3–5 days |
| True loser | Low | Low | Inefficient spend | Pause or cut, refresh creative / audience |
For key metric definitions, the available interfaces per atomic scenario, and role permissions, functions.md is authoritative.