deep-research

What this skill does

# 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.

| Depth | Purpose | Scope |
|-------|---------|-------|
| **focused** | Answer a specific question | One decision: "CodeMirror vs ProseMirror?" — targeted search, local scan, 1-2 comparisons. Produces a 1-page recommendation. |
| **wide** | Understand the space | Landscape for a new product or feature. Competitors, ecosystem, user needs, architecture options. Enough to write a spec. |
| **deep** | Plan a major build | Leave no stone unturned. Everything in wide PLUS library/component research, plugin ecosystems, GitHub issues mining, community sentiment, future-casting, technical deep-dives on every decision. Enough to drive weeks of coding. |

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:

```bash
# 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):

| Question | How to research |
|----------|----------------|
| Features | Landing page, docs, changelog |
| Pricing | Pricing page, comparison sites |
| User complaints | Reddit, HN, app store reviews |
| Tech stack | Wappalyzer, view-source, job postings, blog posts |
| What they do well | 5-star reviews, product demos |
| What they do poorly | 1-star reviews, forum complaints, migration guides FROM the product |
| Documentation quality | Read their docs site — is it comprehensive? What topics need the most explanation? (Complex topics = things users struggle with) |
| Help/support content | Help centre, FAQ, knowledge base, support forums — what questions do users ask most? |
| Onboarding/tutorials | Getting started guides, video tutorials, interactive walkthroughs — how do they teach their product? What do they assume the user already knows? |
| API documentation | If they have an API — how well documented? What patterns do they use? What SDKs do they provide? |
| Migration guides | Do they have "switch from X" guides? These reveal what they consider their advantages AND what users find hard to switch from |

### 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**:

| Question | Why it matters |
|----------|---------------|
| Does it solve our problem? | Feature match |
| Bundle size | Performance budget |
| Last publish date | Is it maintained? |
| Open issues / PRs | Community health |
| Works on our platform? | Cloudflare Workers has restrictions |
| What patterns does it use? | Even if we don't use the library, its patterns are valuable |

**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