Update to Seal Copilot

{
  "description": "Run the Sealmetrics weekly health check — a proactive performance report with verdict and top findings. Trigger on: \"weekly report\", \"health check\", \"how was this week\", \"informe semanal\", \"monday report\", \"give me my marketing report\", or when run from a scheduled task.\n",
  "included_files": [
    {
      "relative_path": "examples/output.md",
      "size_in_bytes": 1166
    }
  ],
  "name": "weekly-health-check",
  "skill_md_contents": "---\nname: weekly-health-check\ndescription: >\n  Run the Sealmetrics weekly health check — a proactive performance report\n  with verdict and top findings. Trigger on: \"weekly report\", \"health check\",\n  \"how was this week\", \"informe semanal\", \"monday report\", \"give me my\n  marketing report\", or when run from a scheduled task.\nshort-description: 'Weekly Sealmetrics performance report with a verdict and top findings. Use for \"weekly report\", \"health check\", \"how was this week\", \"informe semanal\", \"Monday report\".'\n---\n\n# Weekly Health Check\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\nProduce a tight weekly performance report. Budget: ≤8 tool calls.\nApply the operating rules, thresholds, MCP call rules and failure modes from\n`skills/seal-copilot/references/methodology.md`.\n\nIf the period has fewer than 30 conversions, report KPIs only and skip\nfindings — say why in one line.\n\n## Procedure\n\n0. **Follow up on past recommendations first.** Read\n   `<state-dir>/<site_id>/recommendations.jsonl` and act on entries with\n   `status: open` and `verify_on` today or earlier: re-run the one call that\n   measures each `metric`, mark them verified/failed, and rewrite the file.\n   Report the outcomes in one line each, above the new findings — see\n   `skills/seal-copilot/references/state-schema.md`. Skip silently if the\n   ledger is empty or unreadable.\n1. `get_overview(period=7d, compare=previous)` — KPIs and deltas. For\n   seasonal businesses (hotels) also run `compare=yoy` and prefer it.\n2. `get_top_channels(period=this_week)` and `get_top_channels(period=last_week)` —\n   which channels moved. `get_top_channels` does not accept `compare`; diff the\n   two calendar-pair calls yourself (see `methodology.md`, MCP call rules).\n3. `get_campaigns(period=7d, compare=previous, sort_by=revenue, limit=20)`\n   — winners and losers.\n4. If any anomaly (±25%): `get_bot_stats(days=7)` to validate it is human.\n   An empty result means agent analytics is off, not 0% bots — mark the\n   finding \"unvalidated for bots\" (see `methodology.md`).\n5. Optional drill-down (1–2 calls max) only to explain the single biggest\n   mover: `get_landing_pages`, `get_terms`, or `get_devices` as relevant.\n\n## Output format\n\n**Verdict line first:** one of\n- ✅ On track — nothing needs action this week\n- ⚠️ Watch — N items trending wrong, no action yet\n- 🔴 Act now — N items need action this week\n\n**Then KPI table:** entrances, CR, conversions, revenue, AOV — each with\ndelta vs comparable and a one-word direction.\n\n**Then one line for anything the procedure could not do**, whenever a step's\ncall was refused, returned an error as text, or was skipped. The first real\nrun had a +35% traffic spike at 84% bounce and said nothing about the fact\nthat channel and bot data were refused for the site — a reader cannot tell a\nvalidated spike from an unvalidated one unless you say so. Format:\n\n> Not checked: channel split and bot validation — the API refused\n> `get_channels` and `get_bot_stats` for this site (\"Access denied\"). Movers\n> above are unvalidated for bots.\n\nOmit the line only when every step ran.\n\n**Then findings (max 3, ordered by revenue impact).** Each finding:\nevidence (numbers + period) → action → estimated impact → how to verify.\nIf nothing fires, say so in one line — do not pad.\n\n**Close with one suggested question** the user could ask next (e.g. \"Want\nme to diagnose the Paid Search drop?\").\n\nBefore the final message: if no `profile.json` existed, write one with what\ndiscovery established (site, timezone, vertical, event names,\n`agent_analytics_enabled` as `true`/`false`/`\"unknown\"`) **and\n`discovery_cached_at` as today's date** — the 7-day refresh rule reads that\nfield, and a profile without it can never be judged fresh or stale. Append every\nfinding you issued to `recommendations.jsonl` with its metric, baseline,\ntarget and `verify_on` date. Log the run in `runs.jsonl` with exactly the\nfields the state schema lists: `ts`, `skill`, `calls`, `budget`, `verdict`,\n`scheduled`, `notes`. `ts` is a full ISO timestamp in UTC (`2026-09-08T14:02:11Z`),\nnot a date. For this skill `budget` is `8`. `calls` is the number\nof Sealmetrics calls you made, counted, not estimated. Both are numbers.\n\n## Scheduling\n\nFor a scheduled Monday-morning one-pager (compact, email-shareable), use\nthe `monday-briefing` skill instead — it composes this skill plus\nopportunity scan and cart-watchdog status into a single forwardable block.\n\nIf the user wants the full report on a schedule, offer once: \"Want this\nautomatically every Monday morning?\" and set it up with `/schedule` in\nClaude Code, or the equivalent scheduled task in Cowork.\n"
}