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.
Works with
AI-first code editor with Composer
Before installing skills in Cursor, ensure your development environment meets these requirements:
node --versiondeep-researchExecute the skills CLI command in your project's root directory to begin installation:
Fetches deep-research from jezweb/claude-skills and configures it for Cursor.
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
Confirm successful installation by checking the skill directory location:
Restart Cursor to activate deep-research. Access via /deep-research in your agent's command palette.
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Submit your Claude Code skill and start earning
Create detailed user stories, acceptance criteria, and feature specs
Example
Generate user stories for 'password reset feature' with acceptance criteria, edge cases, and test scenarios
Reduce spec writing time by 50%, ensure comprehensive coverage
Research competitors, compare features, identify gaps
Example
Analyze 5 competitor products, create feature comparison matrix, suggest differentiation opportunities
Complete competitive research in 2 hours instead of 2 days
Evaluate features using frameworks (RICE, ICE, Kano) and create prioritized backlogs
Example
Score 20 feature ideas using RICE framework, generate prioritized roadmap with rationale
0
total installs
0
this week
697
GitHub stars
0
upvotes
Run in your terminal
0
installs
0
this week
697
stars
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.
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
Ask the user:
If the user gives a brief prompt ("obsidian replacement on cloudflare"), that's enough — fill in the gaps through research.
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:
Also check:
~/Documents/basalt-cortex/) for related clients, contacts, knowledge factsgrep -rl "KEYWORD" ~/Documents/basalt-cortex/ --include="*.md"Search broadly to understand the space:
Go beyond the core product — the ecosystem reveals what users actually need:
Plugins and add-ons:
GitHub issues and feature requests:
Forum discussions:
App store and review sites:
Integration requests:
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 |
Research the building blocks — what already exists that you can use or learn from:
React / UI libraries:
Headless / unstyled libraries:
Hooks and utilities:
Platform-specific libraries:
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.
Fetch the platform's changelog/blog:
https://blog.cloudflare.com/ + https://developers.cloudflare.com/changelog/https://vercel.com/changeloghttps://firebase.google.com/support/releaseshttps://supabase.com/changelogRead the full product catalogue — not just the services you already use:
For each service, ask: could this solve a problem in the product we're building?
Look for recently shipped features that expand what's possible:
Go through each and ask "would this be useful for what we're building?":
| Category | Services to investigate |
|---|---|
| Compute | Workers, Cron Triggers, Queues consumers, Workflows (multi-step), Containers, Durable Objects (stateful), Tail Workers |
| Storage | D1 (SQL + FTS5), R2 (objects), KV (key-value), Durable Object storage (strongly consistent) |
| AI | Workers AI models (text, image, embedding, speech, translation, toMarkdown), Vectorize (semantic search), AI Gateway (caching/routing) |
| Networking | Custom domains, Tunnel, Spectrum (TCP/UDP), WebSockets, Hyperdrive (database proxy) |
| Security | WAF, Turnstile (CAPTCHA), Bot Management, API Shield, DDoS |
| Media | Images (resize/optimise on-the-fly), Stream (video), Browser Rendering (screenshots, PDF generation) |
| Email Routing (rules), Email Workers (programmable inbound email processing) | |
| Observability | Workers Logs, Analytics Engine, GraphQL analytics |
For each relevant capability, note:
toMarkdown() converts any uploaded PDF/DOCX to markdown at the edge — we could use this for document import without any external service"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%.
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?)
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? |
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]
.jez/artifacts/ — it's useful for future sessions and for the actual build phaseMake data-driven prioritization decisions faster
Draft PRDs, status updates, and stakeholder presentations
Example
Create executive summary of Q3 roadmap, monthly progress report, feature launch announcement
Save 3-5 hours/week on communication overhead
Prerequisites
Time Estimate
30-60 minutes to see productivity improvements
Steps
Common Pitfalls
✓ Do
✗ Don't
💡 Pro Tips
✓ Use when
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
✗ Avoid when
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
jezweb/claude-skills
mattpocock/skills
parcadei/continuous-claude-v3
cursor/plugins
ailabs-393/ai-labs-claude-skills
ailabs-393/ai-labs-claude-skills
We added deep-research from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
Solid pick for teams standardizing on skills: deep-research is focused, and the summary matches what you get after install.
deep-research reduced setup friction for our internal harness; good balance of opinion and flexibility.
deep-research reduced setup friction for our internal harness; good balance of opinion and flexibility.
Registry listing for deep-research matched our evaluation — installs cleanly and behaves as described in the markdown.
deep-research has been reliable in day-to-day use. Documentation quality is above average for community skills.
We added deep-research from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
Keeps context tight: deep-research is the kind of skill you can hand to a new teammate without a long onboarding doc.
deep-research is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
Useful defaults in deep-research — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
showing 1-10 of 42