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.
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.
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 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?)
9. Technical Research (deep mode)
For each major architectural decision:
Decision area
Questions to answer
Editor / UI framework
Options, tradeoffs, community size, our experience
Database
SQL vs NoSQL vs file, managed vs self-hosted, our stack support
Auth
Better-auth, Clerk, Auth.js, custom — what fits?
Hosting / deployment
Cloudflare, Vercel, Railway — constraints and capabilities
Search
FTS5, Elasticsearch, Meilisearch, Vectorize — what scale?
Real-time
WebSockets, SSE, Durable Objects — do we need it?
File storage
R2, S3, local — access patterns?
API design
REST, tRPC, GraphQL — what does the use case need?
10. Synthesis
Produce a research brief saved to .jez/artifacts/research-brief-{topic}.md:
# Research Brief: [Topic]**Depth**: [focused|wide|deep]
**Date**: YYYY-MM-DD
**Research time**: [duration]
## Executive Summary
[2-3 sentences: what to build, why, key insight from research]
## Competitive Landscape
| Product | Strengths | Weaknesses | Pricing | Users |
### Key Insights
[What winners do well, what gaps exist in the market]
## Ecosystem Signals### Most Popular Plugins/Add-ons
[Top plugins for competitors — reveals unmet needs]
### Most Requested Features
[From GitHub issues, forums, reviews — sorted by demand]
### Integration Patterns
[What systems users connect to — reveals real workflows]
## User Needs
[What real users want, from reviews/forums/complaints]
## Technical Landscape
| Decision | Options | Recommendation | Why |
## Libraries and Components
| Need | Library | Stars | Size | Fits platform? | Notes |
[Key libraries evaluated for each major feature]
## Platform Capabilities
| Service | Could use for | Impact |
[Every platform service evaluated against the product's needs]
[Flag recently shipped features the team may not know about]
## Reusable From Existing Projects
| Project | What to reuse | Location |
## Future Possibilities### Platform roadmap### AI opportunities### Adjacent problems### 2-5 year horizon## Proposed Architecture
[Stack, data model sketch, key flows]
## Risks and Open Questions
[Things research couldn't answer]
## Suggested Phases
[Build order based on research findings]
## Sources
[Links to everything read]
Tips
Start the brief early and add to it as you research — the artifact is the deliverable
For deep mode, use sub-agents to parallelise web research and local exploration
The "Reusable From Existing Projects" section often saves weeks of work
Ecosystem signals (plugins, issues, reviews) are often more valuable than competitor feature lists
Save the brief to .jez/artifacts/ — it's useful for future sessions and for the actual build phase
The brief is a living document — update it as you learn more during the build