SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsresearch-to-slides

research-to-slides

Writing & research

View repository

Updated 10-15 17:28

About this skill

Research-to-Slides — Phase 0: Research → Slide Materials

Overview

As a preliminary stage for presentation creation, systematically investigate papers, repositories, and technical information related to the theme, and generate structured research notes (research-notes.md).

Collect and organize the evidence necessary for AI for Science / policy recommendations / technology strategy presentations from highly reliable sources.

Target Tools

Tool Purpose Priority
search_repositories Discovery of theme-related repositories High
search_code Search for specific code patterns and implementation examples Medium
get_file_contents Retrieval of README, docs, and configuration files High
search_issues Investigation of discussions and issues Medium
search_pull_requests Understanding change history and feature additions Medium
list_commits Chronological understanding of development activity Low
web_search Search for papers and external technical information High
web_fetch Detailed retrieval of web pages Medium

Execution Steps

Step 1: Theme Analysis

  1. Extract keywords from user input
  2. Generate 3–5 search query patterns (both English and Japanese)
  3. Define the research scope (technical domain, time range, target organizations)

Step 2: GitHub Repository Investigation

  1. search_repositories Search for theme-related repositories with (sorted by Stars)
  2. For the top 5–10 repositories, get_file_contents retrieve the README with
  3. search_code Identify major implementation patterns with
  4. search_issues / search_pull_requests Understand the latest discussions and changes with
  5. list_commits Check development activity trends with

Step 3: Paper and External Information Collection

  1. web_search Search academic papers, technical blogs, and official documentation with
  2. web_fetch Retrieve details of important pages with
  3. Record preprints (arXiv, etc.) and peer-reviewed papers separately
  4. If policy documents (MEXT, NIST, etc.) are available, collect them preferentially

Step 4: Structuring and Analysis

  1. Organize collected data into the output template
  2. Create a technology comparison table (strengths, weaknesses, application domains)
  3. Derive insights (the "so what")
  4. Attach source URLs to all information

Output template: research-notes.md

# リサーチノート: {topic}

## エグゼクティブサマリー
{3行でまとめ — 何が分かったか、何が重要か、次のアクション}

## 主要リポジトリ
| リポジトリ | Stars | 説明 | URL |
|-----------|-------|------|-----|
| {owner/repo} | {N} | {1行説明} | {URL} |

## 技術比較
| 技術 | 強み | 弱み | 適用領域 |
|------|------|------|---------|
| {tech} | {strengths} | {weaknesses} | {domains} |

## 論文・文献
| タイトル | 著者 | 年 | 要点 | URL |
|---------|------|-----|------|-----|
| {title} | {authors} | {year} | {key finding} | {URL} |

## コードパターン
{実装例とその説明 — コードブロック付き}

## 最新動向（Issue/PR）
| リポジトリ | タイプ | タイトル | 状態 | URL |
|-----------|--------|---------|------|-----|
| {repo} | Issue/PR | {title} | Open/Closed | {URL} |

## インサイト
{「だから何か」の考察 — プレゼンテーションへの示唆}

## 出典一覧
{全URL・パス — 番号付きリスト}

Validation Loop

Output Validation Checks

  1. Source completeness: Whether a URL or file path is attached to every data row
  2. Reliability label: Whether the peer-review status (peer-reviewed / preprint / blog) is explicitly stated for each reference
  3. Fairness of technology comparison: Is the comparison table not one-sided (does each technology have both strengths and weaknesses)?
  4. Freshness: Are the information acquisition date/time and target period clearly stated?
  5. Template compliance: Does the output include all sections of the above template?

Verification procedure

1. research-notes.md の全行を走査
2. URL のない情報行を検出 → 出典追加 or 行削除
3. 信頼性ラベル未付与の文献を検出 → ラベル追加
4. 比較表の偏りチェック → バランス調整
5. 全チェック通過 → Phase 1（Presentation Architect）に引き渡し可能

Failure Recovery

Failure pattern Cause Recovery procedure
GitHub MCP rate limit Large number of requests in a short time Split the search into 3 or fewer rounds and accumulate the results
Zero results with web_search The query is too narrow Generalize the keywords and search again
get_file_contents failure The repository is private or the path is invalid Confirm the file exists with search_code, then retrieve it again
The paper's URL is a dead link Moved or deleted Use web_search with the DOI / title to obtain an alternative URL
The information is old (more than 2 years ago) The latest information cannot be found State clearly that there is 'no latest information' and record the date of the information already obtained

Quality Gates

  • The executive summary conveys the key points in 3 lines or fewer
  • 3 or more major repositories are listed
  • The technology comparison table includes 2 or more technologies
  • 3 or more papers/references are listed
  • A source URL is attached to every data row
  • Preprints and peer-reviewed papers are distinguished
  • The insights section includes 'implications for the presentation'
  • The source list is organized as a numbered list

Gotchas

1. GitHub MCP Rate Limits — Split execution of large searches

GitHub MCP tools have an implicit rate limit.search_repositories Calling 10 or more times in a row will cause a timeout.Split searches into 3 or fewer queries per roundand accumulate the results. In particular, search_code returns a large number of results, so narrow it down with thelanguage: や path: filter.

2. Verifying paper reliability — Distinguishing preprints from peer-reviewed papers

Citing an arXiv preprint as a 'peer-reviewed paper' raises reliability concerns in materials for MEXT / Microsoft HQ.Attach a reliability label to every paper(peer-reviewed / preprint / technical report / blog). For policy recommendation materials, preferentially cite peer-reviewed papers.

3. Prohibition of data without sources — Attach a URL to all information

Descriptions with unknown sources such as 'it is said that' or 'generally' are prohibited. Attach a verifiable URL or file path to all claims, data, and comparison results. For information whose source cannot be found, research-notes.md Do not include in.

4. Search language bias — search in both English and Japanese

Searching only in English will cause you to miss important repositories and literature within Japan. Conversely, searching only in Japanese makes it impossible to grasp international trends.Always in both English and Japanesegenerate search queries with.

Memory Persistence

Patterns learned from past research:

  • AI for Science field: RIKEN, AIST, and RIKEN AIP repositories are search_repositories more web_search are easier to discover
  • Microsoft-related technologies: org:microsoft narrow down to official repositories with the filter
  • MEXT policy documents: web_fetch when retrieving pages on mext.go.jp, since there are many PDF links, limit to summarizing the HTML pages
  • The trap of star counts: Even with few stars, official repositories are important. Do not sort by stars alone

Prohibited actions

  1. Prohibition of including information without sources — information without a URL research-notes.md do not include in
  2. Prohibition of omitting reliability labels — clearly state the peer-review status for all literature
  3. Prohibition of single-language searches — search in both English and Japanese
  4. Prohibition of excessive API calls — GitHub MCP calls per theme must be 15 or fewer
  5. Prohibition of copyright infringement — do not copy full texts of papers or reproduce figures without permission
  6. Prohibition of including private repository contents — even if accessible, confirm whether public disclosure is permitted