1. Only ever show the downloading user's data. Pull exclusively from their connected MCPs. Never inject numbers, campaign names, replies, or examples from anyone else. The template ships empty; it is filled at runtime with their live values. If you cannot pull a value, render the documented empty state — never a placeholder number and never a value borrowed from somewhere else.
2. The output is a LIVE ARTIFACT, not a saved HTML file. In Generate mode you fill the template in memory and render it as a live artifact using the available artifact tool (whatever the current Cowork build exposes for creating/updating an artifact — do not hard-code a tool name). On a refresh, update the existing artifact rather than creating a new one. The

   assets/dashboard-template.html

   file is the build source only.

• Setup mode (first run, or when LGM isn't connected / no identity chosen yet): interactive. Detect the environment, guide install if needed, ask the scoping questions. Conversational.
• Generate mode (every run once setup is done): run the engine, fill the template, emit the artifact + a short handoff. Apply output discipline here — return the artifact and a few lines of handoff, no step-by-step narration.

./.lgm-wpa/

• LGM MCP present? True if tools named

  mcp__*

  for La Growth Machine are available, i.e. any of

  list_identities

  ,

  list_campaigns

  ,

  get_campaign_stats

  ,

  get_conversations_to_reply

  ,

  get_conversation_messages

  ,

  search_conversations

  . (In a terminal you could also confirm with

  claude mcp list

  showing an LGM server, but tool presence is enough — never ask the user.)
• CRM / deal MCP present? Is a HubSpot MCP available (deal/company/contact tools)?

• campaign-impact-analyzer

  skill available? (used to build the optional deal/€ layer.)

1. From the

   gtm-system

   repo, run the installer and complete browser sign-in:
   bash

   sh install.sh

   (or the curl one-liner the repo's README provides). Auth is browser OAuth — there is no API key to paste.
2. No LGM account yet → point them to register at https://app.lagrowthmachine.com and then re-run the installer.
3. After they've run it, re-detect (Phase 0). Loop until the LGM tools appear, then continue.

—

• CRM/deal MCP present → offer now: "Want me to add the deals/€ layer (which campaigns actually drove pipeline), or ship the dashboard first and add it later?"
• No CRM MCP → ask "What do you track deals in?" (HubSpot / Salesforce / Sheets / other / none).
  • HubSpot but not connected → offer to connect it (then it becomes "present").
  • Salesforce / Sheets / other / complex → dashboard-first; add the deal layer later.

• If

  campaign-impact-analyzer

  is available → delegate the LGM×CRM cross-reference to it to populate the "Deals from campaigns" box (deal count + €, this week, portfolio-wide). Use its output to fill

  {{DEALS_VALUE}}

  /

  {{DEALS_NOTE}}

  .
• If

  campaign-impact-analyzer

  is not available → do not block and do not inline a join cascade. Ship the LGM-only dashboard (deals box shows

  —

  ) and, in the handoff, add the pointer: "For the deals/€ layer, install

  campaign-impact-analyzer

  from gtm-system, then re-run."

Ask (English, verbatim-ish): "To make the ↻ Refresh button live, I can set up a weekly routine that re-pulls your La Growth Machine data and updates this dashboard every Monday morning. Want me to set it up?"

• Yes → create a scheduled task with the available scheduling tool, cadence Monday morning (weekly), whose prompt re-runs THIS skill in Generate mode for the same identity/identities and updates the existing artifact (it does not create a new one). Suggested task prompt to store:

  "Re-run the weekly-performance-advisor skill in Generate mode for identity/identities [<ids>]: pull fresh La Growth Machine data, recompute the engine, update the existing Weekly Performance Advisor artifact, and write this week's snapshot to ./.lgm-wpa/. Do not ask questions; setup is already done."

  • Capture the task id the tool returns at runtime and pass it into the template as

    {{REFRESH_TASK_ID}}

    so the ↻ button triggers this user's task. The id is resolved per user at creation time — never hard-code an id in the shipped files.
  • The button already calls

    runScheduledTask(<that id>)

    and shows a graceful message if it can't run.
• No / skip → fill

  {{REFRESH_TASK_ID}}

  with an empty string. The ↻ button then falls back to a friendly alert (nothing breaks); mention they can enable the routine anytime by re-running the skill.

• To do tab = your week: the moves to make, replies to handle (urgency-sorted), and the only-🔴 campaigns to fix. Weekly performance tab = the stats: count KPIs with WoW/30-day deltas, volume-weighted health gauges, and the full campaign panorama.
• Refresh weekly: if they enabled the routine (Phase 4.5), the ↻ button and the Monday task keep the dashboard fresh; otherwise they can re-run this skill anytime (and enable the routine then). Deltas and the 30-day trend come alive after 2+ weeks of snapshots.
• Routine status: confirm whether the Monday auto-refresh was set up (Phase 4.5). If they skipped it, remind them the ↻ button stays inert until the routine exists.
• Classify replies in LGM: nudge them to tag replies (interested / not) in the LGM inbox — it makes next week's positive-reply count and trend sharper.
• Fix-this buttons in the artifact open a copy/paste prompt modal (the ready-made prompt targets the matching gtm-system skill —

  /reply-draft-assistant

  ,

  /campaign-challenger

  ,

  /sales-nav-search-builder

  ,

  /won-deal-icp-finder

  ) to paste into a new conversation.

1. list_identities

   → resolve the selected identity id(s) and name(s).

2. list_campaigns {status:"RUNNING"}

   (paginate) → keep campaigns whose

   identity.id

   ∈ selected.

3. get_campaign_stats

   per kept campaign → per-channel counters.
4. Replies — two distinct pulls (do not conflate them):
   • Actionable "to handle" list →

     get_conversations_to_reply {identityIds:[...selected]}

     : threads currently awaiting your reply. Drives E8 (the rows shown on the To do tab).
   • This-week count set →

     search_conversations

     filtered to RECEIVED this week (the lead replied since Monday), scoped to the selected identities — regardless of whether you've already answered. Drives the E9 count KPIs. This is what makes the hero count accurate: an "interested" lead you already replied to has left the to-handle queue but must still be counted this week.
   • For any thread in either set not yet in the latest snapshot's

     classifiedReplyIds

     , read

     get_conversation_messages

     and classify (incremental — don't re-classify known ids).

campaign = {
  id, name, contacted,
  li: {accept, reply, csent, msent} | null,     // % values; csent = connection-request sends, msent = message sends
  em: {sent, deliv, open, reply, click, bounce, atag, eng} | null
}

• atag

  = the email step contains a tracked

  <a href>

  link (only then is click a real KPI).

• eng

  = email had any engagement to score = (email reply > 0) OR (email click > 0).
• A campaign with

  contacted < 20

  is low-sample: list it, do not score or rank it.

(good, floor, direction)

linkedin_acceptance = (30, 20, up)
linkedin_reply      = (25, 15, up)
email_open          = (60, 45, up)
email_reply         = (6,  3,  up)      # cold-email calibration
email_click         = (8,  4,  up)      # shown, NOT status-driving
email_bounce        = (15, 25, down)    # lower is better
email_deliverability= (90, 80, up)      # not shown as a gauge (see note)

• No deliverability gauge. In LGM

  Delivered = Sent − Bounced

  , so "deliverability" is just

  100 − bounce

  — not a true inbox-placement signal. We track bounce instead (the actionable email technical-health metric). The five portfolio gauges are: LinkedIn acceptance, LinkedIn reply, email bounce, email open, email reply.

• MIN_SEND = 10

  : a KPI or step needs ≥10 sends to be scored, else "insufficient volume".

g if v≥good else y if v≥floor else r

g if v<good else y if v≤floor else r

max(0,(floor−v)/floor)

max(0,(v−floor)/floor)

(kpi, value, state, driving)

• If

  li

  :

  linkedin_acceptance

  (scored if

  csent≥10

  else insuf),

  linkedin_reply

  (scored if

  msent≥10

  else insuf).
• If

  em

  and

  em.sent≥10

  and

  em.eng

  :

  email_open

  ,

  email_reply

  , then

  email_click

  only if

  em.atag

  (non-driving), then

  email_bounce

  .
• If

  em

  and

  em.sent≥10

  and not

  em.eng

  : no email KPIs scored → render the line "Email: {sent} sent · {open}% open · 0 replies · 0 clicks - delivered, no engagement to score".

• li_sends = li.msent (or 0)

  ,

  em_raw = em.sent (or 0)

  ,

  total = li_sends + em_raw

  .

• primary = 'li' if li_sends ≥ em_raw else 'email'

  .

  SEC_MIN = 0.30

  .

• balanced = li_sends>0 AND em scored AND min(li_share, em_share) ≥ 0.30

  .
• is_driving(k):

  • email_click

    → never driving.

  • linkedin_*

    →

    li present AND li.msent≥10 AND (primary=='li' OR balanced)

    .

  • email_bounce

    → driving whenever email is scored (technical health always counts).

  • email_open

    /

    email_reply

    →

    email scored AND (primary=='email' OR balanced)

    .

• driving_reds

  /

  driving_yellows

  = driving KPIs at 🔴 / 🟡.
• status =

  To fix

  if any driving_reds, else

  Watch

  if any driving_yellows, else

  On target

  . (Internally "On target" is the healthy state; never print the words "Healthy" or "needs work".)
• Secondary-channel red (a 🔴 KPI that is NOT driving, on linkedin_acceptance/linkedin_reply/ email_open/email_reply) → don't flip the whole campaign; attach a "email leg to fix" or "LinkedIn leg to fix" chip instead.

• Among

  driving_reds

  , pick the weakest step in funnel order, EXCLUDING the terminal breakup step:

  FUNNEL = [email_bounce, linkedin_acceptance, email_open, linkedin_reply, email_reply]

  → take the first in this order that is red.

• s = sev(k, v)

  ;

  conf = high if s≥0.4 else medium

  . Cap conf to medium when the flagged step has

  <20

  sends (driving evidence is thin). When you show verbatim "current copy", annotate the step type (Intro / Follow-up / BreakUp); the flagged step must not be the breakup.
• Cause + routing skill per KPI:

  linkedin_acceptance -> "targeting or connection note" -> sales-nav-search-builder
  linkedin_reply      -> "message copy"                 -> campaign-challenger
  email_open          -> "subject line or setup"        -> campaign-challenger
  email_reply         -> "message copy"                 -> campaign-challenger
  email_bounce        -> "list quality / warm-up"       -> won-deal-icp-finder   (also flag list hygiene / email verification)

• Channel tip (

  reco

  ): if both LinkedIn reply and email reply are scored and one is red while the other is green/yellow, recommend favoring the stronger channel and reworking/dropping the weaker leg.
• Ranking:

  prio = maxsev(driving_reds) × contacted

  . To-fix cards sorted by

  prio

  desc.

• Classify each new RECEIVED reply into

  interested / neutral / not_interested / wrong_fit

  from the thread.

  hot

  = explicit call/meeting request.

  corr

  = LGM auto-qualify said interested but you corrected it here.

  chan

  ∈ {LINKEDIN, EMAIL}.

  act

  (actionable) =

  cls ∈ {interested, neutral}

  .
• waited days =

  floor((asOf − lastMessageAt)/86400000)

  , min 0;

  urgent

  = actionable AND waited > 3.
• Urgency sort (actionable only): group 0 = call requests (

  hot

  ), 1 = interested, 2 = neutral; within a group, longest-waiting first. Show a "waited Xd" badge per row (urgent → red marker).
• Only interested + neutral are listed as rows.

  not_interested

  /

  wrong_fit

  are collapsed to a count behind an "open in LGM inbox ↗" link; keep a small "N corrected" tally visible there so auto-qualify corrections stay surfaced. No write-back to LGM (the user validates in LGM).

search_conversations

• TOTAL_POSITIVE_REPLIES

  (hero) = count of this-week received threads classified

  interested

  (incl. call requests), portfolio-wide.

• TOTAL_REPLIES

  (secondary) = count of this-week received threads (any lead reply this week).
• Week-cumulative + refresh-safe: persist this week's positive and total counts (and the

  classifiedReplyIds

  ) in the snapshot. On a re-run within the same ISO week, take the union of already-counted ids and the fresh set — a refresh may only add, never drop, a reply already counted this week. (Across weeks the count resets per week, as expected.)
• Never render a "0 positive leads" hero; if zero, show

  0

  plainly with the delta caveat.

./.lgm-wpa/

• For each count KPI and each gauge, show vs last week and vs trailing-30-day weekly average (last ≤4 prior weeks). Arrow ▲/▼; up = green, down = red — inverted for bounce (down is good).
• Units: counts have no unit; gauges use

  pt

  . Zero delta →

  +0

  .
• No history yet → render

  — · trend starts after 2+ weeks

  and caption "Baseline week - trends start after 2+ weeks of history." With history, caption is "Deltas compare this week vs last week and vs the trailing 30-day weekly average."

• 🟢 On target — lists the gauges currently green (`"LinkedIn acceptance 53%, email bounce 7% ...
  • all on target."`).
• 🟡 Watch — for each non-green gauge,

  "<KPI> <v>% - <gap>pt under/over the <good>% target, <note>"

  where note =

  just optimization, not urgent

  if gap ≤ 3, else

  worth a pass

  (or, if that gauge is red,

  needs work

  ). Add the pill

  N campaign(s) to fix

  . Then a red line:

  "Real fix: N campaign(s) to fix on their main channel - <name> (<KPI> <v>%); ... Rewrite that copy first."

  — so 🔴 campaigns stay visible on this tab and point to the To do tab.
• Empty state: no 🔴 campaigns → the To-fix cards region shows "No 🔴 campaigns this week - every running campaign is On target or Watch on its primary channel."

card-name

badge tofix

contacted N

data-prompt

• campaign-challenger

  :

  Use the /campaign-challenger skill. Challenge campaign "{name}" ({label} {value}%, below the {floor}% floor, likely {cause}): rewrite the current copy of the flagged step. If the /campaign-challenger skill is not installed, download it from https://github.com/LaGrowthMachine/gtm-system first, then run it.

• sales-nav-search-builder

  :

  ... Rebuild the targeting for campaign "{name}" ({label} {value}%, below the {floor}% floor): draft a tighter Sales Navigator search and connection note. ...

• won-deal-icp-finder

  :

  ... Clean the audience for campaign "{name}" ({label} {value}%, below the {floor}% floor): rebuild it from a verified ICP list. ...

fix1

{conf} confidence

{value}% now · target ≥{good}% · floor {floor}% · {gap} pt(s) under target

Likely cause: {cause}

reco

diag-out

focus

<details>

./.lgm-wpa/

./.lgm-wpa/snapshot-<YYYY>-W<ww>.json

{
  "week": "2026-W28",
  "identities": ["<id>", ...],
  "counts": { "posReplies": N, "totalReplies": N },
  "positiveReplyIds": ["<conversationId>", ...],   // this-week ids classified interested (for the union)
  "weekReplyIds": ["<conversationId>", ...],        // this-week ids that received a lead reply
  "gauges": { "linkedin_acceptance": %, "linkedin_reply": %, "email_bounce": %, "email_open": %, "email_reply": % },
  "campaigns": [ { "id", "name", "contacted", "status", "fix1": {...}|null, "kpis": {...} } ],
  "classifiedReplyIds": ["<conversationId>", ...]   // every id already classified (skip-list, incremental)
}

• First run = baseline: no prior snapshot → all deltas render

  —

  and the baseline caption.
• Before overwriting, load the latest prior snapshot to compute WoW + 30-day deltas and to skip already-classified reply ids. Keep ≥5 weeks (prune older) so the ~4-week average is computable.
• One snapshot per ISO week. Re-running in the same week updates that week's file: union

  positiveReplyIds

  /

  weekReplyIds

  with the fresh pull, recompute

  counts

  from the unions (so the hero count is refresh-safe and only grows within the week), then persist. Deltas always compare against prior weeks' snapshots, never the current week's earlier run.

• Fresh env, LGM absent → skill guided install, waited, re-detected, then proceeded.
• LGM present → detected silently, asked identity, (optionally) deals, built the artifact from the user's live data. No data from anyone but the user appears anywhere.
• HubSpot +

  campaign-impact-analyzer

  present → deal layer offered and delegated.

• campaign-impact-analyzer

  absent → dashboard shipped anyway + install pointer in the handoff.
• Output is a live artifact (2 tabs) rendered with the available artifact tool (no hard-coded tool name); a snapshot was written to

  ./.lgm-wpa/

  .
• Refresh routine offered (Phase 4.5): on yes → Monday task created, its runtime id injected as

  {{REFRESH_TASK_ID}}

  , ↻ button live; on skip → empty id, button falls back gracefully. No real task id is embedded in the shipped files.
• Counts are refresh-safe:

  posReplies

  /

  totalReplies

  come from the this-week RECEIVED set (

  search_conversations

  ), persisted and unioned within the week, so a mid-week refresh only adds and never drops an already-counted reply (fixes undercount from the to-handle queue).
• Single status lexicon (On target / Watch / To fix) everywhere; email reply uses 🟢≥6/🟡3-6/🔴<3; bounce gauge (not deliverability); no benchmark source/brand cited; English; self-contained.