This source did not publish a separate summary. Review SKILL.md before using the skill.
SKILL.md
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:
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.
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:
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:
Use platform_search.py with --dual-window --append-year flags
Step 4.5: AI uses web_search for safety events
Use deep_dive_search.py with --safety-only flag, OR web_search_fallback.py
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
Detect the language of the user's query (Chinese, English, Japanese, Korean, etc.)
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)
ALL subsequent search queries, keywords, and report text MUST match the detected language and region
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):
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.
Data Source Tier
Source
Core Value
Base Credibility Weight
L1 E-commerce Reviews
Platform purchase reviews (indirect)
Real buyers with real money, long-term follow-up reviews
0.85
L2 Comment Sections
Social platform comment sections (indirect)
Real "debunking" feedback on promotional content
0.75
L3 Forum Posts
Community forums (per region)
Enthusiast deep experience, comparisons
Uses platform_relevance
L4 Independent Posts
Q&A platforms, review sites
Systematic review frameworks
Uses platform_relevance
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):
Constraints: 3-6 dimensions, max 0.4 weight per dimension, weights sum to 1.0. Platform weights adjusted per category. [product] placeholders in search_templates are replaced with actual product names during search.
CRITICAL: The regional_platforms, marketing_signals, authenticity_signals, ecommerce_search_strategy, comment_section_strategy, safety_search_config, and report_labels fields are ALL dynamically generated by the AI based on the detected locale. They must be in the user's language and appropriate for the user's region. The scripts will read these from the profile and use them instead of hardcoded defaults.
Step 2: Multi-layer Data Source Search (with E-commerce + Comment Section + Result Adaptation)
Search in 3 tiers from highest to lowest data source priority, ensuring high-value sources get priority coverage.
Step 2a: E-commerce Review Indirect Search (L1, ≥15% of total)
E-commerce platform reviews are dynamically loaded — search engines cannot directly index them. Use indirect strategies from ecommerce_search_strategy.search_templates.
Tag results with source_layer: "L1_ecommerce", base_weight: 0.85.
Step 2b: Social Comment Section Indirect Search (L2, ≥15% of total)
Search for real "debunking" feedback in comment sections. Use templates from comment_section_strategy.search_templates.
Tag results with source_layer: "L2_comment_section", base_weight: 0.75.
Step 2c: Forum Post + Independent Post Search (L3/L4, ≤70% of total)
Full mode: Use web_search + site: for targeted searches on platforms from regional_platforms.
Fallback mode: Use python scripts/platform_search.py or python scripts/web_search_fallback.py --site [domain] instead.
For each candidate brand, search for safety events across the web. Two-tier classification: general layer (recall/death/removal) + category layer (safety_risk_types). Use keywords from safety_search_config.
The report MUST be written in the user's language (as specified by category_profile.language). All section headers, verdicts, labels, and analysis text must match the user's language.
Key Rules (Non-skippable)
Confirm requirements before searching — Budget, category, and use case are all mandatory; ask user if any are missing
Never assume user needs — If user says "recommend a phone" without budget or use case, ask first
Generate category_profile before searching — It is the foundation for all subsequent steps
Search twice — After broad search, always do targeted negative deep dive on high-frequency models
Append year to searches — Include current year and previous year
Negative search ratio ≥40% — Actively search for negatives; finding none means search depth is insufficient
Safety events MUST be searched — Top recommended brands must pass safety event screening
Adapt search results — Expand when insufficient, trim when excessive
High-engagement content needs scrutiny — High upvotes/likes ≠ authenticity (applies to Zhihu, Reddit, etc.)
Prioritize long-term feedback — "Used for 2 years" is 10x more valuable than "just bought, looks great"
Cross-validation is core — Commercial review says good + niche forum complains → trust the latter
Profile is the sole category knowledge source — Script hardcoded values are only fallback
E-commerce review layer is mandatory — Every research must include e-commerce review indirect search (L1), ≥15% of total
Comment section layer is mandatory — Every research must include social comment section search (L2), ≥15% of total
Follow-up reviews > unboxing — Long-term follow-up reviews (3+ months) are far more valuable than unboxing reviews
Comment sections > post body — Real "debunking" feedback in comment sections takes priority over the post's own conclusions
Match user's language throughout — ALL search queries, scoring labels, and the final report MUST be in the user's language
