context-research

What this skill does

<!--
  The API reference in Part 2 is derived from the huggingface-papers skill
  in the huggingface/skills repository (https://github.com/huggingface/skills),
  originally licensed under the Apache License, Version 2.0.
  See LICENSE-APACHE and NOTICE in the plugin root for details.
-->
---
name: context-research
description: An autonomous research pipeline that identifies, analyzes, and synthesizes SOTA AI research via Hugging Face and ArXiv. Designed for engineering-grade deep dives into AI topics (e.g., "KV-cache optimization," "model merging").
disable-model-invocation: false
---

# PART 1: Research Pipeline Logic

## Phase 1: Intelligent Discovery & Ranking
1.  **Parallel Search**: Execute `GET /api/papers/search?q={query}&limit=20`.
2.  **Ranking Heuristic**: Rank results using a weighted score:
    - **Relevance (50%)**: Keyword density in title/abstract.
    - **Recency (25%)**: Prioritize papers from the last 12-18 months.
    - **Impact (25%)**: Upvotes and author/organization affiliation.
3.  **Sparse Result Fallback**: If < 5 papers are found on HF, the agent MUST use its web search tool to find ArXiv IDs or project pages, then use `GET /api/papers/{ID}` to ingest them.

## Phase 2: Parallel Deep Extraction
To maximize speed, execute metadata and content fetches for the top 3-5 papers **in parallel**.

1.  **Depth Check**: Fetch the `.md` content via `GET /papers/{ID}.md`.
    - **If Shallow (< 3000 chars)**: The markdown is likely just an abstract. Fall back to `https://arxiv.org/pdf/{ID}` to parse the full text for tables, benchmarks, and "Limitations" sections.
2.  **Metric Mining**: Specifically extract quantitative data:
    - Performance deltas (e.g., "26–54% reduction").
    - Hardware requirements and compute costs.
    - Benchmarks used (e.g., Needle-in-a-Haystack, AppWorld).
3.  **Artifact Audit**: Check `githubRepo` and `linkedModels`. If a repo exists, check the README for production implementation details.

## Phase 3: Thematic Synthesis
Avoid individual paper summaries. Organize the report by **Technical Taxonomy**:
1.  **Architectural Shifts**: How does this research change how we build?
2.  **Universal Bottlenecks/Patterns**: Identify cross-paper themes (e.g., "Information Loss," "Latency-Accuracy Trade-offs," or "Context Saturation").
3.  **Production Trade-offs**: Analyze the cost of implementation (e.g., KV-cache invalidation, API overhead).

## Phase 4: Key Takeaways
After synthesis, write a **Key Takeaways** section placed immediately after the report header (before the first numbered section). This should be a concise bulleted list (5-8 bullets) of the most actionable insights distilled from the full report. Each bullet should be self-contained and useful without reading the rest of the document.

## Phase 5: Document Completeness (MANDATORY)
The saved report file must contain everything the user will learn from this research — **including execution recaps, cross-paper findings, picked-paper rationales, and any process meta-commentary**. Do not rationalize any category of content as "meta" and therefore chat-only. If it's worth telling the user, it's worth saving.

1.  **Two canonical summary locations — no others**:
    - **Key Takeaways** (Phase 4): 5–8 actionable insight bullets, immediately after the header. Keep it sharp — do not expand it to absorb recap content.
    - **Appendix: Execution Notes**: placed at the end of the document. Holds the research-process recap: which papers were picked and why, cross-paper findings, methodology notes, and any synthesis that doesn't fit the main taxonomy. Structure it as short prose paragraphs under three fixed sub-headings in this order: **Paper Selection** (what was picked and why), **Cross-Paper Findings** (themes spanning multiple papers), **Methodology Notes** (how the research was conducted, fallbacks used, gaps encountered).
    Do not invent other summary sections.
2.  **Persist before replying**: Both sections must exist in the file on disk before you compose the chat reply.
3.  **Draft the reply from the file**: Compose the chat reply by quoting or paraphrasing directly from the saved document — not by writing it independently. The file drives the reply, never the reverse.

---

# PART 2: Technical Specifications

## Filename & Slugification
All reports MUST be saved using the following convention:
- **Format**: `research_{topic-lowercase-kebab-case}.md`
- **Example**: `research_kv_cache_optimization.md`

## Core API Knowledge (Retained)
- **Search**: `GET /api/papers/search?q={query}`
- **Metadata**: `GET /api/papers/{ID}` (Authors, Upvotes, Links).
- **Content**: `GET /papers/{ID}.md` (Markdown version).
- **Model Links**: `GET /api/models?filter=arxiv:{ID}`.

## Error Handling & Fallbacks
- **404/Empty MD**: Always check `https://arxiv.org/abs/{ID}` as the source of truth if HF indexing is incomplete.
- **Multi-ID Support**: Handle both HF internal IDs and arXiv IDs (e.g., `2602.08025`).

## When to Use
- Deep-dive technical requests requiring more than a surface-level summary.
- Requests for "State of the Art" (SOTA) analysis.
- Identifying implementation risks for new AI architectures.