Deep research and discovery before building something new. Explores local projects for reusable code, researches competitors, reads forums and reviews, analyses plugin ecosystems, investigates technical options, and produces a comprehensive research brief. Three depths: focused
Installs just this skill. Get the whole plugin for auto-invocation.
⚡ How it fires
How this skill gets triggered: by you, by Claude, or both.
Fires itselfClaude auto-loads it when your prompt matches the work.
You can call itInvoke it directly when you want it.
Slash command/deep-research
👁️ Context preview
The summary Claude sees to decide when to auto-load this skill.
Deep research and discovery before building something new. Explores local projects for reusable code, researches competitors, reads forums and reviews, analyses plugin ecosystems, investigates technical options, and produces a comprehensive research brief. Three depths: focused
📊 Stats
Stars940
Forks96
LanguagePython
LicenseMIT
📦 Ships with jezweb-skills
</> SKILL.md
deep-research.SKILL.md
---name: deep-research
description: "Deep research and discovery before building something new. Explores local projects for reusable code, researches competitors, reads forums and reviews, analyses plugin ecosystems, investigates technical options, and produces a comprehensive research brief. Three depths: focused (30 min), wide (1-2 hours), deep (3-6 hours). Triggers: 'research this', 'discovery', 'explore the space', 'what should I build', 'competitive analysis', 'before I start building', 'research before coding'. Not for cited fact-checking research reports (a separate harness does those); this is pre-build product discovery."
compatibility: claude-code-only
---# 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. |
| 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
- 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.
**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.
- Example: "Workers AI `toMarkdown()` converts any uploaded PDF/DOCX to markdown at the edge — we could use this for document import without any external service"
#### Why This Matters
The difference between "build a note app" and "build a note app that converts any file to markdown, searches semantically across all notes, generates summaries with AI, syncs via background Workflows, and renders PDFs with Browser Rendering" is **knowing what the platform offers**. Most developers only use 20% of their platform because they never looked at the other 80%.
### 8. Future-Casting (deep mode)
Think beyond what exists today:
**Platform roadmap**: Based on the changelog and blog research above, what direction is the platform heading? What's in beta? What was announced but not yet GA?
**AI integration**: Not "add a chatbot" — think deeper. What's possible when the tool can read, reason about, and act on the user's data? What if every note could be searched semantically? What if the app could write its own documentation? What if uploads auto-converted to markdown?
**Device and input evolution**: Mobile-first, voice input, wearables, spatial computing. How might users interact with this in 2-5 years?
**Data sources**: What new inputs could feed in? Sensors, APIs, real-time data, cross-app context?
**Adjacent opportunities**: What problems sit next to this one? e.g. building a note app — adjacent: task management, project tracking, team communication. What are users duct-taping together today?
**Convergence trends**: What separate tools are being unified? (Email + chat + tasks = Slack. Notes + databases + wikis = Notion. What's next?)
