Tech Scout

Technology scouting and evaluation skill. Systematically discovers, evaluates, and compares technical options to support informed technology decisions.

Trigger Words

• /tech-scout
• "evaluate this technology"
• "compare these frameworks"
• "what are the options for"
• "build vs buy"
• "technology assessment"
• "find alternatives to"
• "scout technologies"

Quick Start

1. Define the technical need and constraints
2. Discover candidate technologies
3. Establish evaluation criteria with weights
4. Evaluate each candidate against criteria
5. Produce comparison matrix and recommendation

Core Workflow

Tech Scout Progress:
- [ ] Step 1: Define need and constraints
- [ ] Step 2: Candidate discovery
- [ ] Step 3: Evaluation criteria
- [ ] Step 4: Deep evaluation
- [ ] Step 5: Comparison matrix
- [ ] Step 6: Recommendation

Step 1: Define Need and Constraints

## Technical Need
- Problem to solve: [description]
- Current solution (if any): [what exists today]
- Why change is needed: [pain points]

## Constraints
| Constraint | Value | Flexibility |
|-----------|-------|-------------|
| Budget | [amount] | [hard/soft] |
| Timeline | [timeframe] | [hard/soft] |
| Team skills | [languages/frameworks] | [hard/soft] |
| Scale requirements | [users/requests/data] | [hard/soft] |
| Integration needs | [systems to integrate with] | [hard/soft] |
| Compliance/Security | [requirements] | [hard/soft] |

Step 2: Candidate Discovery

Search strategy:

1. Known options: Technologies the team already knows about
2. Market leaders: Top solutions by adoption/market share
3. Rising contenders: Newer options gaining traction
4. Open-source alternatives: Community-driven options
5. Unconventional approaches: Different paradigms that solve the same problem

For each candidate, capture:

| # | Technology | Category | Maturity | License | Last Release |
|---|-----------|----------|----------|---------|-------------|
| 1 | [name] | [category] | [early/growth/mature/declining] | [license] | [date] |

Step 3: Evaluation Criteria

Standard criteria (customize per evaluation):

Customization rules:

• Weights must sum to 100%
• Minimum 5 criteria, maximum 10
• At least one criterion must address risk/security
• Weights should reflect the specific decision context

Step 4: Deep Evaluation

For each candidate, evaluate:

## [Technology Name]

### Overview
- What it is: [one sentence]
- Primary use case: [intended purpose]
- Architecture: [key design decisions]

### Strengths
1. [strength with evidence]
2. [strength with evidence]

### Weaknesses
1. [weakness with evidence]
2. [weakness with evidence]

### Scores
| Criterion | Score (1-5) | Justification |
|-----------|-------------|---------------|
| Functionality fit | [1-5] | [why] |
| Performance | [1-5] | [why] |
| ... | ... | ... |

### Risk Assessment
- Vendor lock-in risk: [low/medium/high]
- Technology obsolescence risk: [low/medium/high]
- Migration difficulty (if switching later): [low/medium/high]

### Notable
- [Any standout feature or concern not captured above]

Step 5: Comparison Matrix

## Comparison Matrix

| Criterion (Weight) | Option A | Option B | Option C |
|-------------------|----------|----------|----------|
| Functionality (25%) | 4 (1.00) | 3 (0.75) | 5 (1.25) |
| Performance (15%) | 3 (0.45) | 5 (0.75) | 4 (0.60) |
| Dev Experience (15%) | 5 (0.75) | 3 (0.45) | 3 (0.45) |
| Community (10%) | 4 (0.40) | 5 (0.50) | 2 (0.20) |
| Maintenance (10%) | 4 (0.40) | 4 (0.40) | 3 (0.30) |
| Security (10%) | 3 (0.30) | 4 (0.40) | 4 (0.40) |
| Integration (10%) | 4 (0.40) | 3 (0.30) | 3 (0.30) |
| Cost (5%) | 5 (0.25) | 2 (0.10) | 3 (0.15) |
| **Weighted Total** | **3.95** | **3.65** | **3.65** |

Format: raw_score (weighted_score) where weighted_score = raw_score × weight

Step 6: Recommendation

## Recommendation

### Primary Recommendation: [Technology]
- Weighted score: [X.XX]
- Key reasons: [top 2-3 differentiators]
- Risk mitigation: [how to address top risks]

### Runner-Up: [Technology]
- When to choose this instead: [specific conditions]

### Not Recommended: [Technology]
- Why not: [key disqualifiers]

### Implementation Considerations
- Migration path from current solution: [approach]
- Estimated adoption timeline: [timeframe]
- Key risks to monitor: [risks]
- Success metrics: [how to know it's working]

Build vs Buy Decision Template

When the evaluation is specifically build-vs-buy:

## Build vs Buy Analysis

| Factor | Build | Buy |
|--------|-------|-----|
| Upfront cost | [estimate] | [estimate] |
| Annual maintenance | [estimate] | [estimate] |
| Time to production | [estimate] | [estimate] |
| Customization | Full control | [level] |
| Competitive advantage | [yes/no - why] | N/A |
| Team capacity | [impact on team] | [minimal] |
| 3-year TCO | [total] | [total] |

### Recommendation: [Build/Buy]
[Reasoning]

Integration with Other Skills

• Use deep-research for in-depth background on specific technologies
• Use research-analyst for market and ecosystem analysis
• Use deep-think for complex architectural trade-offs
• Feed results to brainstorm for implementation approaches

Anti-Patterns

• Do NOT evaluate only one option (minimum 2 candidates)
• Do NOT use subjective scoring without justification
• Do NOT ignore total cost of ownership (focus only on license cost)
• Do NOT skip risk assessment
• Do NOT recommend based on hype or popularity alone
• Do NOT ignore the team's existing skills and constraints