How do I install the Tech Research skill?

Run npx skillmds@latest add jamestorrevillas/tech-research in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Tech Research skill do?

Technology Research It is listed under Research & Search on SkillMD.

Is Tech Research safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Tech Research?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Tech Research free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Tech Research?

jamestorrevillas (@jamestorrevillas) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Tech Research by jamestorrevillas — Agent Skill

Name: Tech Research
Rating: 4.2 (5 reviews)
Author: jamestorrevillas

File contents

Technology Research

Research Process

1. DEFINE    — What specific decision are we making?
2. CONSTRAIN — What are the non-negotiables? (team skills, budget, timeline)
3. GATHER    — Collect data from quality sources
4. COMPARE   — Evaluate options against the same criteria
5. DECIDE    — Choose with explicit reasoning
6. DOCUMENT  — Record the decision for future reference

Technology Evaluation Criteria

Criterion	What to Look For
Problem Fit	Does it actually solve YOUR problem?
Maturity	Production-proven? Version 1.x or 0.x?
Community	Active GitHub, Stack Overflow, Discord
Maintenance	Last commit? Open issues? Response time?
Performance	Benchmarks relevant to your scale
Learning Curve	Team familiarity, documentation quality
Ecosystem	Plugins, integrations, tooling
Exit Cost	How hard to migrate away?
License	MIT/Apache (permissive) vs GPL vs commercial

Source Quality Hierarchy

Official documentation — authoritative, check version
Production case studies — most reliable, hardest to find
Benchmark comparisons — verify the benchmark matches your use case
Respected technical blogs — check date and author credentials
Reddit / Hacker News — good for real-world sentiment and gotchas
YouTube tutorials — useful for learning, not for decisions

Always check the date. A 2-year-old comparison may be obsolete.

Decision Document Template

## Technology Decision: [topic]

**Date:** | **Decided by:**

### Context
[What problem are we solving? What are our constraints?]

### Options Evaluated
| Criterion | Option A | Option B | Option C |
|-----------|---------|---------|---------|
| Problem Fit | | | |
| Maturity | | | |
| Team Familiarity | | | |
| Performance | | | |
| Long-term Risk | | | |

### Decision
**Chosen:** [option]

**Reasoning:** [why this fits our specific context]

**Trade-offs accepted:** [what we give up]

**Revisit if:** [conditions that would change this decision]

Build vs Buy Framework

Build when:

This IS your core competitive differentiator
No existing solution fits well enough (>40% custom needed)
You have the expertise and time to maintain it

Buy / Use OSS when:

It's infrastructure (auth, payments, email, queues)
Time-to-market is critical
Your users don't care who built the underlying tool
Maintenance would distract from core product

The hidden cost of building: every line you write, you now own forever.

Staying Current

Trusted sources for staying up to date:

GitHub Trending (weekly)
State of JS / State of CSS surveys (annual)
Stack Overflow Developer Survey (annual)
Official release blogs of tools you use
Hacker News "Who's Hiring" (for industry signals)
Thoughtworks Technology Radar (strategic view)

---name: tech-researchdescription: Technology Research---# Technology Research## Research Process```1. DEFINE — What specific decision are we making?2. CONSTRAIN — What are the non-negotiables? (team skills, budget, timeline)3. GATHER — Collect data from quality sources4. COMPARE — Evaluate options against the same criteria5. DECIDE — Choose with explicit reasoning6. DOCUMENT — Record the decision for future reference```---## Technology Evaluation Criteria| Criterion | What to Look For ||---|---|| **Problem Fit** | Does it actually solve YOUR problem? || **Maturity** | Production-proven? Version 1.x or 0.x? || **Community** | Active GitHub, Stack Overflow, Discord || **Maintenance** | Last commit? Open issues? Response time? || **Performance** | Benchmarks relevant to your scale || **Learning Curve** | Team familiarity, documentation quality || **Ecosystem** | Plugins, integrations, tooling || **Exit Cost** | How hard to migrate away? || **License** | MIT/Apache (permissive) vs GPL vs commercial |---## Source Quality Hierarchy1. Official documentation — authoritative, check version2. Production case studies — most reliable, hardest to find3. Benchmark comparisons — verify the benchmark matches your use case4. Respected technical blogs — check date and author credentials5. Reddit / Hacker News — good for real-world sentiment and gotchas6. YouTube tutorials — useful for learning, not for decisions**Always check the date.** A 2-year-old comparison may be obsolete.---## Decision Document Template```markdown## Technology Decision: [topic]**Date:** | **Decided by:**### Context[What problem are we solving? What are our constraints?]### Options Evaluated| Criterion | Option A | Option B | Option C ||-----------|---------|---------|---------|| Problem Fit | | | || Maturity | | | || Team Familiarity | | | || Performance | | | || Long-term Risk | | | |### Decision**Chosen:** [option]**Reasoning:** [why this fits our specific context]**Trade-offs accepted:** [what we give up]**Revisit if:** [conditions that would change this decision]```---## Build vs Buy Framework**Build when:**- This IS your core competitive differentiator- No existing solution fits well enough (>40% custom needed)- You have the expertise and time to maintain it**Buy / Use OSS when:**- It's infrastructure (auth, payments, email, queues)- Time-to-market is critical- Your users don't care who built the underlying tool- Maintenance would distract from core product**The hidden cost of building:** every line you write, you now own forever.---## Staying CurrentTrusted sources for staying up to date:- GitHub Trending (weekly)- State of JS / State of CSS surveys (annual)- Stack Overflow Developer Survey (annual)- Official release blogs of tools you use- Hacker News "Who's Hiring" (for industry signals)- Thoughtworks Technology Radar (strategic view)

Frequently asked questions

Tech Research