Notion Research Complete

A practical skill for conducting and documenting research using Notion — covering source collection, synthesis workflows, citation management, research brief generation, and structured knowledge capture for academic, market, and technical research.

When to Use This Skill

Choose Notion Research Complete when you need to:

• Collect and organize research sources in Notion
• Synthesize findings across multiple sources into briefs
• Create research reports with citations linked to sources
• Build a knowledge base from ongoing research activities
• Share research findings with team members in structured format

Consider alternatives when:

• You need web scraping for data collection (use a scraper skill)
• You need academic paper management (use a reference manager)
• You need survey design (use a survey research skill)

Quick Start

Copy
# Conduct research and document findings
claude "Research the current state of WebAssembly adoption in production. Find sources in Notion, synthesize findings, and create a research brief."

Copy
# Research Brief: WebAssembly in Production

## Research Question
What is the current adoption rate of WebAssembly in
production environments, and what are the primary use cases?

## Sources Analyzed
| Source | Type | Key Finding |
|--------|------|-------------|
| [State of Wasm 2024](notion://xxx) | Survey | 67% using in production |
| [Figma Engineering Blog](notion://yyy) | Case Study | 3x perf improvement |
| [Cloudflare Workers Docs](notion://zzz) | Documentation | Edge computing primary use |

## Key Findings
1. **Adoption is growing**: 67% of respondents use Wasm in
   production, up from 47% in 2023 (Source 1)
2. **Primary use cases**: Edge computing (45%), web apps (30%),
   server-side processing (25%) (Source 1)
3. **Performance gains**: Figma reported 3x rendering speed
   improvement after migrating core engine to Wasm (Source 2)
4. **Developer experience**: Rust → Wasm toolchain is most
   mature, followed by Go and C++ (Sources 1, 3)

## Gaps in Research
- Limited data on long-term maintenance costs
- Few studies on debugging experience in production
- No comprehensive comparison of Wasm vs. native performance
  across different workload types

## Recommendations
1. Evaluate Wasm for compute-intensive frontend components
2. Start with a contained experiment (image processing, data viz)
3. Use Rust as the source language for best tooling support

Core Concepts

Research Workflow

Phase	Activities	Notion Structure
Question	Define research question	Page with objectives
Collection	Gather sources and evidence	Sources database
Analysis	Read, annotate, extract findings	Annotations in source pages
Synthesis	Combine findings, identify patterns	Research brief page
Publication	Share findings with stakeholders	Published page or PDF

Source Database Design

Copy
// Notion source tracking database
const sourceProperties = {
  "Title": { title: {} },
  "URL": { url: {} },
  "Type": { select: { options: [
    { name: "Paper", color: "blue" },
    { name: "Blog Post", color: "green" },
    { name: "Documentation", color: "gray" },
    { name: "Survey", color: "yellow" },
    { name: "Case Study", color: "orange" },
  ]}},
  "Credibility": { select: { options: [
    { name: "High", color: "green" },
    { name: "Medium", color: "yellow" },
    { name: "Low", color: "red" },
  ]}},
  "Key Findings": { rich_text: {} },
  "Research Project": { relation: { database_id: "projects_db_id" } },
  "Date Published": { date: {} },
  "Read Status": { checkbox: {} },
};

Configuration

Parameter	Description	Example
research_topic	Research question or topic	"WebAssembly adoption"
source_types	Types of sources to collect	["papers", "blogs"]
synthesis_depth	Brief or comprehensive analysis	"brief" / "detailed"
citation_style	Citation format	"numbered" / "author-date"

Best Practices

1. Define the research question before collecting sources — Aimless collection produces a pile of bookmarks, not insights. Write down the specific question you're answering. Every source collected should directly address that question.

2. Rate source credibility when adding to the database — A peer-reviewed paper and a random blog post carry different weight. Tag credibility at collection time so synthesis isn't biased by low-quality sources.

3. Extract key findings as you read, not after — Annotate each source with its key findings immediately. Batch annotation after reading 20 sources leads to shallow summaries because you've forgotten the nuances.

4. Synthesize across sources, don't summarize each one — A research brief that says "Source 1 says X. Source 2 says Y." is a bibliography, not synthesis. Group findings by theme: "Three sources confirm that adoption is growing, while two highlight that tooling maturity varies by language."

5. Document what you didn't find — Research gaps are as valuable as findings. If no source addresses long-term maintenance costs of WebAssembly, that gap itself is a finding worth reporting.

Common Issues

Research never reaches the synthesis phase — Collection is satisfying; synthesis is hard. Set a deadline for collection (e.g., "I'll review 10 sources, then synthesize") and stick to it. Infinite source collection is procrastination disguised as diligence.

Sources become stale before the brief is published — In fast-moving fields, a source from 6 months ago may be outdated by the time you publish. Add publication dates to every source and flag anything older than your relevance threshold.

Findings from different sources conflict — This is normal and valuable. Don't hide contradictions — highlight them. "Source 1 reports 67% adoption while Source 2 reports 45%. The discrepancy likely reflects different sample populations (enterprise vs. all developers)."