Deep Research

Deep Research

Comprehensive research and discovery before building something new. Instead of jumping straight into code from training data, this skill goes wide and deep — local exploration, web research, competitor analysis, ecosystem signals, future-casting — and produces a research brief that makes the actual build 10x more productive.

Depth Levels

The difference is scope of ambition, not just time.

Default: wide

Workflow

1. Understand the Intent

Ask the user:

• What are you building? (one sentence)
• Why? What problem does it solve? Who's it for?
• Constraints? Stack preferences, budget, timeline, must-haves?
• Existing work? Any projects to build on? Repos to look at?

If the user gives a brief prompt ("obsidian replacement on cloudflare"), that's enough — fill in the gaps through research.

2. Local Exploration

Scan the user's machine for relevant prior work:

# Find related projects by name/keyword
ls ~/Documents/ | grep -i "KEYWORD"

# Read CLAUDE.md of related projects for architecture context
find ~/Documents -maxdepth 2 -name "CLAUDE.md" -exec grep -l "KEYWORD" {} \;

# Check for reusable patterns, schemas, components
find ~/Documents -maxdepth 3 -name "schema.ts" -o -name "ARCHITECTURE.md" | head -20

For each related project found:

• Read CLAUDE.md (stack, architecture, gotchas)
• Check for reusable code (schemas, components, utilities, configs)
• Note what worked well and what didn't (from git history, TODO comments)

Also check:

• Basalt Cortex (~/Documents/basalt-cortex/) for related clients, contacts, knowledge facts
• grep -rl "KEYWORD" ~/Documents/basalt-cortex/ --include="*.md"

3. Web Research

Search broadly to understand the space:

• Product category: "markdown note app", "knowledge management tool for teams"
• Competitors: find top 5-10 by searching "best X", "X alternatives", "X vs Y"
• Open source: search GitHub for open-source alternatives, check star counts
• Architecture: "how to build X", "X tech stack", "building X with [framework]"
• Technology docs: check llms.txt, official docs for key technologies
• Platform examples: "built with Cloudflare Workers", "D1 full-text search example"
• Tutorials and case studies: "building a Y from scratch", "lessons learned building Z"

4. Ecosystem and Community Research (wide + deep)

Go beyond the core product — the ecosystem reveals what users actually need:

Plugins and add-ons:

• What plugins exist for major competitors? The most popular ones reveal what the core product lacks.
• e.g. Obsidian has 1800+ plugins — the top 20 tell you what Obsidian doesn't do well natively.
• Search: "top [product] plugins", "[product] plugin directory"

GitHub issues and feature requests:

• Check top competitors' GitHub repos for most-upvoted issues
• Sort by thumbs-up reactions — this is direct user demand signal
• Check closed issues for how features were implemented

Forum discussions:

• Reddit: r/[product], r/selfhosted, r/webdev, relevant niche subreddits
• Hacker News: search for the product category
• Discord/Discourse: product-specific communities
• What do users love? What do they complain about? What do they wish existed?

App store and review sites:

• 1-star reviews = unmet needs (the product fails at this)
• 5-star reviews = what to preserve (users love this, don't break it)
• 3-star reviews = the interesting middle (it's okay but...)
• Search: ProductHunt, G2, Capterra, App Store reviews

Integration requests:

• What systems do users want to connect to? (Zapier integrations, API requests)
• These reveal real workflows — users duct-tape tools together

5. Competitor Deep-Dive (wide + deep)

For each major competitor (3-5 for wide, 5-10 for deep):

6. Library and Component Research (deep mode)

Research the building blocks — what already exists that you can use or learn from:

React / UI libraries:

• Search npm for category-specific packages ("react markdown editor", "react kanban", "react data table")
• Check weekly downloads, last publish date, GitHub stars, open issues count
• Read the README and examples — what patterns do they use?
• Check bundle size (bundlephobia.com) — does it fit the project constraints?
• Look at the source code of the best ones — their architecture is proven by real usage

Headless / unstyled libraries:

• Headless UI, Radix, React Aria, Downshift — what primitives exist for the features you need?
• These are often better than full component libraries because you control the styling
• Check if shadcn/ui already wraps what you need

Hooks and utilities:

• TanStack (Query, Table, Virtual, Router) — what's relevant?
• React Hook Form, Zod, date-fns, Zustand — proven solutions for common problems
• Search "awesome-react" lists and curated collections

Platform-specific libraries:

• For Cloudflare: what works on Workers? (No Node.js APIs, no native modules)
• Check Cloudflare's own examples and starter templates
• Search for "cloudflare workers" + the feature you need

What to capture for each library:

The insight: Even if you decide to build something custom, researching existing libraries shows you the patterns that survived contact with real users. A library with 10K stars has had its API refined by thousands of developers — steal their design decisions.

7. Platform Capability Deep-Dive (wide + deep)

This is critical. Claude's training data is always behind on platform features. Cloudflare, Vercel, Firebase, Supabase — they all ship new capabilities constantly. A feature you assume doesn't exist might have launched last month. The Basalt Cortex project exists because of capabilities (Workers AI toMarkdown, Vectorize metadata filtering, D1 FTS5) that weren't obvious without actively looking.

Do NOT rely on training data for platform capabilities. Go read the actual current docs.