AnalyticsGPT: Sequential LLM Workflow for Scientometric Question Answering

This skill teaches Claude to build end-to-end LLM-powered pipelines that answer scientometric questions -- meta-scientific queries about research output, impact, collaboration patterns, and publication trends. The core technique from the AnalyticsGPT paper (Ly et al., 2026) is a four-stage sequential workflow: (1) high-level planning with named-entity recognition of academic entities, (2) detailed plan generation with dependency-aware tool calls, (3) parallel execution of data retrieval steps, and (4) analytical synthesis into structured, citation-rich responses. This approach handles the unique challenge of scientometric QA where questions reference specific authors, institutions, journals, and topics that must be resolved to database identifiers before any data can be retrieved.

When to Use

• When the user wants to build a natural-language interface to an academic or bibliometric database (Scopus, OpenAlex, Semantic Scholar, DBLP, institutional research platforms)
• When implementing a multi-agent pipeline that decomposes complex research-analytics questions into executable sub-queries
• When the task requires named-entity recognition and resolution for academic entities (author names, institution names, journal titles, research topics) against a knowledge base
• When building RAG systems over structured scholarly metadata rather than unstructured paper text
• When the user needs to compare research performance across institutions, authors, countries, or time periods
• When generating analytical reports from raw scientometric data (h-index, impact factors, citation counts, collaboration networks)

Key Technique

The core insight is that scientometric questions differ from standard QA because they require a planning phase that traditional retrieve-then-read pipelines skip. A question like "How does MIT's AI research output compare to Stanford's over the last decade?" cannot be answered with a single retrieval call. It requires: (a) recognizing "MIT" and "Stanford" as institution entities and "AI" as a topic, (b) resolving each to database identifiers, (c) planning separate but parallel data retrievals for each institution filtered by topic and year range, and (d) synthesizing comparative analysis from the results.

The two-tier planning architecture separates concerns cleanly. A lightweight high-level planner (can use a smaller/faster model) extracts named entities with their types and outlines broad steps. A more capable detailed planner then expands each broad step into specific tool calls with exact parameters, dependency ordering, and entity IDs injected from the resolution stage. This separation means the expensive model only sees well-structured input, and the entity resolution step bridges the gap between natural language references and database-ready identifiers.