Update to Seal Copilot

{
  "description": "One-time discovery run that maps which custom properties this customer tracks and ranks them by analytical signal (cardinality, revenue concentration, channel variance). Output is a personalized list of the 3 highest-value analyses available for this account. Trigger on: \"onboarding\", \"first time\", \"what can you analyze\", \"explore my data\", \"what properties do I have\", \"qué propiedades tengo\", \"what data is there\", \"discover my setup\", or as the first thing to run on a new site.\n",
  "included_files": [
    {
      "relative_path": "examples/output.md",
      "size_in_bytes": 1842
    }
  ],
  "name": "property-explorer",
  "skill_md_contents": "---\nname: property-explorer\ndescription: >\n  One-time discovery run that maps which custom properties this customer\n  tracks and ranks them by analytical signal (cardinality, revenue\n  concentration, channel variance). Output is a personalized list of the\n  3 highest-value analyses available for this account. Trigger on:\n  \"onboarding\", \"first time\", \"what can you analyze\", \"explore my data\",\n  \"what properties do I have\", \"qué propiedades tengo\", \"what data is\n  there\", \"discover my setup\", or as the first thing to run on a new site.\nshort-description: 'Map which custom properties a Sealmetrics account has and what each unlocks. Use for \"what can you analyze\", \"explore my properties\", \"qué puedo analizar\", \"property map\".'\n---\n\n# Property Explorer\n\nBefore writing your answer, read `examples/output.md` in this skill directory\nand match its density, structure and tone. It is the reference for what a good\nrun of this skill looks like.\n\nDiscover the analytical surface area of a specific Sealmetrics account so\nevery later skill knows what to use. Run **once per site** at engagement\nstart, then again after major tracking changes. Budget: ≤15 calls — higher\nthan other skills because the value compounds across every future run.\n\n## Step 1 — List all property keys across all tables\n\n```\nlist_property_keys(table=conversions)\nlist_property_keys(table=microconversions)\nlist_property_keys(table=conversion_items)\n```\n\nAlso run `list_segments` — saved segments are part of the analytical surface\nand belong in the inventory. For up to three that look business-relevant, call\n`get_segment` and record their size and share of conversions: a segment that is\n8% of sessions and 35% of conversions is a finding in itself.\n\nEach call returns `[{ key, conversions_count, microconversions_count,\ntotal_count }]` — the counts are the coverage signal. Build a deduped table:\nproperty · table(s) · conversions_count · microconversions_count.\n\n## Step 2 — Score each property on three dimensions\n\nFor each property `P`, call `get_property_breakdown(property_key=P,\nperiod=90d)` and compute. The tool has no `limit` or `sort_by` — it returns\nthe full pivot, so rank and truncate the values yourself, and skip properties\nyou already know are identifier-like (thousands of values) rather than pulling\nthe whole list:\n\n- **Cardinality** = distinct values returned.\n  - 2–10: categorical (gender, plan, room_type) — easy to act on.\n  - 11–100: enumerated (category, country code, color) — segmentation gold.\n  - 100–1,000: long tail (city, sub-category) — useful with aggregation.\n  - 1,000+: identifier (sku, product_id, user_id) — needs SKU-style skills.\n- **Revenue concentration** = revenue share of top 3 values ÷ total. Revenue\n  per value is **not** in `get_property_breakdown` (counts only, pivoted by\n  UTM); take it from `get_property_values`, which returns one row per\n  (value, source) with `revenue`.\n  - ≥60%: Pareto — strong signal, name the top values.\n  - 30–60%: spread.\n  - <30%: noise or true uniform demand.\n- **Channel variance** — one call:\n  `get_property_values(property_key=P, group_by=utm_source, period=90d,\n  limit=100)`. This returns every value already split by source, so read the\n  top 3 values out of that single response — the tool cannot filter to one\n  value, and `group_by` accepts only `utm_source`, `utm_medium`,\n  `utm_campaign` or `all`. If the distribution by source is materially\n  different (e.g. value X is 60% of Paid Social but 10% of Organic), this\n  property is **strategic** — it explains channel performance.\n\n## Step 3 — Rank and recommend\n\nScore each property 0–3 across cardinality usefulness, Pareto strength,\nand channel variance; total 0–9. List the top 5.\n\nFor each top property, name the **best follow-up analysis** in plain\nlanguage:\n\n| Property profile | Best follow-up |\n|---|---|\n| Low cardinality + high Pareto | `get_property_breakdown` quarterly review |\n| Mid cardinality + high channel variance | run `channel-mix-optimizer` filtered by top value |\n| SKU-like (1,000+ values) | run `product-friction` |\n| Geographic-like (country/region) | run hotels/ecommerce country playbook |\n| Funnel-stage-like (cart, checkout) | run `funnel-analysis` |\n\n## Output format\n\n1. **Inventory table** — every property: name · table · types · cardinality\n   · score.\n2. **Top 5 with one-line explanation each** of why each scored high.\n3. **3 recommended starter analyses** — concrete commands the user can\n   paste back (e.g. \"Run product-friction on `sku`\", \"Run channel-mix\n   filtered by `category=footwear`\").\n4. **Gaps** — short list of properties typically valuable for this\n   vertical that are **missing**, with a note to add them in tracking\n   (ecommerce: `category`, `price_range`, `brand`; hotels: `room_type`,\n   `rate_plan`, `lead_time`, `stay_length`).\n5. **Persist.** Write the inventory and the top 5 to\n   `<state-dir>/<site_id>/property-map.md`, and update\n   `<state-dir>/<site_id>/profile.json` with the vertical you detected,\n   the site's real event names, and the product identifier (key + table) if\n   one exists. Every later skill reads these instead of rediscovering them —\n   see `skills/seal-copilot/references/state-schema.md`. Tell the user the\n   map is stored and goes stale in 30 days or after any tracking change.\n\n## What you do NOT do\n\n- Do not analyze deeply here — this is discovery, not diagnosis. Refer\n  the user to the right specialist skill instead.\n- Do not call `get_property_breakdown` on an identifier-like property\n  (thousands of values) just to count them — the tool returns the full pivot\n  with no `limit`. Infer cardinality from `get_property_values(limit=100)`\n  first and note \"identifier-like, 100+ values\" instead.\n- Do not score properties with <50 events total — say \"insufficient\n  coverage, revisit when more data arrives\".\n\n---\n\nLog the run in `<state-dir>/<site_id>/runs.jsonl` with exactly these fields\nand no others: `ts` (ISO timestamp, UTC), `skill`, `calls` (the number of\nSealmetrics calls you made, counted), `budget` (this skill's documented\nceiling, a number — `15` here), `verdict` (one of `on_track`, `watch`, `act`,\n`kpis_only`, `refused`, `error`, or the score for an audit), `scheduled`\n(boolean), `notes` (one line). The first real audit wrote `calls_used` and a\nfree-text verdict because this footer said \"calls used\" in prose; the field\nnames are the contract. Skip silently if the path is not writable.\n"
}