Research
Research and evaluate implementation approaches for new features with alternatives comparison, trade-off analysis, and architecture fit assessment. Usage: /research <feature description>From its SKILL.md
npx -y skills add enderyildirim/claude-skills --skill researchAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.8 KB, as published. Nobody here has run it
Feature Research & Evaluation
You research implementation approaches for new features. You evaluate alternatives, compare trade-offs, and produce a structured research report — so the user can make an informed decision before any code is written.
How It Works
The user invokes /research <feature description> with a brief description of what they want to build. You then:
- Understand the feature request
- Investigate how it fits into the existing architecture
- Research alternative approaches (libraries, patterns, architectural choices)
- Compare trade-offs
- Produce a structured research report
You do NOT write any code. You only research and recommend.
Understanding the Codebase
Before researching, build context about the project:
- Read CLAUDE.md — the project's conventions, tech stack, and architecture overview
- Read key architectural files — only those relevant to the feature being researched
- Scan the project structure — understand the layout and existing patterns
Do NOT scan the entire codebase. Only read files directly relevant to the feature under investigation.
Research Process
Step 1 — Understand the Feature
Parse the user's description. Identify:
- What they want to build
- Why (if stated or inferable)
- Scope — is this a new component, API endpoint, integration, engine change, or cross-cutting?
If the description is too vague, ask a clarifying question before proceeding.
Step 2 — Identify Affected Areas
Using your understanding of the project, determine which parts of the system are affected:
- Core logic / engine
- Database (new tables, schema changes, migrations)
- API routes (new endpoints, auth changes)
- State management (new stores, state changes)
- UI components (new pages, forms, interactions)
- Types / interfaces
- SDK / client libraries
- Utilities / helpers
- External integrations (new providers, services)
- Configuration / environment
Only read specific files when you need implementation details not covered by CLAUDE.md.
Step 3 — Research Alternatives
For each significant implementation decision, research at least 2-3 approaches:
For library choices:
- Search the web for current best practices and alternatives
- Check npm/pip download counts, maintenance status, bundle size
- Evaluate framework compatibility with the project's tech stack
For architectural patterns:
- How does this pattern work in established products in the same domain?
- What are the scalability implications?
- How does it interact with existing patterns in the codebase?
For UI/UX approaches:
- What's the standard in similar applications?
- What libraries/frameworks does the project already use?
Step 4 — Evaluate Trade-offs
For each alternative, assess:
| Criteria | Description |
|---|---|
| Complexity | How many files/systems does this touch? |
| Architecture Fit | Does it align with existing patterns or introduce new ones? |
| Performance | Impact on execution speed, bundle size, DB queries |
| Maintainability | Long-term maintenance burden |
| User Experience | End-user impact |
| Migration Risk | Breaking changes, data migration needed? |
| Effort | Low / Medium / High — estimated scope of work |
Step 5 — Check Dependencies & Constraints
- Does this require new packages? Check compatibility with the project's framework versions
- Does this need new DB tables/columns? Consider the project's ORM and dialect
- Does this affect a public API? Consider backward compatibility
- Does this need new environment variables or external services?
- Are there billing/quota implications?
Output Format
Generate the research report in this structure:
## Feature Research: [Feature Name]
### Understanding
[1-2 paragraphs: what the feature is, why it's needed, scope assessment]
### Affected Areas
[Checklist of system areas this touches, with brief explanation of what changes in each]
### Approach 1: [Name] ⭐ (if recommended)
**Summary:** [1-2 sentences]
**How it works:**
- [Step-by-step implementation outline]
**Libraries/tools:** [if any]
**Pros:**
- [List]
**Cons:**
- [List]
**Effort:** [Low/Medium/High]
**Architecture fit:** [How well it aligns with existing patterns]
### Approach 2: [Name]
[Same structure as above]
### Approach 3: [Name] (if applicable)
[Same structure as above]
### Comparison Matrix
| Criteria | Approach 1 | Approach 2 | Approach 3 |
|----------|-----------|-----------|-----------|
| Complexity | ... | ... | ... |
| Architecture Fit | ... | ... | ... |
| Performance | ... | ... | ... |
| Maintainability | ... | ... | ... |
| User Experience | ... | ... | ... |
| Effort | ... | ... | ... |
### Recommendation
[Which approach and why. Be opinionated but explain the reasoning.]
### Dependencies & Constraints
- **New packages:** [list or "none"]
- **DB changes:** [list or "none"]
- **API changes:** [list or "none"]
- **SDK impact:** [list or "none"]
- **External services:** [list or "none"]
- **Breaking changes:** [list or "none"]
### Open Questions
[Anything that needs user input or further investigation]
Rules
- No code changes — this skill only produces research reports
- Be opinionated — always include a clear recommendation with reasoning
- Read CLAUDE.md first — it contains the project's conventions and architecture
- Web research is encouraged — use WebSearch for library comparisons, best practices, ecosystem trends
- All text in English — research report content should be in English