Prompt gallery
Prompts
promptsPage.hero.subtitle
MCP-ready prompts touch real registry/event data once @gurulu/mcp-server is installed. AI-layer (Phase 2) prompts are on the roadmap — copy them now, be ready.
50 prompts
MCP-readyDeveloper
Add a new event to the registry
@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
Generate a typed event tracker
@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
Debug a missing production event
@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
Write and simulate an attribution policy
@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
Wire contract drift checks into 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
Audit a specific user's consent state
@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
Identity merge — dry-run first
@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 layer · P2Developer
Generate webhook verifier integration tests
@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
Author an anomaly health rule
@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
Spin up a workspace + invite the team
@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 layer · P2Marketer
Weekly channel performance summary
@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
Cross-model attribution comparison
@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
Highest-converting channels & creatives
@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 coverage audit
@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 layer · P2Marketer
Copy variants for the highest-converting flow
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 layer · P2Marketer
Quarterly board slide draft
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 layer · P2Marketer
Explain a traffic drop
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
Landing-page behavior audit
@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
Funnel drop-off analysis
@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
Cohort retention — biggest drop
@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 layer · P2Growth
Find the activation moment in data
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 layer · P2Growth
Turn an observation into an experiment hypothesis
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 layer · P2Growth
Surface a churn signal
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
Build a re-engagement segment
@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
North-star — 90-day trend
@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 layer · P2Growth
A/B test statistical read
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 layer · P2Founder
Morning brief — what happened yesterday
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
Health across all integrations
@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 layer · P2Founder
Outcome-driven revenue summary
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
Data-quality audit
@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
This month vs last month
@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 layer · P2Founder
What changed materially this week
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 layer · P2Founder
Investor update draft
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 layer · P2Founder
Anomaly explanation
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 layer · 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 layer · 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 layer · 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 layer · 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 layer · 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 layer · 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 layer · 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 layer · 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