提示词图库

Prompts

promptsPage.hero.subtitle

一旦安装了 @gurulu/mcp-server，MCP 就绪的提示词便能触达真实的注册表/事件数据。AI 层（第 2 阶段）提示词已在路线图上——现在就复制好，随时待命。

63 条提示词

MCP-readyDeveloper

向注册表新增一个事件

@gurulu I want to add a new event. First call list_events to check for collisions, then add_event with this contract:

Event: {{event_key}}
Class: {{interaction|intent|outcome}}
Owning team: {{team_name}}
Trigger location: {{trigger_location}}

Required properties:
- {{required_property_1}}: {{type}}
- {{required_property_2}}: {{type}}

Optional properties:
- {{optional_property_1}}: {{type}}

Enforce snake_case. Summarize the contract back to me before adding.

#registry#mcp

MCP-readyDeveloper

生成一个带类型的事件追踪器

@gurulu Generate a TypeScript wrapper for these registry events: {{event_keys}}

- One function per event (e.g. trackSignupCompleted())
- Required fields required, optional optional
- JSDoc with the registry description and a sample payload
- Works against both @gurulu/web and @gurulu/node

Return a single copy-pasteable file: events.gen.ts

#registry#codegen

MCP-readyDeveloper

调试一个缺失的生产事件

@gurulu This event is not showing up in production: {{event_key}}

Check in order:
1. Is it defined in the registry? (validate_event)
2. Did it land in ingestion in the last hour? (event-health)
3. If it did, was it quarantined or rejected? Why?
4. Could the current consent state be blocking it?
5. If a webhook is involved, give me the last dispatches + error rate.

List findings by priority and propose a fix.

#pipeline#debug

MCP-readyDeveloper

编写并模拟一项归因策略

@gurulu Let's author a new attribution policy for {{tenant_or_workspace}}.

Context: {{free_text_business_context}}
Outcome event: {{outcome_event_key}}
Touchpoint events: {{touchpoint_event_keys}}
Lookback: {{14d|30d|90d}}
Model: {{first_touch|last_touch|linear|time_decay|position_based|data_driven}}

Return the policy as JSON with provenance trace enabled. Simulate it across 3 sample touchpoint paths before applying.

#attribution

MCP-readyDeveloper

把契约漂移检查接入 CI

@gurulu Propose a CI workflow for this repo: on every PR, run `gurulu validate` so any event call that doesn't match the registry contract fails the PR.

Branch: {{main}}
Package manager: {{bun|pnpm|npm}}
CI: {{github_actions|gitlab|circle}}

Give me the YAML + the secrets needed (GURULU_API_KEY, GURULU_PROJECT_REF). Show a dry-run first.

#ci#registry

MCP-readyDeveloper

审计某个特定用户的授权状态

@gurulu Run a consent audit for this user:

person_id or anonymous_id: {{id}}

Return:
- Latest GCM v2 decision (analytics_storage, ad_storage, ad_user_data, ad_personalization)
- Decision-change history (when, from which channel)
- DSR export / forget request history
- Which events are currently blocked given their consent

Is there anything to fix under GDPR / CCPA / KVKK?

#consent#gdpr

MCP-readyDeveloper

身份合并——先做演练

@gurulu Dry-run a merge BEFORE applying it:

Source anonymous_id: {{anon_id}}
Target person_id: {{person_id}}

Report:
- Timeline after merge (how many events combine)
- 3-level confidence score
- Property conflicts (e.g. two different emails)
- Proposed ledger entry description
- Reversibility plan (how we roll back if wrong)

Do not perform the real merge without my approval.

#identity

AI 层 · P2Developer

为 Webhook 校验器生成集成测试

@gurulu/node webhook verifier — generate an integration test suite:

Provider: {{stripe|shopify|lemonsqueezy|custom}}
Framework: {{hono|express|fastify}}
Test runner: {{bun_test|vitest|jest}}

Coverage:
- Valid signature → 200 + event consumed
- Invalid signature → 401, no replay
- Stale timestamp (>5min) → reject
- Body tampering → reject
- Same event twice (dedup)

Single file, with mock fixtures.

#webhook#sdk-server

MCP-readyDeveloper

编写一条异常健康度规则

@gurulu Set up an anomaly health rule for {{event_key}}:

Metric: {{volume|unique_users|payload_size|missing_required_fields_rate}}
Window: {{1h|6h|24h}}
Expected deviation: {{stddev|percent}}
Alert severity: {{info|warn|critical}}
Notification channel: {{discord|email|slack|webhook}}

Pull the last 14 days as baseline, propose the threshold, and show me before saving.

#health#anomaly

MCP-readyDeveloper

搭建一个工作区并邀请团队

@gurulu Set up a new workspace:

Tenant: {{tenant_slug}}
Workspace name: {{workspace_name}}
Environment: {{development|staging|production}}
Region: {{eu_falkenstein|eu_helsinki}}

Invite:
- {{email_1}} → {{owner|admin|member|viewer}}
- {{email_2}} → {{role}}

Initial seed: {{industry_pack: ecommerce|saas|gambling|media|finance}}. Create workspace + memberships + magic-link invites in one go, confirm the audit log entries.

#onboarding

AI 层 · P2Marketer

每周渠道表现摘要

@gurulu Summarize last week (Mon-Sun, {{week_range}}) for marketing:

- Outcome event: {{outcome_event_key}}
- Compare against: previous week + 4-week average
- Break down by: channel × campaign × device
- Top 3 risers, top 3 fallers
- Anomaly note for any spike / dip
- 3 paste-ready Slack action recommendations

Format numbers cleanly.

#report#weekly

MCP-readyMarketer

跨模型归因对比

@gurulu For the last {{30d|90d}}, compare 5 attribution models against the same outcome:

Outcome: {{outcome_event_key}}
Scope: {{tenant_or_workspace}}
Models: last_touch, first_touch, linear, time_decay, data_driven

Table: | Channel | Last | First | Linear | Time-decay | Data-driven |

Comment on which model flatters which channel. End with one data-grounded recommendation.

#attribution

MCP-readyMarketer

转化率最高的渠道与创意

@gurulu For the last {{30d}}, surface the highest-converting sources:

Outcome: {{outcome_event_key}}
Min touchpoints: {{50}}
Dimensions: utm_source × utm_medium × utm_campaign × utm_content

Metrics: count, conversion rate, avg time-to-outcome, median revenue (if available).

Top 10 + bottom 5 as separate lists. Flag rows with low sample as low-confidence.

#channels

MCP-readyMarketer

UTM 覆盖率审计

@gurulu Run a UTM coverage report for the last {{14d}}:

- % of sessions missing utm_source + their top referers
- Most-used utm_campaigns and the channels they show up on
- Spelling variants of the same campaign (Spring_Sale vs spring-sale)
- 3 hypotheses for what's hiding inside '(direct)' traffic

Sort by fix priority — big-loss first, cosmetic last.

#utm#health

AI 层 · P2Marketer

为转化率最高的流程撰写文案变体

Identify the highest-converting step on {{flow_or_landing_url}} and write 5 alternative headlines + 3 CTAs.

Audience: {{audience_short_description}}
Brand tone: {{terminal|plain|friendly}}
Banned words: {{list_optional}}

For each variant, parenthesize the pain it targets. Recommend which one to A/B first.

#copy

AI 层 · P2Marketer

季度董事会幻灯片初稿

Board deck for {{quarter — Q3 2026}}:

- Primary outcome: {{outcome_event_key}}
- vs last quarter and vs start of year
- 3 wins, 2 misses (with evidence and numbers)
- Plan vs actual
- 3 priorities for next quarter

Output: 6 slide titles + 3 bullets each + speaking notes. Friendly to CFOs but no polish on the numbers.

#report#board

AI 层 · P2Marketer

解释一次流量下跌

Last week {{paid_search|paid_social|organic}} traffic dropped {{X}}%. Enumerate possible causes:

- Budget / campaign pause
- Bidding change (CPC spike?)
- Creative fatigue (rising frequency)
- Broken UTMs
- Server / CDN / landing perf (event-health rage_click)
- Seasonality / event calendar

Pull evidence for each. Start with the top 3 most likely.

#anomaly

MCP-readyMarketer

落地页行为审计

@gurulu For the last {{30d}}, report on {{landing_url}}:

- Pageview count
- Scroll-depth distribution (25 / 50 / 75 / 100)
- Rage_click frequency
- Form_started → form_submitted conversion rate
- Top 10 outbound click destinations
- Bounce by source

Recommend 3 concrete fixes: copy, layout, performance — which is priority?

#landing#bounce

MCP-readyGrowth

漏斗流失分析

@gurulu Build this funnel:
1. {{step_1_event_key}}
2. {{step_2_event_key}}
3. {{step_3_event_key}}
4. {{step_4_event_key}}
5. {{outcome_event_key}}

Window: {{7d|14d|30d}} · Cohort: {{new_users|returning|all}}

Return:
- Per-step conversion + drop-off
- The step with the biggest drop
- Most common failure pattern at that step (form_validation_error, payment_declined…)
- Mobile vs desktop split

Write one hypothesis for the drop.

#funnel

MCP-readyGrowth

群组留存——最大的跌落点

@gurulu Weekly cohort retention table:

Cohort definition: {{first_seen_week}}
Retention event: {{retention_event_key}}
Weeks observed: 8

Return:
- Table (cohort × W0..W8)
- Which cohort dropped sharply? In which week?
- That cohort's acquisition source
- How it differs from a 'healthy' cohort

Recommend whether this looks like a product issue or an acquisition issue.

#cohort#retention

AI 层 · P2Growth

在数据中找到激活时刻

Which event or event-chain correlates most strongly with retention?

Retention proxy: {{day_7_return | day_28_return}}
Candidate events: {{event_keys_optional}}

Return:
- Strongest correlate: event or event_count ≥ N
- Correlation ≠ causation caveat + a counterfactual to consider
- A one-sentence 'aha-moment' candidate
- Suggested onboarding action to pull users toward it

Add a sample-size warning.

#activation

AI 层 · P2Growth

把一个观察转化为实验假设

Turn this observation into a Lean experiment hypothesis:

Observation: {{plain_text_observation}}
Affected metric: {{metric_name}}

Return:
- Hypothesis ('if … then … because …')
- Minimum detectable effect (MDE)
- Required sample size (alpha 0.05, power 0.8)
- Estimated duration given current traffic
- 2 guardrail metrics

If sample is short, narrow the hypothesis.

#experiment

AI 层 · P2Growth

揪出一个流失信号

Identify users who haven't returned in {{X}} days, then mine the last 7 days before they left for shared patterns:

- Events that dropped most vs the prior week
- 'Near-exit' events (error_shown, payment_failed, support_ticket_opened)
- Plan / tier breakdown
- Onboarding step skipped in the first 24h

Draft a re-engagement segment and tell me how many users it covers.

#churn

MCP-readyGrowth

构建一个重新激活分群

@gurulu Build and name this segment:

Name: {{segment_name}}
Definition: users who did {{trigger_event_key}} in the last {{30d}} but did NOT do {{exclude_event_key}}
Property filter: {{country_in: TR,DE}} and plan_tier = {{free}}
Min outcome: {{outcome_event_key}} ≥ 1

Prepare it for {{crm|ads}} destinations. Tell me the count, save the manifest.

#audience

MCP-readyGrowth

北极星指标——90 天趋势

@gurulu North-star: {{north_star_metric}}

Return:
- 90-day weekly series
- Last 4-week average vs prior 4-week average
- Trend: up / down / flat
- Major breakpoints (deploys, campaigns, external events)
- 95% confidence interval

Project 30/60/90 days linearly under 'if this trend continues'.

#metric

AI 层 · P2Growth

A/B 测试统计解读

Analyze this A/B result:

Control: n={{n_control}}, conversions={{c_control}}
Variant: n={{n_variant}}, conversions={{c_variant}}
Primary metric: {{metric_name}}
Alpha 0.05, two-sided.

Return:
- Lift (% and absolute)
- p-value
- 95% confidence interval
- Significant or not, why
- Peeking-penalty warning
- Decision: ship / kill / continue

Run a sample ratio mismatch (SRM) check too.

#experiment#stats

AI 层 · P2Founder

晨间简报——昨天发生了什么

Yesterday's summary, readable in 3 minutes:

- 3 core outcome event totals + prior 7-day average
- The one anomalous event (if any) + raw count
- New health rule alerts
- Yesterday's top rising and top falling channel
- Open DSR / forget request count

One sentence per bullet. Tag anything that needs action 'TODAY'.

#daily

MCP-readyFounder

所有集成的健康度

@gurulu Sweep every active integration:

- SDK web: last 24h volume, error rate, version split
- SDK server: same + webhook dispatch error rate
- Webhook providers (Stripe / Shopify / LS / Custom): last 100 dispatches, failure %
- CAPI destinations (Meta / Google Ads / EMQ): dedup match rate
- AI layer: model fallback count, latency p95

Red flags first. One-line action per item.

#health

AI 层 · P2Founder

结果驱动的收入摘要

Last 30 days — outcome-driven revenue summary:

Outcome event: {{outcome_event_key}}
Currency: {{TRY|EUR|USD}}

- Total: net + refunds
- vs prior 30 days
- Top 5 customers by value (anon ID + amount)
- New vs renewal split
- Refund rate + top 5 reasons

Top-line only — don't confuse with burn.

#outcome#revenue

MCP-readyFounder

数据质量审计

@gurulu Run a data-quality audit for the last {{7d}}:

- Quarantine / reject count + top 10 reasons
- Missing required-field patterns (event_key × field)
- Duplicate count (dedup hits)
- Identity confidence distribution (low / medium / high %)
- Schema drift warnings
- Pending conflicting person-merge suggestions

Sort by volume first, then by persistent pattern.

#quality

MCP-readyFounder

本月对比上月

@gurulu Compare this month ({{month_year}}) to last month:

Outcome event: {{outcome_event_key}}

- Total + % change
- Weekly curve (both months together)
- 3 most-changed channels (up + down)
- New big customer / segment won or lost
- vs same period last year (if available)

No bold claims — say what the data says.

#compare#monthly

AI 层 · P2Founder

本周发生了哪些实质性变化

Pull everything that changed materially last week into one list:

- Outcome events with ±2σ or ±15% deviation
- Registry events added or removed
- Unusual jumps in the identity merge ledger
- New health rule alerts
- New destination / CAPI connection
- DSR forget backlog

1 line per item with a 'why it matters' parenthetical. Max 10 items.

#anomaly#weekly

AI 层 · P2Founder

投资人更新初稿

Draft an investor update for {{month_year}}:

- TL;DR (3 bullets, top line is the most important number)
- Community + product metrics: {{north_star}}, MRR/ARR, customer count, NPS
- Wins + learnings this month
- Open asks — what can the investor help with?
- 3 priorities for next month

No number chasing. If we dropped somewhere, say why and what the plan is.

#investor

AI 层 · P2Founder

异常解释

Explain the {{event_or_metric}} anomaly on {{date}}:

- Magnitude (absolute + % vs baseline)
- Any other anomalous signals at the same time (deploy, ad spike, downstream service)
- Top 3 likely causes
- Data error vs real — what evidence
- 2 queries to run for verification

This will be used for a board / investor summary — keep it short and honest.

#anomaly

MCP-readyMarketer

从 RFM 队列构建高价值受众

@gurulu 从 RFM 队列生成 M24 受众并推送到目的地：

源队列：{{cohort_id}}
RFM 细分筛选：{{rfm_segment}}
目标 destination：{{destination_id}}

- 从 {{cohort_id}} 中取 monetary 分数前 10%
- 与 {{rfm_segment}} 取交集（例如 champions、loyal、at_risk）
- 带 provenance trace 物化受众（哪些事件让每个人达到资格）
- 同步到 {{destination_id}}（Meta CAPI / Google Ads / webhook）
- 在切换为 live 之前，给我 eligible 与 pushed 的对比数 + 5 个样本成员。

#M24#audience#rfm

AI 层 · P2Growth

行为型受众（最近 30 天活跃）

构建行为型 M24 受众模板：

触发事件：{{event_key}}
回溯窗口：{{lookback_days}} 天
属性筛选：{{property_filters}}

示例：最近 {{lookback_days}} 天内触发 {{event_key}} 且满足 {{property_filters}} 的人（例如 plan=pro AND completed_onboarding=true）。

- 输出：M24 builder 可直接使用的受众定义 JSON
- 估算受众规模 + 3 种 lookalike 扩展策略
- 推荐最适合的 destination 类型（paid retargeting vs lifecycle email）
- 标注同步前需应用的 consent 或 GCM v2 约束。

#M24#audience#behavior

MCP-readyFounder

面向 CSM outreach 的 B2B 账号级受众

@gurulu 为 CSM / enterprise outreach 构建账号级 M24 受众：

账号 ID 列表：{{account_id_list}}
Tier 筛选：{{tier_filter}}

- 通过 workspace 的 company identifier 把 person 汇总到 account
- 按 {{tier_filter}}（例如 enterprise、mid-market）过滤
- 每个 account 输出健康信号（last login、MAU 趋势、support ticket volume）
- 如有 CSM owner 字段则按其分组
- 输出：CSV 就绪的表格 + 适合 Slack 的 CSM 团队简报。

#M24#audience#b2b

AI 层 · P2Developer

Churn-risk 受众自动化

构建在 engagement 下降时触发的 churn-risk M24 受众自动化：

下降指标：{{declining_metric}}
阈值：{{threshold}}
通知 webhook：{{webhook_url}}

- 按 person 对比 {{declining_metric}} 最近 7 天 vs 前 7 天
- 当下降超过 {{threshold}}（例如 -50%）时加入受众
- 成员变动时，用 HMAC 签名 POST 到 {{webhook_url}}
- 指标回到阈值之上时自动移除
- 保险栅：受众规模超过 MAU 的 5% 时自动暂停。

#M24#audience#churn

MCP-readyMarketer

Meta CAPI 首次接入分步指南

@gurulu 从零接入 M25 Meta CAPI destination：

Pixel ID：{{pixel_id}}
Access token：{{access_token}}
目标受众：{{audience_id}}

1. 用 Marketing API 校验 {{access_token}} + 确认 pixel 所有权
2. 把我们的 outcome 事件映射到 Meta 标准事件（Purchase、Lead、CompleteRegistration）
3. 配置 deduplication（event_id + event_time + fbp/fbc）
4. 从 sandbox 发送 3 条测试事件，并在 Events Manager 中确认
5. 将 {{audience_id}} 同步切到 live，并给出第一小时的 match rate。

#M25#destinations#meta

MCP-readyGrowth

Google Ads OAuth + Customer Match 接入

@gurulu 配置一个 M25 Google Ads Customer Match destination：

Customer ID：{{customer_id}}
User list ID：{{user_list_id}}
Developer token：{{developer_token}}

- 跑 OAuth 流程并保存 refresh token
- 确认 {{customer_id}} 的访问级别（standard vs basic）
- 上传前对 PII（email、phone）做 SHA-256 + 规范化哈希
- 将首批数据推送到 {{user_list_id}}，按 identifier 类型报告 match rate
- 每 6 小时调度一次增量同步；当 match rate 低于 40% 触发告警。

#M25#destinations#google-ads

AI 层 · P2Developer

带 HMAC 模式的 Webhook 接入

生成一个带 HMAC 校验的 M25 webhook destination：

Webhook URL：{{webhook_url}}
Shared secret：{{secret}}
Payload 结构：{{payload_shape}}

- 每个 POST 用 `HMAC-SHA256(secret, body)` 签名，放入 `X-Gurulu-Signature` 头
- 添加 `X-Gurulu-Timestamp`（Unix ms），拒绝超过 5 分钟的 replay
- 按接收方期望的 {{payload_shape}} 适配
- Retry：5 次指数退避（1s、5s、30s、2m、10m）
- 5 次仍失败则进入 dead-letter，并通知 workspace 所有者。

#M25#destinations#webhook

MCP-readyFounder

Audience 到 destination 的链接最佳实践

@gurulu 干净地把 M24 受众链接到 M25 destination：

受众：{{audience_id}}
Destination 类型：{{destination_kind}}
同步频率：{{sync_frequency}}

- 为 {{destination_kind}} 选合适的节奏：realtime CAPI vs hourly batch vs daily CSV
- 映射 provenance：让 qualify 的事件保留在同步行上
- 设置 rate-limit 保险栅（不要超出 destination 的日配额）
- 加监控：同步延迟 > 2x {{sync_frequency}} 或错误率 > 2% 时告警
- 写下 tear-down 计划，便于事故时干净断开。

#M25#destinations#sync

AI 层 · P2Marketer

按你的行业定制 morning summary

为 {{sector}} 定制 M27 morning summary：

行业：{{sector}}（例如 ecommerce、saas、gambling、media、finance）
关注指标：{{focus_metrics}}
语气：{{tone}}（例如 terminal、plain、friendly）

- 用 {{focus_metrics}} 替换泛用的 'sessions / signups'
- 按 {{sector}} 运营者期望的方式格式化数字（GMV vs ARR vs handle/hold）
- 以一个值得反应的 anomaly 开头，以一个值得追问的问题结尾
- 保持 {{tone}} 语气，无营销修饰、无含糊措辞
- 把定制后的 summary 设为 workspace 默认。

#M27#ai-layer#summary

AI 层 · P2Developer

Anomaly 调查工作流

@gurulu 端到端排查这次 M27 anomaly：

Alert ID：{{alert_id}}
Event key：{{event_key}}
Severity：{{severity}}

1. 取 {{event_key}} 的 baseline window 与 anomalous window
2. 按 source × campaign × device × geo 分解，找出最大贡献者
3. 与同时段的 deploy、registry 变更、destination 错误做相关分析
4. 排除数据质量问题（quarantine 飙升？dedup miss？identity merge 浪潮？）
5. 给出排序后的 3 个假设 + 每个假设 2 条 SQL 校验语句
6. 按 {{severity}} 推荐动作（info → log，warn → review，critical → on-call page）。

#M27#ai-layer#anomaly

MCP-readyFounder

AI 成本优化（chain provider 调优）

@gurulu 把 M27 ai-layer chain 调到月度预算内：

月度预算：{{monthly_budget}}
Provider 偏好：{{provider_preference}}（例如 minimax_first、bedrock_first、cheapest_first）

- 对最近 30 天做画像：按 prompt 类型拆解成本（summary、anomaly、copy、codegen）
- 找出哪些 prompt 类可下沉到便宜的 provider 而不损失质量
- 为每个类配置 cache hit 目标（summary 上 ≥ 60%）
- 按 {{provider_preference}} 重排 fallback chain
- 输出对比 {{monthly_budget}} 的月度成本预测 + 暂停非关键任务的硬上限。

#M27#ai-layer#cost

AI 层 · P2Growth

多语言 summary prompt

为 {{audience}} 用 {{language}} 生成 M27 summary：

目标语言：{{language}}（例如 tr、en、zh、ar）
Audience：{{audience}}（例如 founder、marketer、finance team）
Persona 声音：{{persona_voice}}（例如 analyst、coach、terminal）

- 直接用 {{language}} 原生书写，不要从英文翻译（避免生硬 calque）
- 匹配 {{audience}} 的指标素养（对 finance team 不用术语，对 analyst 可以深入）
- 整篇 summary 保持 {{persona_voice}}
- 对 RTL 语言（ar），把数字包在 LTR isolate 里以保持顺序
- 用目标语言的祈使句给出一条 action。

#M27#ai-layer#i18n

MCP-readyFounder

Partner 申请 + Stripe Connect onboarding

@gurulu Onboard 一个新的 M43 affiliate partner：

Partner 类型：{{partner_type}}（例如 agency、creator、community、integrator）
预计月度量级：{{expected_volume}}

- 审核申请并标注合规风险（受制裁地区、利益冲突）
- 开 Stripe Connect Express 账号（KYC + payout currency）
- 生成 partner 的 referral slug + dashboard 凭据
- 根据 {{partner_type}} + {{expected_volume}} 选择起始 commission tier
- 发送含 3 个模板的欢迎消息：blog、X thread、podcast plug-in。

#M43#affiliate#stripe

AI 层 · P2Marketer

Referral tracking + UTM 策略

设计 M43 referral + UTM tracking 方案：

Campaign：{{utm_campaign}}
Landing path：{{landing_path}}
Referral slug：{{slug}}

- 搭建 canonical 链接：gurulu.io{{landing_path}}?ref={{slug}}&utm_source=affiliate&utm_medium=referral&utm_campaign={{utm_campaign}}
- 把 `ref` 写入 first-party cookie，30 天（consent-aware）
- 即便 UTM 在 funnel 中途丢失，也把 conversion 归因到 slug
- 每个 partner 出一份 dashboard：click、signup、paid conversion、MRR 贡献
- 给出 3 条 UTM 卫生规则，避免 partner 互相覆盖。

#M43#affiliate#utm

MCP-readyFounder

Payout 优化 & tier 管理

@gurulu 为 partner {{partner_id}} 优化 payout + tier：

Partner：{{partner_id}}
累计 MRR 贡献：{{cumulative_mrr}}
Tier override %：{{tier_override_pct}}

- 从 M43 ledger + 默认 schedule（20% / 25% / 30%）读取当前 tier
- 如果 {{cumulative_mrr}} 越过下一档阈值，下个月 payout 升档
- 若有 {{tier_override_pct}} 则覆盖（例如 strategic partner 的定制条款）
- 给出当前 vs 新 tier 的下月 payout 预测
- 注明 clawback 风险（refund、在 protection window 内 churn 的客户）。

#M43#affiliate#payout

AI 层 · P2Developer

多页 pattern 检测工作流

@gurulu 用 M13 F2.3 crawler 在多页面上检测重复 selector：

Base selector：{{base_selector}}
URL pattern：{{url_pattern}}
最大页面数：{{max_pages}}

- 抓取最多 {{max_pages}} 个匹配 {{url_pattern}} 的 URL（尊重 robots.txt + rate limit）
- 在每个页面上定位匹配 {{base_selector}} 的元素，并捕获稳定属性
- 聚类 selector 变体，选出最稳健的一个（data-testid > role > class chain）
- 提议一条 registry rule，统一在所有匹配 URL 上触发
- 输出覆盖报告：每页 hit % + 保存规则前需要复查的 5 个 outlier。

#M13#F2#crawler

MCP-readyGrowth

贝叶斯 A/B 结果解读

@gurulu 用贝叶斯方式解读实验 "{{experiment_key}}"（M30）：

- 为每个变体推导后验 Beta(1+conversions, 1+misses)
- 计算 P(variant > control) 与 expected loss
- 给出 95% 可信区间（不是 frequentist p-value）
- 是否达到最小样本量，是否存在 peeking 风险
- 决策：ship / kill / 继续 —— 用 MC 采样置信度解释

#M30#experiment#bayesian

MCP-readyGrowth

假设 → registry outcome 映射

@gurulu 把新实验的假设绑定到 registry：

假设：{{hypothesis}}
变体：{{variants}}

- 为 primary_metric_event_key 推荐一个现有的 registry outcome 事件（不要臆造名称）
- 校验该 outcome 是否 verified（M12 后端），否则告警
- 提醒 exposure 事件 = experiment_exposed（Interaction，系统种子）
- 确定性分配：hash(experiment_key+uid)%10000 —— uid = person_id ∥ anonymous_id
- 若缺少 registry 契约，先建议 'gurulu push'

#M30#experiment#registry

MCP-readyDeveloper

解释 SRM 告警

@gurulu 解释实验 "{{experiment_key}}" 的 SRM（样本比例失衡）告警：

期望权重：{{expected_weights}}
观测曝光：{{observed_counts}}

- 用卡方检验对比期望与观测的分流
- SRM 是真实的还是噪声（阈值 p<0.001）
- 可能原因：机器人流量、分配 bug、重定向丢失、延迟曝光
- 结果是否可信 —— 若存在 SRM，警告不要解读结果
- 给出修复步骤

#M30#experiment#srm

AI 层 · P2Marketer

生成弹窗内容变体

@gurulu 为 M31 弹窗生成 {{n_variants}} 个内容变体：

目标分群：{{audience}}
目标：{{goal}}（例如 邮箱采集、购物车挽回）
类型：{{popup_type}}（modal / banner / slide-in）

每个变体：标题、正文、cta_label、cta_url 占位。
- 建议触发方式（exit_intent / scroll / delay）
- 建议 frequency_cap（每人/天）
- 提醒无营销 consent 不可展示（M4）
- 内容在服务端清洗（allow-list HTML）—— 不要放 script/内联处理器

#M31#activation#popup

AI 层 · P2Growth

设计引导步骤

@gurulu 为 M32 引导设计步骤序列：

激活目标：{{activation_goal}}
薄弱漏斗步骤：{{weak_step}}

每步：selector、title、body、placement、advance_on（click/event/next）。
- 首次会话自动触发，还是手动 gurulu.tour.start(key)
- 进度存于服务端（跨设备）—— 提示
- 说明通过 tour_step_completed Interaction 事件度量步骤流失
- 不要超过 3-5 步（完成率会下降）

#M32#activation#tour

MCP-readyGrowth

Personalization 规则 + holdout

@gurulu 配置 M33 personalization 规则：

Slot：{{slot_key}}
Audience → 内容映射：{{rules}}
Holdout：{{holdout_percent}}%

- 为重叠 audience 建议 priority 顺序（首匹配胜出）
- 定义 default_content（无匹配 / holdout 组）
- 若 holdout_percent > 0，效果用 M30 贝叶斯增益度量 —— 解释
- 分配 mode 标记 = personalize（确定性），而非 measure（M30）
- 通过 personalization_served Interaction 事件跟踪 serve/conversion

#M33#activation#holdout

MCP-readyFounder

用 insight 组合看板

@gurulu 用现有 insight 组合自定义看板：

我想回答的问题：{{question}}
受众：{{viewer}}（例如 founder、growth）

- 需要哪些 widget（kpi / timeseries / breakdown / funnel / retention / table）
- 每个 widget 的 query_config = 现有端点参数（无新指标引擎）
- 建议网格布局（x/y/w/h）
- visibility = private 或 workspace
- 看板 widget 调用现有 /v1/insights、/v1/funnels、/v1/retention —— 无需新后端

#boards#dashboard

MCP-readyMarketer

共享看板模板

@gurulu 为团队推荐共享看板模板：

角色：{{role}}（例如 营销周报、founder 日报）
行业：{{sector}}

- 定义 visibility = workspace 的标准 widget 集
- 给出每个 widget 标题 + query_config（现有端点）
- 哪些指标驱动该角色决策，省略什么
- 为新成员准备合理的默认布局
- 说明看板能否被个人克隆

#boards#template

MCP-readyFounder

AI 成本优化（M46）

@gurulu 用 M46 LLM Analytics 优化我自己 AI 功能的成本：

时间范围：{{date_range}}
月度 AI 预算：{{monthly_budget}}

- 从 llm_request 事件按 provider × model × operation 拆解成本
- 哪类调用最贵（tokens × 价格映射）
- 建议可降到更便宜模型的操作（不损失质量）
- 提醒：若缺 cost，则由 model→价格映射推导
- 对照预算做预测 + 节省优先级

#M46#llm#cost

MCP-readyDeveloper

模型延迟/错误排查

@gurulu 在 M46 LLM Analytics 中排查模型延迟 + 错误：

模型：{{model}}
时间范围：{{date_range}}

- 拆解 llm_request status：success / error / timeout / rate_limited 比例
- latency_ms p50/p95/p99 —— 哪个 operation 慢
- 错误/超时上升是否绑定到特定 provider 或 model
- 若 rate_limited 飙升，建议配额/退避
- 影响：这种延迟破坏了哪个 outcome 漏斗（复用 identity）

#M46#llm#latency

AI 层 · P2Developer

LLM 错误根因分析

@gurulu 分析最近 {{lookback}} 内 LLM 错误的根因：

- 分组 status=error/timeout/rate_limited 的 llm_request
- 找出共同维度：provider、model、operation、部署时间
- 错误率是否与某次 release/时间窗相关
- 内容默认关闭（仅 metadata）—— 做无 PII 分析
- 排序可能原因 + 修复（重试、换模型、改 prompt）

#M46#llm#errors

AI 层 · P2Developer

OTel SDK 接入

@gurulu 用 OTLP 把我的服务接入 Gurulu observability：

语言/框架：{{stack}}
服务名：{{service_name}}

- 展示标准 OpenTelemetry SDK 接入（无 vendor lock —— Gurulu = OTLP 端点）
- 将 OTLP exporter 指向 /v1/otlp/v1/{traces,logs,metrics} HTTP
- 用 workspace OTLP token 作为 auth header
- 添加 tenant/workspace 资源属性（Universe gate K15）
- 采样建议：小服务 head 100%，大服务 tail-sampling

#observability#otel#setup

AI 层 · P2Developer

日志/链路查询

@gurulu 在 observability 中用日志 + 链路排查一次事件：

症状：{{symptom}}
时间范围：{{time_range}}
服务：{{service_name}}

- 在 otel_logs 过滤 severity=error，在 body 中检索
- 找到相关 trace_id，构建 otel_traces 瀑布
- 在 service_map 中，哪个 caller→callee 慢/出错
- 该错误是否与产品事件/漏斗处于同一 identity 图（关联）
- 是否在 hot/warm 保留期内，否则告警 cold S3

#observability#logs#traces