SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillssuper-search

super-search

Writing & research

View repository

Updated 10-15 17:31

About this skill

Super Search

IRON LAW: NEVER GENERATE ANSWERS FROM TRAINING DATA. Every factual claim in the report must be traceable to at least one URL fetched during this session.

Core Positioning

General-purpose web research and fact-checking tool. Key differences from hv-analysis(mandatory vertical and horizontal axis framework, producing a 10K-30K word PDF deep product/company research):

hv-analysis Super Search
Research Framework Vertical axis + horizontal axis + cross-insights (mandatory) No preset framework, flexible as needed
Scope of Application Products/companies/concepts/people Any topic
Report Depth 10K-30K word PDF Lightweight to medium, as needed
Adversarial Review Encourages critical thinking (not systematized) Universal for all topics: dual review of timeliness + authenticity
Cache None Built-in TTL cache layer

Workflow

⚡ Fast Path (90% of searches use this path)

Most searches do not need the full 9-step process. Actual execution mode:

加载 skill → 领域探测(references/domain-detector.md) → 3-4 并行搜索 → 1-2 并行抓取 → 手动写报告 → 飞书发送

Scripts (env-check/search/fetch/analyze/report/review) run only in deep mode or when caching is needed.

Full Deep Path (when finance/medical/legal or 2+ domain detectors hit)

Copy this checklist and check off items as you complete them:

Super Search Progress:

  • Step 0: Domain Detect ⚠️ REQUIRED — Answer 5 domain detector questions to determine verification depth
  • Step 1: Environment Check — Run only in deep mode node dist/env-check.mjs
  • Step 2: Plan — Parse user intent, expand multilingual keywords, determine search depth
  • Step 3: Search — Multi-source search, collect result URLs
  • Step 4: Fetch — Batch crawl content, check cache first
  • Step 5: Analyze — Quality scoring (reference only, discard low-quality), sort and organize
  • Step 6: Cross-Reference — Multi-source comparison, flag contradictions
  • Step 7: Review ⚠️ REQUIRED — Dual review of timeliness + authenticity for all key data
  • Step 7.5: Template Selection ⚠️ REQUIRED — Select report template based on topic characteristics
  • Step 8: Report — Generate a structured report according to the selected template and write it to a file
  • Step 9: Verify — Pre-delivery check

Step 0: Domain Detect ⚠️ REQUIRED — Mandatory decision gate before entering search

Answer the following 5 questions to determine search depth and verification strategy (see references/domain-detector.md）：

# Detector Question Hit Keywords Mandatory Action After Hit
Q1 Involves GitHub/open-source projects? github, open-source project, repo, star, fork Fetch the original repo to confirm ⭐/license/activity + scan Issues
Q2 Involves finance/investment/money? finance, stocks, investment, funds, trading, pricing Full adversarial review + risk matrix + disclaimer
Q3 Involves medicine/law/security? medicine, medical, law, security vulnerability, vulnerability Full adversarial review + confidence annotation
Q4 Involves product/tool/competitor comparison? comparison, compare, which is better, ranking, recommendation, selection, vs, competitor, alternative, why choose, migrate Official page comparison scraping + tool comparison → Trigger security audit investigation（references/competitive-analysis.md）
Q5 Time-sensitivity sensitive? latest, 2026, recent, latest, trending Annotate all data dates + June expiration warning

Before entering Step 3 search, must output decision JSON:

{
  "topic": "用户搜索主题",
  "domains": ["github", "ai"],
  "triggers_fired": ["github-verification"],
  "depth": "normal",
  "multi_language": ["en"],
  "counter_queries": ["...反面搜索词..."],
  "verification_actions": ["抓取所有引用 GitHub repo", "标注 ⭐ 获取日期"],
  "source_priority": "github-projects"
}

source_priority Automatically match based on domains references/source-priority.md the corresponding high-priority source table for the field, prioritize obtaining from these sources when searching.

Deep mapping: 0 hits → Quick | 1 hit (non-financial) → Normal | financial hit or 2+ → Deep

⚠️ Must not enter Step 3 search before outputting decision JSON.

Step 1: Environment Check

Only runs in Deep mode. Normal/Quick mode directly uses available tools.

Iron rule of tool availability: Record the complete list of all available tools (such as tinyfish-search_search, webfetch, etc.). Each subsequent search/scrape operation prioritizes the primary tool; on failure, switch to the next tool in the list in order until successful or all have been tried.

Step 2: Plan

Parse user input, determine:

  • Core topic and search keywords
  • Search depth:quick(3-5 sources),normal(8-12 sources),deep(15-20 sources)
  • Whether adversarial review is needed (see references/review-triggers.md）
  • Source priority: determine the search path according to references/source-priority.md ,search L0-L2 high-priority sources first, then drill down
  • Output file path (user-specified or default ./research-output/{date}-{topic-slug}.md, if the file already exists automatically append -v2/-v3 suffix)
  • Cache directory (user-specified or default ~/.super-search-cache/）

Ask: "For the following question, what opposing/counter/critical keywords should I additionally search for?" For example: when searching for "AI replaces programmers", also search for "reasons why AI will not replace programmers" "limitations of AI programming tools".

Multilingual keyword expansion ⚠️ Must be executed

Identify the field the topic belongs to, infer the possible original information language, and use multilingual keywords to expand the search scope. Expansion rules:

Field Expansion language Description
Tech/AI/Programming + English The main information sources for tech content are in English; most research papers, official documentation, and first-hand materials are first published in English
Anime/ACG/Japanese games + Japanese + English The original source of Japanese anime content is Japanese; using Japanese keywords can obtain first-hand materials (such as official websites, interviews, production team releases); English communities also have a large amount of discussion
Japanese culture/Nintendo/JRPG + Japanese + English Same as above, the original source of Japan-related cultural information is Japanese
Korean pop culture/K-pop + Korean + English The original source of Korean entertainment content is Korean
Other/General + English (minimum) English is the main language of the internet; at least add English search expansion

Expansion strategy：

  • Chinese keywords → translate to target-language keywords (using the built-in terminology mapping table)
  • Add mixed-language queries (e.g. "中文词" site:en.wikipedia.org、"translated topic" Reddit）
  • In deep mode, add academic search dimensions (e.g. "translated topic" research paper、"translated topic" arXiv）
  • For Japanese anime, use dual search with romaji and Japanese kanji

When running node dist/search.mjs --topic '...' --depth normal , the script automatically generates the multiLanguageQueries field. When the AI performs searches, it must execute a search for every type of multilingual query and must not skip any.

Step 3: Search

Number of search entries：

  • quick → per query limit=10
  • normal → per query limit=10, append pagination for key dimensions page=2
  • deep → per query limit=20, pagination page=2, append for academic search page=3

Execute searches according to the plan.Search execution order：

  1. First execute the primary query (thequeries field)
  2. Then execute the multilingual queries (themultiLanguageQueries field),must not be skipped
  3. Finally execute the adversarial queries (thecounterQueries field)

Tool fallback strategy：

  • Prefer the primary search tool (e.g. tinyfish-search_search)
  • If the tool returns an error/times out/returns no results → automatically switch to the next available search tool
  • If all search tools fail → try fetching the search term directly as a URL (e.g. site:xxx search variants), or skip that keyword and record it
  • For each search term, try at least 2 different tools or query variants

Iron rule of data sufficiency: each key dimension (e.g. "price" "specs" "policy") requires coverage from at least 2 sources. If insufficient, immediately triggerSearch engine supplementary discovery—use all available search tools, vary the keywords (adding suffixes such as "comparison" "ranking" "price list" "2026"), and iterate searches until enough data is found or it is confirmed that the dimension truly has no publicly available data. It is forbidden to directly skip a dimension when data is insufficient.

Merging multilingual search results: results returned by searches in different languages are included in the quality analysis process under the same standard; the source authority assessment will consider whether it is the original information language for that field. For example, Japanese official pages have higher authority weight in anime-related topics than Chinese reposted pages.

Search termination conditions

Stop searching and enter the crawling phase when the following conditions are met:

  1. Each key dimension has at least 2 sourcesof coverage, and there are ≥2 source types (see references/source-priority.md）
  2. All official pages have been attempted for crawling (data successfully obtained, or confirmed unobtainable with the reason recorded)
  3. Executed 2 roundsof keyword variant searches, and new results tend to be duplicates (>80% duplicate)
  4. Adversarial searches have been executed for high-risk topics (medical/legal/financial)
  5. GitHub project-type searches → Issues pages of all referenced projects have been crawled (first 2 pages)

Source quality check: before terminating the search, confirm:

  • □ At least 1 first-hand/official source (GitHub repo, official documentation)
  • □ The GitHub projects involved have had their original repo pages crawled (not paraphrases in third-party articles)
  • □ Aggregator/repost sources ≤ 30% of total sources

If not satisfied, continue triggering search engine supplementary discovery; do not skip when data is insufficient.

Step 4: Fetch

Run node dist/fetch.mjs --cache-dir '...' Check the cache.

  • Cache hit → use the cached content directly (node dist/cache.mjs get --url "..." --type fetch）
  • Miss → fetch the content.Tool fallback strategy：
    1. Prefer the primary fetch tool (such as webfetch or tinyfish-search_fetch)
    2. Returns 403/404/Transport Error/JS empty shell → automatically switch to the next available fetch tool
    3. All fetch tools fail → enter the search engine alternative fetching process (see below)
  • After fetchingmust immediatelywrite back to cache:

Default TTL: search results 30min, web page content 24h.

Step 5: Analyze

For each piece of content, tag the quality tier according to references/source-priority.md (🥇/🥈/🥉/4️⃣/⚠️), then score it.

Quality assessment dimensions (see references/quality-criteria.md）：

  • Source authority (official > well-known media > personal blog > untrustworthy; when values/specifications/pricing are involved, official page data must be given priority)
  • Information completeness (date, author, citations, data)
  • Content freshness
  • Language quality (exclude machine translation/low-quality content)

Source tier check：

  • CSDN (csdn.net / blog.csdn.net) must be excluded in all scenarios, must not be included in reports, must not be used as a citation source, and must not be used as a reference link. This is not something only tinyfish MCP can do—web_search、web_extract, RSS collection, and all other entry points must filter out the CSDN domain.
  • Sources at the ⚠️ tier are not included in reports by default, unless information truly cannot be found at the 🥇🥈 tiers

Scoring is only forrelative reference, and content explicitly assessed as low-value is discarded directly.

Step 6: Cross-Reference

Perform multi-source comparison for key facts:

  • Consistent → label "multi-source confirmed"
  • Contradictory → immediately trigger fact-checking: directly fetch the original sources/official pages cited by each party, and adjudicate based on official first-hand data. The consensus of multiple third-party sources cannot override the explicit data on official pages
  • Isolated → mentioned by only one source, label "to be verified", and at the same time try to search official sources to confirm

Comparison standards for third-party reposted data：

  • Third-party data requires at least 2 independent sources for cross-confirmation before it can be labeled "verified"
  • Contradictions among third-party sources cannot be resolved by "majority vote" — you must try to retrieve the original official data
  • Data from only one third-party source is labeled "to be verified (third-party single source)", with a maximum confidence of medium
  • ⚠️ Case data cited in third-party aggregated reports (such as industry white papers/research compilations) is "second-hand retelling" and must be traced back to first-hand sources from the founders before it can be accepted; those for which no first-hand source can be found should be downgraded or deleted

Output a confidence matrix.

Source diversity check(against references/source-priority.md tiers):

  • □ 🥇 first-hand/official sources ≥ 1
  • □ 🥇+🥈 combined ≥ 50% of the total
  • □ ⚠️ aggregated/reposted ≤ 30% of the total
  • □ Not satisfied → trigger supplementary search, prioritizing 🥇 sources

Iron rules of fact-checking: When numerical/specification-type claims are contradictory, you must directly retrieve the official pricing page/specification page as the ultimate basis for adjudication, and must not judge based merely on the number of third-party articles.

Multilingual cross-validation: When multilingual searches return sources in different languages, prioritize the field'soriginal information languageas the basis:

  • Tech/AI → English first-hand materials (research papers, official blogs) authority > Chinese translations/reposts
  • Anime/ACG → Japanese official pages authority > Chinese reposts > English discussions
  • K-pop/Korean wave → Korean official/Korean media authority > Chinese translations/English reports

Step 7: Review ⚠️ REQUIRED (adversarial review)

Review is not an optional add-on, but a necessary step to ensure report quality.Take facts as the first priority; do not sacrifice accuracy for the sake of added speed.

The two dimensions of review：

Timeliness review (common to all topics)

Ask:

  • What is the publication time of each piece of data? How long ago was it?
  • Is there any outdated information older than the "latest" data being cited?
  • Do third-party reposted articles' price/specification data indicate an update date?
  • If key datasource date > 6 months ago, trigger a supplementary search to confirm whether there is a newer version

Authenticity review (common to all topics)

Ask:

  • Can the original source of this claim be traced back to an official page?
  • If the data comes from a third-party repost, does the reposter have an incentive to distort the data (such as promotion commissions/business partnerships)?
  • Are descriptions of the same fact consistent across different sources? When inconsistent, which is more credible?
  • Which claims in this report carry an "isolated source" risk?

Automatically triggered(stricter rebuttal search + official verification):

  • High-risk topics such as medicine, law, finance, and safety
  • GitHub/open-source projects(Step 0 decision gate Q1 hit) — must check Issues + license + activity level
  • Scientific topics such as physics, chemistry, and mathematics (verify from basic principles)
  • Key findings' confidence below threshold
  • Contradictions or isolated claims found in Step 6 cross-validation
  • Claims involving money(pricing, rates, commissions) — must be confirmed by more than two sources

⚠️ Step 0 decision gate output's triggers_fired and verification_actions are the mandatory checklist for review. During review, they must be checked item by item and executed; they cannot be skipped.

Run node dist/review.mjs to perform adversarial review:

  • Search for rebuttal evidence for each main conclusion
  • Check source diversity
  • Flag omission risks
  • If major omissions are found, return to Step 3 for supplementary search

Step 7.5: Template Selection ⚠️ Must be executed before generating the report

Based on the topic characteristics, refer to the references/report-templates.md template selection guideto determine the report template:

Topic characteristics Template Key discriminating basis
Price or feature comparison of multiple products/solutions Comparison-type report Topic contains "comparison/compare/which is better/ranking"
Root cause investigation of issues/errors Diagnostic report Topic contains "error/exception/issue/bug/cause"
Market/track ecosystem research Comparative report(grouped by platform) Topic contains "ecosystem/platform/aggregation/relay"
Simple fact verification Quick summary template Only need to confirm 1-2 facts

After selecting a template, organize the report content according to the template structure.Mixing template structures across types is not allowed，Use of _（请手动填写）_ class placeholders is not allowed。

When researching AI coding subscription plans (Coding Plan): please load references/coding-plan-research.md to get the dedicated workflow, data cross-validation methods, and pitfalls guide. This file covers content not included in model research, such as multi-source pricing confirmation, quota multiplier calculation, and regional price difference handling.

Step 8: Report

Run node dist/report.mjs --output 'path/to/report.md' to generate the report.

The report is written according to the template selected in Step 7.5. For the complete template and writing standards, see references/report-templates.md。

Source link format requirements ⚠️: every key data claim in the report must include a clickable Markdown link pointing to the original source URL. Format:[来源名称](https://...), do not write only the name without a link. This makes it easy for readers to verify with one click.

Step 8.5: Deliver ⚠️ Required reading for Feishu users

For detailed sending methods, see references/feishu-file-delivery.md

Feishu messages do not render Markdown. When delivering the report:

  1. Write the report to the .md file (already completed in Step 8)
  2. Use the send_message tool to send as an attachment:MEDIA:/absolute/path/to/report.md
  3. Keep only a ≤5 line brief summaryin the message body; do not paste the report Markdown body
  4. If the report is very short (<10 lines), it may be output directly in the message; if it exceeds 10 lines, it must be sent as a file

Step 9: Verify

Pre-delivery checklist:

  • The report template matches the topic type (comparative vs diagnostic vs quick summary)
  • Every factual claim in the report has a traceable URL
  • Low-quality sources (scored below the threshold) have been excluded
  • Source diversity meets the standard: ≥1 🥇 (first-hand/official), 🥇+🥈 ≥50%, aggregation ≤30% (see references/source-priority.md）
  • GitHub project-type searches: the first 2 pages of Issues, LICENSE, and last commit date have been fetched for all referenced projects
  • All referenced URLs have passed source credibility checks (high-risk TLDs have been flagged/excluded)
  • Contradictions have been checked against official sources and conclusions have been noted
  • Key numerical/pricing/rate data is confirmed by 2 or more independent sources
  • Timeliness review has passed: the source dates of all data are within the acceptable range
  • The output file has been written to the specified location
  • Feishu users: the report is sent via MEDIA: attachment, and the message body contains only a brief summary
  • Comparison tables/key data prioritize links to official pages rather than third-party articles
  • Competitor comparison scenarios: each competitor's CVE and supply chain security have been checked (references/competitive-analysis.md）
  • Third-party reposted data meets the 2-source cross-check requirement, and the data source type is clearly marked in the report
  • Promotional content has been marked in the source table (⚠️ 推广性质）
  • No _（请手动填写）_ category placeholders

Fact-first principle

  • Prohibit speculation and assumptions: Do not rely on training data to "infer" the user's environment state or existing resources. Check first, then draw conclusions.
  • All key data claims must include a clickable original source URL: Do not merely write names such as "Bessemer" or "arXiv" without providing links. Every factual claim in the report should be traceable to at least one crawled URL.
  • Third-party relayed data must be labeled: If the source is an aggregated report rather than first-hand interview, the report must clearly label it with ⚠️"third-party relay, first-hand source unconfirmed".

Anti-Patterns

Search phase (Step 1-3)

  • Searching directly without checking environment availability
  • Using model training data instead of actual search results
  • Drawing conclusions after looking at only the first search result
  • Giving up after one search/fetch tool fails without trying other available tools
  • Skipping multilingual expanded searches and searching only with monolingual keywords, causing first-hand information sources to be missed
  • Using only Chinese keywords when searching Japanese and Korean content, without adding Japanese/Korean and English searches
  • Taking only 5 search items without paginating, missing key information on subsequent pages
  • Not conducting targeted searches according to source priority, mixing in large amounts of low-quality reposted content

Fetch phase (Step 4)

  • Skipping cache checks and repeatedly fetching the same URL
  • Directly using memories from AI training data to "complete" data when fetching fails
  • When missing data for key dimensions is found, not supplementing the search through search engines and directly marking it as "insufficient information" and letting it pass

Analysis phase (Step 5-6)

  • Claiming in the report that the user "already has X tool/system/configuration" without first checking the actual environment (writing "you already have Miniflux" when no docker is running)
  • Treating quality scores as absolute standards rather than relative references
  • Adopting data after finding only one third-party repost source without multi-source cross-comparison
  • Directly accepting case values in third-party aggregated reports (revenue, user counts, etc.) without tracing them back to first-hand sources
  • Resolving contradictions among third-party sources by "majority vote" rather than tracing back to original official data
  • Citing values from third-party articles without verifying official sources
  • Not fetching official pages for secondary confirmation when cross-validation reveals contradictions
  • Directly marking isolated claims as "to be verified" and letting them pass without supplementary searches
  • Citing low-cost TLD domains such as .cc/.xyz/.top/.tk as official sources without secondary verification
  • Treating content from agents/promotional sites (such as xxx.cc) as equivalent to official information
  • Prioritizing third-party links over official links in comparison tables/details
  • Writing recommendations for open-source project research without checking Issues —— Issues are the most authentic usage feedback
  • Adopting sources uniformly without distinguishing source quality —— 5 CSDN reposts ≠ 5 independent sources; CSDN must be unconditionally excluded
  • Comparing only features and not security in comparison reports —— CVEs, supply chain attack history, and security audits are mandatory check items in competitor comparisons; skipping them equals missing key decision dimensions
  • Using CSDN links in reports — csdn.net / blog.csdn.net / ask.csdn.net domains are all blocked; ignore results from this source, no matter how relevant the title is

Review and Reporting Phase (Step 7-9)

  • Do not trigger adversarial review for medical/legal/financial claims
  • For claims involving pricing/rates/commissions, confirm with only one source
  • Skipping timeliness or authenticity review steps out of concern about "spending too much time checking"
  • Factual claims in the report do not include source URLs
  • Do not label confidence levels for high-rigor topics
  • Report template does not match the topic type (e.g., using a diagnostic template for a comparison-type topic)
  • Leftover in the report _（请手动填写）_ placeholder
  • In the report, only writing the source name without giving a clickable URL (e.g., "Bessemer" without giving a https://... link)
  • Speculating about the user's environment state (e.g., "you already have X") instead of checking the facts first

Output path maintenance notes ⚠️

Default output path ./research-output/{date}-{topic-slug}.md is hardcoded in the following 8 places , and all must be updated in sync when modified:

# File Purpose
1 SKILL.md (Step 2) Description of the default path read by the AI
2 references/report-templates.md (output path rules) Default path in the template document
3 references/competitive-analysis.md Competitive comparison research methodology (CVE/security/ecosystem/migration path analysis)
4 scripts/report.ts Default path + collision detection in the TypeScript source code
5 scripts/pipeline.ts Pipeline instructions in the TypeScript source code
6 dist/report.mjs Default path + collision detection in the compiled JS
7 dist/pipeline.mjs Pipeline instructions in the compiled JS
8 .gitignore Git ignore rules (prohibit workspace/ from entering version control)

Modifying only SKILL.md while omitting code filesThis will cause the AI instructions and script behavior to be inconsistent, and the actual report will still be written to the old path.

For detailed naming conventions, see references/filename-convention.md。

Facts and Sources First Principle

  • Sources are verifiable: Every key data claim in the report must be accompanied by a clickable original source link ([来源](URL) format). It is not acceptable to write only the source name without giving a link. This is a hard requirement for cross-validation in Step 6 and the pre-delivery check in Step 9.
  • Facts and evidence first: It is prohibited to speculate out of thin air that the user "already has X" or to assume an unverified state. All assertions about the user's environment, assets, and capabilities must first check the actual environment before drawing conclusions. Case data in the report must be traced back to first-hand sources (official pages/founder blogs/original interviews); data relayed in third-party aggregated reports must not be directly trusted.

Script design principles

  • Scripts output JSON instructions, and the AI executes the actual search/fetch tool calls
  • Scripts do not directly depend on any specific search/fetch API
  • The cache path can be overridden by the user via --cache-dir override
  • All time-sensitive operations record timestamps