research-gather

Research Gather — Resource Collection by Domain

Collects academic papers, patents, websites, and business cases for specified research domains and produces structured resource lists. This skill sits between domain mapping (research-clustering) and detailed reports (research-retrieval) in the research pipeline.

Auto Mode (--auto)

When $ARGUMENTS contains --auto, run the entire workflow non-interactively — skip ALL AskUserQuestion calls and use the following defaults:

Collection depth and domain selection are not parameters — every run collects the maximum number of resources across all clusters (see "Collection Scope" below).

In --auto mode, the remaining text in $ARGUMENTS (after removing --auto) is used as the input (file path or keywords). For example: /research-gather --auto research/runs/<domain>/clustering/latest/index.md → input is the clustering result file.

If $ARGUMENTS does NOT contain --auto, proceed with the normal interactive workflow below.

Pipeline Position

research-clustering → research-gather → research-retrieval
(domain mapping)      (resource lists)   (paper deep-dive)

Workflow

Step 1: Parse Input

Determine the input type and extract domain information.

Supported input types:

1. Clustering output file — Markdown file generated by research-clustering. Parse the cluster structure (names, keywords, overview) directly.
2. User keywords/text — Keywords, phrases, or natural-language descriptions provided in conversation. Extract domains and search terms from these.
3. Existing Markdown file — A user-prepared file listing research domains or topics.

For clustering output, detect it by looking for the characteristic structure: "Cluster Summary" table, "Cluster Details" sections with keywords and research strategy. Use the cluster names, keywords, and strategies as the basis for resource collection.

For user keywords/text, group related terms into tentative domains before proceeding. If the grouping is ambiguous, confirm with the user.

Step 2: User Hearing

--auto mode: Skip this entire step. Use the default values from the Auto Mode table above.

Confirm research parameters via AskUserQuestion. Skip hearings for parameters already specified by the user in their request.

Hearing 1: Resource Types

AskUserQuestion:
  question: "どの種類のリソースを収集しますか？（複数選択可）"
  header: "リソース種別"
  multiSelect: true
  options:
    - label: "学術論文"
      description: "arXiv、IEEE、ACM等の学術論文を検索"
    - label: "特許"
      description: "Google Patents、USPTO、J-PlatPat、Espacenet等から検索"
    - label: "技術情報"
      description: "技術ブログ、カンファレンス発表、OSSプロジェクト等"
    - label: "ビジネス事例"
      description: "企業導入事例、市場レポート、業界動向"

Hearing 2: Time Range

AskUserQuestion:
  question: "対象期間を指定してください"
  header: "対象期間"
  multiSelect: false
  options:
    - label: "直近4年（推奨）"
      description: "2022年〜現在の結果を対象"
    - label: "直近2年"
      description: "最新トレンドに絞る"
    - label: "直近7年"
      description: "より広い範囲をカバー"
    - label: "カスタム"
      description: "任意の期間を指定"

If "カスタム" is selected, ask a follow-up for the specific year range.

Step 2.5: Collection Scope (fixed — no hearing)

Collection depth and cluster selection are NOT user choices. Every run uses the maximum scope:

• Depth: at least 20 verified resources per domain × resource type. Treat 20 as a floor, not a target — if high-quality resources remain after 20, keep going. Stop only when additional searching stops surfacing new relevant resources, not when a count is reached.
• Clusters: always collect for every cluster in the input. Never ask which clusters to target and never sample a subset.

Note the interaction with Step 4's verification: the floor applies to resources that survive URL verification. If verification drops entries below 20 for a domain, search again to replace them.

Never offer the user a faster, shallower option, and never stop early because the result set "looks like enough".

Report Quality Principles — Visual and Structural Expression

Use figures, tables, formulas, structured lists, Mermaid diagrams, and ASCII art aggressively throughout the output. Prose is the fallback, not the default: whenever information has structure — a distribution, a trend, a relationship, a comparison — express that structure visually rather than describing it in sentences.

The resource tables are the backbone of this skill's output, but a wall of tables is not a report. The analytical sections around them must be visual too.

Default representation by information shape:

Specific requirements for this skill:

• 収集サマリ table (mandatory) — Counts per domain × resource type, already in the template.
• Year distribution (mandatory) — Show how resources spread across the target period, as an ASCII bar chart. A reader should see at a glance whether the field is accelerating.
• 全体の傾向 section — Lead with a visual (chart or diagram), then the prose. Never a bare paragraph.
• Resource relationship diagram — When collected resources have visible relationships (a survey and the papers it covers, a patent family, papers from one group), show them as a Mermaid diagram.
• Coverage gaps — When a domain yields notably fewer resources, make this visible in a table or chart rather than burying it in prose.

Example of the year distribution chart:

2026 |████████████ 12
2025 |████████████████████ 20
2024 |███████████ 11
2023 |█████ 5

Mermaid syntax constraint: output under research/** is rendered by the viewer and validated by npm run check:docs (mermaid parse check). Keep node labels free of unescaped (, ), :, and , — wrap such labels in quotes (A["label (with parens)"]). A diagram that fails to parse breaks CI.

Step 3: Resource Collection

For each target domain, search for resources in parallel using the Agent tool to spawn subagents.

3a: Academic Papers (arXiv-first)

Papers are searched with arXiv as the primary source because it provides open-access full text, stable URLs, and consistent metadata.

Search strategy:

1. arXiv search via WebSearch: Query site:arxiv.org "{domain keyword}" {year range} to find relevant papers. Also search for survey/review papers: site:arxiv.org "{domain keyword}" survey OR review.
2. Semantic Scholar / Google Scholar fallback: If arXiv results are insufficient (e.g., the domain is not well-represented on arXiv), broaden to "{domain keyword}" paper {year} on general web search.
3. IEEE/ACM for specific domains: For domains where conference proceedings are important (networking, systems, HCI), also search site:ieee.org or site:dl.acm.org.

For each paper, collect:

• Title
• Authors (first author + "et al." for >3 authors)
• Year
• Venue (arXiv, conference name, journal)
• arXiv ID or DOI
• URL (prefer arxiv.org/abs/ format)
• 1-2 sentence summary

CRITICAL — Anti-hallucination rule for URLs:

• Only record URLs that appear verbatim in WebSearch results. NEVER construct or guess arXiv IDs.
• If a search result shows a title but no direct URL, run a follow-up WebSearch for site:arxiv.org "{exact paper title}" to obtain the real URL.
• Do NOT fabricate arXiv IDs by combining partial numbers. Every URL must come from a search result or a WebFetch response.

Quality signals to prioritize:

• High citation count (if visible in search results)
• Survey/review papers (valuable for overview)
• Papers from top venues (NeurIPS, ICML, CVPR, ACL, etc.)
• Recent papers with significant attention

3b: Patents

Search across multiple patent databases to get broad coverage.

Search strategy:

1. Google Patents (primary): site:patents.google.com "{domain keyword}" — provides international coverage with English abstracts
2. USPTO: Search for US patents when the domain has strong US presence
3. J-PlatPat: Search in Japanese for Japan-specific patents — useful when keywords have Japanese equivalents
4. Espacenet: Search for European patents when relevant

For each patent, collect:

• Title
• Patent number (e.g., US11234567B2, JP2023-123456)
• Assignee/Applicant
• Filing year
• Patent office (USPTO/JPO/EPO/WIPO)
• URL
• 1 sentence summary of the invention

CRITICAL — Anti-hallucination rule for URLs:

• Only record patent numbers and URLs that appear verbatim in search results or WebFetch responses.
• NEVER fabricate patent numbers. If a search result mentions a patent without a clear number, run a follow-up search to obtain the exact number and URL.

Prioritize:

• Patents from major companies in the domain
• Recent patents (within the specified time range)
• Patents with many citations or family members

3c: Technical Resources

Search for high-quality technical content.

Search targets:

• Technical blogs from major companies (Google AI Blog, Meta Research, Microsoft Research, etc.)
• Conference talks and presentations (from slides/video sharing sites)
• Notable OSS projects on GitHub
• Technical standards and specifications

For each resource, collect:

• Title
• Source/Author
• Year/Date
• Type (

Content truncated.