competitor-alerts（竞争对手警报）

/dm:competitor-alerts

Purpose

Configure an intelligent competitor alert system that surfaces competitive changes worth knowing about while actively managing alert fatigue. Define what types of competitive changes should trigger notifications, at what significance thresholds, for which competitors, through which channels, and at what urgency tier. Competitive monitoring generates a high volume of raw change signals — most are noise that does not warrant human attention. This command transforms raw change detection into actionable competitive intelligence by applying tiered urgency rules, smart thresholds calibrated to each dimension's natural volatility, and digest batching that groups lower-priority changes into periodic summaries rather than individual pings. The result is a competitor alert pipeline that reliably surfaces high-impact competitive moves in real-time while packaging routine competitive activity into digestible periodic briefings that maintain awareness without disruption. Supports per-competitor and per-dimension alert customization so the user can watch a primary rival more closely with tighter thresholds while applying lighter monitoring to secondary and emerging competitors.

Input Required

The user must provide (or will be prompted for):

• Competitors to monitor: Which tracked competitors should have alerts enabled — can be all currently monitored competitors from competitor-monitor or a specific subset. Each competitor can have fully independent alert configurations, allowing tighter trigger thresholds and higher default urgency for primary rivals versus secondary competitors. Competitors must have existing baselines from competitor-monitor to enable meaningful change detection; if any requested competitors lack baselines, the user is prompted to run competitor-monitor first to establish the reference state
• Alert types to enable: Which competitive change categories to monitor — content (new pages published, significant edits to key pages, messaging or value proposition changes), pricing (any pricing page change, plan restructuring, new discount offers or promotions, free trial modifications), ads (new campaign launches in Google Ads or Meta, major creative rotations, new advertising platform presence), social (mention volume spikes, sentiment shifts, viral content, significant follower growth), ranking (organic position changes on tracked keywords beyond the configured threshold), serp (featured snippet ownership changes, People Also Ask presence shifts, knowledge panel updates, AI overview citation changes), positioning (correlated changes across multiple dimensions suggesting a deliberate strategic shift). Select all for comprehensive alerting or choose specific types per competitor based on competitive priorities
• Urgency tiers per alert type: Assignment of each enabled alert type to an urgency tier — critical (immediate real-time notification for high-impact competitive moves demanding fast response), warning (batched into daily digest for notable but non-urgent changes requiring awareness), or info (collected into weekly digest for background intelligence and pattern recognition). If not specified by the user, defaults are applied based on typical competitive impact patterns and dimension sensitivity
• Notification channel: Where to deliver alerts — Slack channel name (e.g., #competitor-alerts, #marketing-intel, #urgent-competitive) or email address. Supports specifying different channels per urgency tier for intelligent routing — e.g., critical alerts to #urgent-alerts with @channel mention for immediate visibility, warning alerts to #competitor-daily for morning review, and info alerts bundled into the #competitor-weekly digest. For Slack delivery, requires the Slack MCP server to be connected with posting permissions on the target channels
• Alert mode: Delivery timing preference per urgency tier — real-time (alerts sent immediately upon change detection, best suited for critical-tier alerts only), daily-digest (all alerts of the tier batched and delivered once per day at a specified time, typically morning), or weekly-digest (all alerts batched into a comprehensive weekly competitive intelligence briefing). Recommended configuration mixes modes by tier — critical alerts in real-time for immediate competitive response, warning alerts in daily digest for daily planning context, info alerts in weekly digest for strategic awareness
• Custom thresholds (optional): Override the default change significance thresholds per alert type to tune sensitivity — e.g., "alert on ranking changes greater than 3 positions instead of the default 5", "trigger social alerts at 1.5x baseline mention volume instead of 2x", "alert on any content change to competitor homepages and pricing pages, not just significant edits", "lower ad alert threshold to include creative refreshes not just new campaigns". Allows fine-tuning based on competitive intensity, industry pace, and the user's tolerance for alert volume versus comprehensiveness

Process

1. Load brand context and existing competitor monitoring configuration: Read ~/.claude-marketing/brands/_active-brand.json for the active slug, then load ~/.claude-marketing/brands/{slug}/profile.json. Apply brand competitive landscape context, industry vertical, and target market definitions. Load existing competitor monitoring data from competitor-tracker.py — competitor profiles with current baselines, scan schedules with frequencies, historical change logs, and any previously configured alert rules that may need updating rather than creating from scratch. Verify that all requested competitors have active baselines with recent data; if any lack baselines, prompt the user to run competitor-monitor first to establish the reference state required for meaningful change detection. Check for agency SOPs at ~/.claude-marketing/sops/.
2. Configure alert rules per alert type: For each enabled alert type, define the specific trigger conditions that constitute a change worth alerting on, calibrated to filter noise while catching meaningful competitive signals. Content alerts: new page published on the competitor's site or significant edit to a key page (homepage, pricing, product, about, landing pages) detected via content diff where similarity drops below the threshold, filtering out minor copy corrections and formatting changes while catching messaging pivots, new feature announcements, and positioning shifts. Pricing alerts: any detectable change to pricing page content including plan names, price points, feature lists, tier structure, or promotional offers — pricing changes are binary-sensitive so any modification is considered alert-worthy. Ad alerts: new campaign detected in Google Ads Transparency Center or Meta Ad Library, or major creative rotation where more than 50% of active creatives in a campaign are new within the scan window. Social alerts: mention volume exceeding 2x the rolling 30-day baseline average indicating unusual buzz, or sentiment score shifting more than 0.3 points on a normalized -1 to 1 scale suggesting a reputation event. Ranking alerts: organic position change exceeding 5 positions (configurable via custom thresholds) on any tracked keyword, with separate sensitivity for page 1 losses versus deep ranking fluctuations. SERP alerts: featured snippet, knowledge panel, or People Also Ask ownership change on tracked keywords where the brand or a competitor gains or loses a SERP feature. Positioning alerts: correlated changes detected across two or more dimensions within a 7-day window suggesting a coordinated strategic move — e.g., new landing page plus new ad campaign plus messaging change on the homepage.
3. Set urgency tiers: Assign each alert type to the user-specified or default urgency tier with corresponding delivery behavior and formatting. Critical tier — default for pricing changes, major positioning shifts, and page 1 ranking losses to a direct competitor: real-time Slack alert with @channel mention, red urgency sidebar, competitor name and change summary prominently displayed, baseline-versus-current comparison data, and recommended immediate response action. Warning tier — default for new content publication, new ad campaigns detected, ranking drops below the critical threshold, and moderate social mention spikes: batched into a daily digest sent at the configured time (default 8am local), yellow indicator, summary context with trend direction, and priority ranking within the digest based on competitive impact. Info tier — default for minor content updates, incremental ranking movements, social mention fluctuations within normal range, and routine competitive activity: collected into a weekly digest, neutral formatting, included primarily for pattern recognition and long-term competitive awareness rather than requiring any immediate action.
4. Configure notification routing: Map each urgency tier to its specific delivery channel, formatting template, and interaction behavior. For Slack: specify the target channel per urgency tier, mention behavior (@channel for critical to ensure immediate team visibility, no automatic mentions for warning and info to avoid fatigue), message formatting using Slack Block Kit with urgency-colored sidebar indicators, competitor name and logo as the header, structured change summary with before/after comparison, baseline reference data, and recommended next action as a call-to-action block. Thread behavior: critical alerts posted as top-level messages for maximum visibility, warning and info alerts posted as threaded replies under a daily or weekly digest parent message to keep the channel organized. For email: specify recipient list per tier, subject line format with urgency prefix tag (URGENT/HEADS UP/FYI), and HTML email template with change details, visual diff where applicable, and competitive context.
5. Set alert fatigue guardrails: Configure volume limits, adaptive urgency rules, and cool-down mechanisms to prevent notification overload during periods of high competitive activity. Maximum alerts per urgency tier per 24-hour window — default caps at 3 critical alerts, 10 warning alerts, and unlimited info alerts (info alerts are batched into digests regardless so volume is inherently managed). Auto-downgrade rule: if more than 3 alerts of the same alert type for the same competitor trigger within a 24-hour window, automatically downgrade subsequent alerts one urgency tier (critical becomes warning, warning becomes info) to prevent a single hyperactive competitor from monopolizing the alert channel — the downgrade is noted in the alert so the user understands why urgency was reduced. Cool-down period: after a critical alert fires for a specific competitor and dimension, suppress duplicate critical alerts for that same competitor-dimension pair for a configurable cool-down window (default 4 hours) — subsequent changes within the window are appended to the original alert's Slack thread rather than generating new top-level notifications, keeping related updates grouped. Include a weekly alert volume report in the weekly digest showing total alerts fired by type and urgency, auto-downgrade events, cool-down suppressions, and fatigue trend metrics to help the user tune thresholds over time.
6. Save alert configuration via competitor-tracker.py: Execute competitor-tracker.py to persist the complete alert configuration — per-competitor alert type assignments with enabled/disabled state, trigger conditions with specific thresholds per alert type, urgency tier mappings with delivery behavior specifications, notification channel routing per tier with formatting preferences, delivery mode settings (real-time/daily/weekly per tier), digest schedule times, and all fatigue guardrail parameters including volume caps, auto-downgrade rules, and cool-down windows. Configuration is stored per-brand at ~/.claude-marketing/brands/{slug}/competitors/alerts/ so multiple brands can maintain fully independent alert setups even when tracking overlapping competitors with different sensitivity requirements.
7. Send test alert to verify notification pipeline: Generate a synthetic test alert at each configured urgency tier and deliver it through the configured notification channels via send-notification. For each tier: create a clearly labeled test alert with sample competitor change data, deliver to the configured Slack channel or email address, verify successful delivery with confirmation receipt, confirm that formatting renders correctly with the appropriate urgency color indicators, competitor context blocks, and baseline comparison data, and validate that @mentions and thread behavior work as configured. If any delivery fails, report the specific failure reason with actionable remediation steps — missing Slack MCP connection, insufficient bot permissions for the target channel, invalid channel name, or email delivery rejection. Successful test alerts are labeled as tests in the message body so recipients are not confused by simulated competitive changes.

Output

A structured alert configuration summary containing:

• Alert configuration summary: Complete configuration table showing each monitored competitor with their enabled alert types, specific trigger thresholds per type (with custom overrides noted), urgency tier assignments for each alert type, notification channel routing per tier, and delivery mode per tier (real-time, daily digest, weekly digest with schedule times) — the full picture of what is being monitored, how sensitive the triggers are, and exactly where and when alerts will be delivered
• Test alert confirmation: Delivery status for each test alert sent during pipeline verification — urgency tier tested, target channel or email, delivery timestamp, success or failure status with error detail if applicable, and a preview or screenshot of how the formatted alert appears in Slack or email so the user can verify the visual presentation, urgency indicators, competitor context blocks, and action formatting match expectations before real alerts begin flowing
• Estimated alert volume: Projected number of alerts per day and per week based on current competitive activity levels observed in baseline data and recent scan history — broken down by urgency tier (estimated critical alerts per week, warning alerts per day, info items per weekly digest) so the user can assess whether the configured thresholds will produce a manageable and valuable signal volume or whether thresholds need adjustment before going live
• Alert fatigue guardrails configured: Summary of all fatigue management mechanisms in place — volume caps per tier per 24-hour window, auto-downgrade trigger conditions and behavior, cool-down periods between duplicate alerts with thread-append behavior, weekly volume reporting schedule, and threshold adjustment recommendations based on the estimated alert volume projections
• Next steps for ongoing monitoring: Actionable guidance on what happens after configuration — when the first real scans will run based on the monitoring schedule from competitor-monitor, expected timeline for the first real alerts based on competitive activity patterns, how to adjust thresholds after the first week of live alerts based on actual volume and signal quality, how to add new competitors or alert types to the existing configuration, and how to temporarily mute or pause alerts during known noisy periods such as competitor product launches, industry conferences, or seasonal promotional cycles

Agents Used

• competitor-intelligence — Alert rule configuration with dimension-specific trigger condition definition calibrated to each monitoring dimension's signal characteristics and noise profile, threshold calibration using competitive activity baselines and historical volatility patterns per dimension, urgency tier assignment informed by competitive impact assessment frameworks, change significance evaluation with multi-factor criteria that distinguish strategic competitive moves from routine operational changes, positioning shift detection through cross-dimension correlation analysis, and alert fatigue pattern analysis from historical competitive monitoring data to recommend optimal threshold starting points
• execution-coordinator — Notification pipeline setup and end-to-end testing via Slack and email MCP servers including channel permission verification and bot capability validation, delivery channel configuration with per-tier routing and formatting template application using Slack Block Kit and HTML email templates, test alert generation with synthetic competitor change data delivered across all configured urgency tiers for pipeline verification, alert fatigue guardrail implementation with volume tracking counters, auto-downgrade logic, cool-down timers, and thread-append behavior for suppressed duplicates, and execution logging for complete alert delivery audit trail and reliability monitoring across all notification channels