research-intelligence-workflows

Research Intelligence Workflows

Overview

This umbrella covers research discovery, monitoring, synthesis, and research-output drafting. Use it when the task is to find current sources, monitor feeds, query markets, build/query a knowledge base, or write academic/research documents.

The shared discipline is source-grounded work: collect real sources, preserve identifiers/URLs, separate evidence from interpretation, and cite or archive enough context to reproduce the result.

When to Use

• Search arXiv by keyword, author, category, or ID.
• Monitor RSS/Atom/blog feeds and summarize changes.
• Build/query an LLM or markdown knowledge base.
• Query Polymarket markets, orderbooks, prices, or history.
• Plan/write ML research papers, related work, experiments, and submission checklists.

Workflow

1. Define the research question. Scope domain, timeframe, required freshness, and output format.
2. Collect primary sources first. Prefer official APIs/pages, arXiv IDs, feed URLs, market IDs, or source documents.
3. Normalize identifiers. Record arXiv IDs, DOI/URL, feed URL, market slug/condition ID, or note path.
4. Extract enough detail. Titles, authors, dates, abstracts/snippets, metrics/prices, and quoted evidence where needed.
5. Synthesize with uncertainty. Distinguish fact, inference, and recommendation.
6. Archive/reproduce. Save queries, scripts, source lists, or output paths when the work is likely to be revisited.

Labeled Subsections from Former Narrow Skills

arXiv and paper discovery

• Use precise query fields when possible and preserve arXiv IDs/versions.
• For literature reviews, cluster papers by method/task/evaluation instead of listing chronologically.

Blog/RSS monitoring

• Keep feed URLs explicit, deduplicate by stable entry IDs/links, and compare against the previous checkpoint when monitoring.
• Summaries should emphasize what changed and why it matters.

LLM wiki / knowledge-base work

• Treat the KB as a graph of markdown notes: stable filenames, backlinks, summaries, and explicit source notes.
• Query results should cite note paths and avoid overconfident synthesis when the KB is sparse.
• For portable agent-consumable KBs, prefer OKF-inspired Markdown: concept documents with YAML frontmatter (type, title or name, description, tags, timestamp, optional resource/okf_version), normal Markdown links as graph edges, index.md for progressive disclosure, and log.md for semantic update history.
• Keep consumption permissive but production strict: readers should tolerate unknown types/fields and some broken links, while repo CI should validate metadata shape, internal links, reserved-file rules, and registry/frontmatter consistency before publishing.