---
name: sigpik-growth-teardown
description: >
  Orchestrates a Sigpik MCP growth teardown (“抄作业”): start with free product overview,
  branch by lead acquisition channel into keywords or signals, optionally place the product
  in category rankings, then ask before starting a paid promotion investigation. Use when
  the user wants competitor teardown, growth breakdown, acquisition playbook, 抄作业,
  增长拆解, how a product gets traffic, or similar research with Sigpik MCP tools.
---

# Sigpik growth teardown

Teach an Agent how to reverse-engineer an AI product’s growth with **Sigpik Remote MCP** (`https://sigpik.com/api/mcp`). Facts come from tools; narrative and strategy come from you. Do not invent metrics.

Requires MCP tools from the Sigpik server. Prefer tool names exactly as registered.

## Hard rules

1. **Start with overview.** Always call `get_product_overview` first (free latest-month snapshot). Do not open investigation or dump every tool.
2. **Branch, don’t spray.** After overview, call at most the tools justified by `acquisition.lead_channel` (and user follow-ups).
3. **Facts ≠ causation.** Traffic and channel shares are third-party estimates. Never claim an observed change *caused* growth.
4. **Cite.** Include product page URL from tool `links` (or `https://sigpik.com/tools/{slug}`) and the observation month when quoting traffic/growth.
5. **Paid work needs consent.** Call `start_promotion_investigation` only after the user explicitly agrees **and** pass `confirm_usage: true`. Never invent `confirm_usage`.
6. **No fake polling.** If `get_promotion_investigation` returns `poll_after_seconds`, wait at least that long (or tell the user to check later). Do not hammer `get_*` while `queued`/`running`.
7. **Backlinks are async and paid.** Use `start_backlink_research` only after explicit user consent with `confirm_usage: true`. Prefer `domain`/`slug` (auto-binds the latest applicable backlink signal window). Then `get_backlink_research` and respect `poll_after_seconds` / `poll_hint`.
8. **Entitlement failures are expected.** `list_product_keywords` needs `product.search_intelligence` (Starter+). Backlinks need `backlinks.research`. Signals may be preview-truncated. Explain the gate; offer the public product URL; do not fabricate rows.

## Workflow

### 1. Resolve the product

Inputs: domain (preferred) or canonical slug. If the user pastes a URL, normalize to hostname before calling tools.

```text
get_product_overview({ domain } | { slug }, locale?)
```

- `not_found` → show up to 3 `suggestions`; ask which product; **do not** silently pick a fuzzy match.
- domain+slug conflict → report conflict; do not guess.
- Empty traffic/channels → still continue with identity + “insufficient coverage”; do not invent shares.

### 2. Qualitative snapshot (free path — always do this)

From overview, state briefly:

- Who: `product.name`, domain, primary market
- Scale: `traffic.latest_month`, visits, MoM if present
- Authority: current Domain Rating if present
- Acquisition: `acquisition.lead_channel`, `lead_share`, top channels (share 0–1)
- Link: product page from `links.product_page`

**Free-tier success criteria:** user gets channel qualitative read + product URL. Stop here unless they want deeper facts or paid investigation.

### 3. Channel branch (conditional)

Use `acquisition.lead_channel` (fallback: largest share in `channels`):

| Lead channel | Next tool | Notes |
|---|---|---|
| `search_organic` | `list_product_keywords` | Prefer `brand_scope: "non_brand"`, `limit: 10–20`. If `KEYWORDS_DISABLED`, say Starter+ required and link the product page. |
| `referrals` / `paid_referrals` | `list_product_signals` then optional backlinks | First signals (`window: "30d"`). If the user wants a cleaned backlink list and consents to spend allowance/credits, `start_backlink_research` → `get_backlink_research`. |
| `search_paid` / `social_paid` / `display_ads` / `mail` | Stay on overview + optional signals | Paid-buy narrative from channel mix only — no ad-account or creative inventing. |
| `social_organic` | `list_product_signals` | Look for distribution/product signals; do not invent social posts. |
| `direct` / unknown / `coverage: none` | Optional `list_product_signals` | Say coverage is thin; avoid over-claiming. |

Default: hide AI-visibility noise unless the user asks — pass `family: "ai_visibility"` only then.

Keywords skill note: return **observed facts only**. No competitor keyword gap, no “opportunity score”, no invented volumes.

### 4. Optional market context

Only if the user asks “vs category / ranking / peers”:

1. `list_market_categories` → copy a **canonical** `slug` (do not invent category strings).
2. `rank_ai_products` with that `category` + a fitting `sort` (`growth`, `traffic`, `organic`, `ai`, `paid`, `dr_growth`, …).
3. Place the target product if present; otherwise say it is outside the returned page.

### 5. Optional paid async tools (consent required)

Before spending, call free `get_account_quota` and confirm remaining `promotion_research` / `backlink_research` allowance (and limited MCP call units when `mcp_calls.kind` is `limited`). If remaining is 0, stop and tell the user — do not start.

**Promotion investigation** — deeper “how they promote / cold-start playbook”:

```text
get_account_quota({})
start_promotion_investigation({
  slug,                    // canonical slug from overview
  locale,
  idempotency_key,         // fresh UUID per distinct request
  confirm_usage: true      // required literal
})
get_promotion_investigation({ task_id })
```

**Backlink research** — cleaned referring domains for the latest applicable backlink signal window:

```text
get_account_quota({})
start_backlink_research({
  domain,                  // or slug; auto-binds latest backlink signal window
  confirm_usage: true
})
get_backlink_research({ domain, page_size: 20 })
```

Shared polling rules:

- Respect `poll_after_seconds` and any `poll_hint`. Tell the user progress; **do not tight-loop**.
- Prefer the Summary Header / report fields over dumping every row into chat.
- On entitlement / quota errors, surface the code; do not invent a silent retry that recharges.

## Output shape (suggested)

Keep the answer short unless the user wants a long memo:

1. **Snapshot** — identity, month, visits, lead channel  
2. **Evidence** — 3–7 bullets grounded in tool fields (keywords, signals, or rank row)  
3. **Hypotheses** — clearly labeled speculation; separated from facts  
4. **Next steps** — what another tool or investigation would unlock; ask before spending  

## Anti-patterns

- Calling keywords + signals + rankings + investigation on every request  
- Treating preview signal caps as “the product has only 3 signals” without noting truncation  
- Dumping raw JSON into the user reply  
- Implying Sigpik first-party analytics  
- Starting investigation or backlink research “just in case” without `confirm_usage` consent  
- Calling fictional backlink tools or inventing Domain Rating filters not returned by the API