Agentic Paper Digest Skill

**Judgment:** A strong, well-scoped agent skill for generating structured digests of recent arXiv and Hugging Face papers. It is particularly well-suited for research assistants and automation pipelines that need JSON-based, topic-filtered literature updates, but it expects a reasonably technical setup and configuration. **What it does well** - Implements a complete, opinionated workflow: fetch → filter by LLM relevance → summarize → store → serve results via CLI/API. - Designed explicitly for agents: JSON-centric CLI output and a clear HTTP API (`/api/run`, `/api/status`, `/api/papers`, `/api/topics`, `/api/settings`). - Good configurability: topics, per-topic caps, recency window, arXiv categories, and fetch limits are all tunable. - Flexible model/provider support through LiteLLM, with separate models for relevance and summarization and sensible guidance (e.g., stronger model for summaries). **Key risks / limitations** - **Setup complexity:** Requires Python, shell access, environment variables, `.env` management, and JSON config editing. Non-expert users or tightly sandboxed environments may struggle. - **External dependencies:** Relies on arXiv, Hugging Face, and an LLM provider (OpenAI or compatible). Outages, rate limits, or API changes can break or degrade the pipeline. - **Cost and latency:** LLM-based relevance + summarization on multiple papers can be slow and incur non-trivial token costs, especially with larger windows or result caps. - **Configuration sensitivity:** Poorly designed topics (overlapping or too broad) or overly strict fetch limits can lead to sparse or noisy results; users need guidance to get good performance. **Recommended scenarios** - Building an **agentic research assistant** that periodically fetches and summarizes new papers for defined topics and feeds them into other tools or UIs. - Teams or power users who want a **local, configurable research digest service** with control over topics, recency, and data storage. - Workflows where **structured JSON outputs** (with topic IDs, caps, and run metadata) are needed for downstream automation, ranking, or ingestion into other systems. **Less ideal scenarios** - Very non-technical users who cannot manage Python, shell scripts, `.env` files, or JSON configs. - Environments where outbound network access or external LLM calls are constrained or heavily audited. - Use cases needing real-time, low-latency responses at very high volume (LLM-based filtering/summarization will be a bottleneck).