Update to Seal Copilot

{
  "description": "Install Sealmetrics on a site from scratch: create the site if needed, place the tracking snippet in the codebase, confirm the first hit arrives, then instrument the conversions and microconversions the business actually needs. Trigger on: \"install Sealmetrics\", \"set up Sealmetrics\", \"add analytics to this site\", \"instalar Sealmetrics\", \"configurar el píxel\", \"I have no tracking yet\", \"add the tracking code\", \"instrument my checkout\", or when another skill finds that a site has no data at all.\n",
  "included_files": [
    {
      "relative_path": "examples/output.md",
      "size_in_bytes": 2356
    }
  ],
  "name": "install-sealmetrics",
  "skill_md_contents": "---\nname: install-sealmetrics\ndescription: >\n  Install Sealmetrics on a site from scratch: create the site if needed, place\n  the tracking snippet in the codebase, confirm the first hit arrives, then\n  instrument the conversions and microconversions the business actually needs.\n  Trigger on: \"install Sealmetrics\", \"set up Sealmetrics\", \"add analytics to\n  this site\", \"instalar Sealmetrics\", \"configurar el píxel\", \"I have no\n  tracking yet\", \"add the tracking code\", \"instrument my checkout\", or when\n  another skill finds that a site has no data at all.\nargument-hint: \"[domain]\"\nshort-description: 'Install Sealmetrics from scratch: create the site, place the pixel, verify it, instrument events. Use for \"install Sealmetrics\", \"set up tracking\", \"instalar Sealmetrics\".'\n---\n\n# Install Sealmetrics\n\nTake a site from no analytics to measured and verified. This is the only skill\nthat writes code, and the only one that can create an account — both are gated\nbelow. Budget: ≤15 tool calls plus whatever editing the codebase takes.\n\nBefore writing your answer, read `examples/output.md` in this skill directory\nand match its density, structure and tone.\n\n## Step 0 — Find out where you are starting\n\n1. `get_setup_status` — has a site already been provisioned in this session?\n2. `list_sites` — does the account already have sites? If a site for this\n   domain exists, **skip provisioning entirely** and go to Step 2. Creating a\n   duplicate site splits the data and is hard to undo.\n\nState which of the three starting points applies before doing anything:\nno account, account without this site, or site already exists.\n\n## Step 1 — Create the site (only if there is genuinely no site)\n\n`provision_site` creates a real account on the user's behalf and emails them a\nclaim link. Treat it as the user's decision, never yours:\n\n1. Show them the terms link — https://sealmetrics.com/terms — and say plainly\n   that provisioning creates a free Sealmetrics account tied to their email.\n2. Ask for the email address, the site name and the domain. Do not guess an\n   email from git config, the environment, or anything else you happen to know.\n3. **Wait for the user to say, in their own words, that they accept the terms.**\n   Only then call `provision_site(accept_terms=true, email=…, site_name=…,\n   domain=…)`.\n\nNever pass `accept_terms=true` on your own initiative. If the user has not\nexplicitly accepted in the conversation, stop and ask. If they would rather\nsign up on the website themselves, that is a perfectly good answer — tell them\nto come back with the account id and continue from Step 2.\n\nAfter it succeeds, tell them to check their email for the claim link, because\nthe account has no password until they set one.\n\n## Step 2 — Work out where the snippet goes\n\n`detect_framework(path=<repo root>)` when you have the repository. Without a\nrepo it returns `unknown` plus the manual guide, which is fine — you will hand\nthe snippet to the user instead of placing it.\n\n`get_tracking_code(site_id=…)` returns `script_tag` (the exact tag to place),\n`tracker_url`, a `js_api` block whose `signatures[].call` strings are the\npageview, conversion and microconversion calls to use verbatim, an\n`implementation_guide` with `spa_support` and `content_grouping`, and worked\n`examples` per vertical. Use those signatures as written — do not paraphrase\nthem into a slightly different API.\n\n**Placement rules that matter more than the framework:**\n\n- The snippet goes in `<head>`, and it must load **before** anything that calls\n  `sealmetrics.*`. Most \"sealmetrics is not defined\" reports are a tag manager\n  firing before the tracker.\n- One installation per site. Two copies double every pageview.\n- In a single-page app, the tracker must be told about route changes rather\n  than reloading — otherwise you get one pageview per session, or duplicates,\n  depending on how the router is wired. Follow the API reference for the\n  framework you detected.\n\nPlace it, show the diff, and say which file you edited.\n\n## Step 3 — Prove it works before going further\n\n`verify_setup(account_id=…, timeout_seconds=…)` polls until a real pageview\narrives. Ask the user to open the site in a browser while it runs.\n\nIf it times out, do not guess: call `get_troubleshooting_guide` and work the\nmatching symptom. The usual causes are the snippet sitting outside `<head>`, a\nbuild that has not been deployed yet, or an ad blocker on the only browser\nbeing tested.\n\n**Do not instrument events until a pageview is confirmed.** Everything after\nthis depends on the tracker loading at all.\n\n## Step 4 — Instrument what the business actually measures\n\n`get_instrumentation_guide(account_id=…)` returns the canonical taxonomy with\nthe account id substituted. Follow it — the conversion and microconversion\nnames are a closed set, and inventing names is what makes later analysis\nimpossible.\n\nAsk what the site is for, then instrument the funnel for that vertical:\n\n| Vertical | Conversions | Microconversions |\n|---|---|---|\n| Ecommerce | `purchase` with revenue | `product_view`, `add_to_cart`, `start_checkout` |\n| Hotel / travel | `booking` with revenue | `room_view`, `booking_start` |\n| SaaS / lead-gen | `signup`, `demo_request`, `trial_start` | `pricing_view`, `cta_click`, `form_view` |\n\nTwo things to get right at install time, because retrofitting them is painful:\n\n- **Pass revenue** on the conversion where revenue exists. Without it every\n  later recommendation is expressed in conversions instead of euros.\n- **Pass a product identifier** on *both* the product-view and the\n  add-to-cart events, using the same key and the same value. This single\n  detail is what makes per-SKU analysis possible later. Getting it right now\n  costs nothing; adding it in six months means six months of unusable history.\n\nNever send personal data. Sealmetrics is consentless by design and that\nproperty depends on no identifiers being passed — no emails, names, user ids,\norder ids, phone numbers or addresses, in any event or property.\n\n## Step 5 — Verify each event, not just the pixel\n\nFor every event you wrote:\n\n`verify_event_instrumented(account_id=…, kind='conv'|'micro', name=…,\ntimeout_seconds=…)`\n\nAsk the user to perform the action — add something to the cart, submit the\nform — while it polls. An event that was written but never fires is worse than\na missing one, because it looks instrumented in the code review.\n\nReport each event as confirmed or not confirmed. Do not mark an event done\nbecause the code looks right.\n\n## Step 6 — Hand off\n\n1. Write what you established into\n   `<state-dir>/<site_id>/profile.json` — site id, domain, timezone,\n   vertical, the real event names you used and the product identifier key.\n   See `skills/seal-copilot/references/state-schema.md`.\n2. Tell the user that data takes a few days to become analyzable, and name the\n   first analysis that will be worth running: `property-explorer` once events\n   are flowing, then `weekly-health-check`.\n3. If anything is instrumented but unverified, say so explicitly and offer\n   `setup-audit` to re-check once traffic arrives.\n\n## What you do NOT do\n\n- Do not call `provision_site` without the user's explicit acceptance of the\n  terms in this conversation. Never infer acceptance from their asking you to\n  install Sealmetrics.\n- Do not create a second site for a domain that already has one.\n- Do not pass any personal identifier into any event or property.\n- Do not claim an event works because you wrote the code. Only\n  `verify_event_instrumented` settles that.\n- Do not invent event names outside the instrumentation guide's taxonomy.\n- Do not deploy. You edit the code; shipping it is the user's call.\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"
}