Anti SEO Researcher

Anti-SEO Deep Consumer Researcher

Detailed rules, scoring criteria, and category examples: see references/SKILL_REFERENCE.md

Tool Availability & Graceful Degradation

This skill works best with web_search + web_fetch, but web_search is optional. If your environment does not have web_search available (e.g., no API key configured), the skill will automatically degrade to use built-in Bing scraping scripts instead.

Detection (run at skill startup)

At the very beginning, before any research steps, determine which search mode to use:

1. Full mode (preferred): If web_search tool is available in your environment, use it directly for all search operations as described in the workflow below.
2. Fallback mode: If web_search is NOT available (tool missing, API key not configured, or returns errors), use the built-in fallback script for ALL search operations:

# Instead of: web_search("电竞椅 推荐 避坑 2025")
# Use:
python scripts/web_search_fallback.py "电竞椅 推荐 避坑 2025" --count 10 --days 365

# Instead of: web_search("site:reddit.com office chair review")
# Use:
python scripts/web_search_fallback.py "office chair review" --site reddit.com --count 10

# Multi-site search (searches each site independently):
python scripts/web_search_fallback.py "电竞椅 推荐" --sites zhihu.com,v2ex.com,smzdm.com --count 5

# Search + fetch content in one call (reduces round trips):
python scripts/web_search_fallback.py "电竞椅 避坑" --count 10 --fetch-content --fetch-limit 3

The fallback script uses DuckDuckGo HTML search as the primary engine (most reliable, no captcha), with Bing HTML as automatic fallback — zero API keys needed. It outputs the same JSON format as web_search results.

Fallback Mode Workflow Adjustments

When in fallback mode, apply these adjustments throughout the entire workflow:

Important: web_fetch is STILL used normally in fallback mode for fetching specific page content. Only web_search is replaced.

All other steps (credibility scoring, conflict resolution, brand scoring, report generation) work identically in both modes — they process search results regardless of how those results were obtained.

Architecture Overview

Language Detection → AI Category Adaptation → AI Multi-layer Search (forum posts + e-commerce reviews + social comment sections) → Script Scoring → AI Semantic Analysis → Dynamic Multi-dimensional Scoring → Report

• Language & Region Layer: Detect user's language from query, generate region-specific platform config, search templates, and keyword dictionaries
• Category Layer: AI generates category_profile JSON (evaluation dimensions/weights/pain point keywords/safety risks/platform weights/e-commerce search strategy)
• Search Layer (3-tier data sources):
  • L1 E-commerce Review Layer (highest priority): Indirect search for real buyer reviews (e.g., Amazon reviews, JD follow-up reviews, depending on region)
  • L2 Social Comment Section Layer (second priority): Search for "debunking" feedback in comment sections of promotional posts
  • L3 Forum Post Layer (traditional): AI uses web_search (or web_search_fallback.py when web_search is unavailable) + site: for targeted community searches
• Scoring Layer: credibility_scorer.py (regex pre-filter + category signal injection + data source tier weighting) → ai_credibility_analyzer.py (AI deep analysis for gray zone 30-85 scores)
• Multi-dimensional Scoring: brand_scorer.py (dimensions/weights from profile, safety capping is category-adaptive)
• Report Layer: generate_report.py (dynamic table headers + data source distribution stats, from profile dimension definitions)

Multi-language & Multi-region Adaptation

Core Principle: This tool adapts to any language and region. The AI detects the user's language from their query and generates ALL region-specific configurations dynamically in the category_profile.

Language Detection Rules

1. Detect the language of the user's query (Chinese, English, Japanese, Korean, etc.)
2. Infer the target market/region from context (e.g., Chinese query → China market; English query about "best vacuum" → likely US/UK market; Japanese query → Japan market)
3. ALL subsequent search queries, keywords, and report text MUST match the detected language and region
4. If the user explicitly mentions a region (e.g., "available in the UK", "sold on Amazon Japan"), use that region regardless of query language

Regional Platform Mapping

The AI MUST generate appropriate platform configurations based on the detected region. Below are reference mappings (the AI should adapt these based on actual availability and relevance):

China (zh-CN):

United States / English-speaking (en-US):

Japan (ja-JP):

South Korea (ko-KR):

Europe (various):

Regional Regulatory Authorities

Safety event searches must include the correct regulatory bodies for the target region:

Regional Marketing Signal Adaptation

Each region has different marketing manipulation patterns. The AI MUST generate region-appropriate marketing signals in category_profile:

China: SEO manipulation keywords (e.g., marketing buzzwords, "zhong cao/ba cao" patterns), fake review indicators, WeChat marketing patterns US/UK: Affiliate link indicators, sponsored content disclaimers, Amazon vine/incentivized review patterns, influencer disclosure signals Japan: Stealth marketing (ステマ) indicators, PR article patterns, affiliate blog signals Universal: Excessive superlatives, zero-defect descriptions, brand-official language repetition

Data Source Tier Strategy

Problem: Over-reliance on search-engine-indexable "post-type" content (forum answers, review articles) where the ad-to-content ratio is high. E-commerce platforms' real purchase reviews and social platforms' comment section feedback have higher information density and higher cost of astroturfing, but are dynamically loaded and cannot be directly indexed by search engines.

Solution: Use indirect search strategies (search for "review compilation posts", "follow-up review summaries", "negative review roundups", etc.) to access e-commerce reviews and comment section data.

Key Constraint: E-commerce review layer and comment section layer searches should account for no less than 30% of total search volume.

Workflow (7 Steps)

Step 1: Interactive Requirements Confirmation

Core Principle: Research cannot be interrupted once started (time-consuming and token-intensive), so requirements must be confirmed before starting. Better to ask one more question than to research in the wrong direction.

Mandatory Confirmation Items (MUST ask user if missing):

• Target Category: What does the user want to buy? — Never assume the category
• Budget Range: What is the price range? — Never use a default budget
• Core Use Case or Pain Point: What is the main purpose? What matters most? — Never assume the need

Conditional Confirmation Items (proactively ask when relevant):

• When significant version/channel differences exist (e.g., domestic vs. import versions, regional variants) → confirm variant preference
• When brand preference is apparent → confirm whether to limit to specific brands
• When user needs are ambiguous → use multiple-choice questions to confirm

Confirmation Format: Use short multiple-choice or open questions, max 3 questions.

After confirmation, output task_config (for reference in subsequent steps):

{
  "category": "category name",
  "budget_min": 2500,
  "budget_max": 3500,
  "currency": "USD",
  "locale": "en-US",
  "core_scenario": "gaming",
  "pain_points": ["cooling", "frame rate stability"],
  "excluded_brands": [],
  "preferred_brands": [],
  "variant_preference": "",
  "special_requirements": []
}

Skip confirmation only if ALL conditions are met:

1. Category is clear (e.g., "recommend a $200 gaming keyboard")
2. Budget is clear (has specific numbers or clear range)
3. Use case is clear (e.g., "for gaming", "for my baby")