opencode-workflow/skills/evaluate_tech_stack/SKILL.md

---
name: evaluate_tech_stack
description: "Evaluate and recommend technology stack including language, framework, database, queue, cache, and infrastructure. Document pros, cons, and justification for each choice. A deliverable skill referenced by design-architecture."
---

This skill provides guidance and format requirements for evaluating and recommending the technology stack within the architecture document.

This is a deliverable skill, not a workflow skill. It is referenced by `design-architecture` when evaluating technology choices.

## Purpose

The Architect must evaluate the technology stack for the system, considering requirements from the PRD, existing systems, team expertise, and operational constraints. Each technology choice must be justified with pros, cons, and rationale.

## Technology Stack Evaluation Format

When evaluating the technology stack for a feature, produce a structured evaluation for each stack layer:

```markdown
### {Layer}: {Technology}

- **Pros**:
  - {Specific advantage relevant to this use case}
  - {Another advantage}

- **Cons**:
  - {Specific disadvantage relevant to this use case}
  - {Another disadvantage}

- **Why Chosen**:
  - {Specific rationale tied to PRD requirements}
  - {Why this technology is the best fit for this use case}

- **Alternatives Considered**:
  - {Alternative 1}: {Brief reason why not chosen}
  - {Alternative 2}: {Brief reason why not chosen}
```

## Evaluation Layers

### Language
- Primary programming language for each service
- Justification based on: ecosystem, performance, team expertise, library support
- Consider: type safety, concurrency model, deployment size, development velocity

### Framework
- Application framework for each service
- Justification based on: maturity, community, performance, developer experience
- Consider: built-in features, middleware ecosystem, testing support, documentation

### Database
- Primary and secondary databases
- Justification based on: data model fit, query patterns, write patterns, consistency requirements, scale expectations
- Consider: ACID vs eventual consistency, operational complexity, backup/restore, migration path

### Queue / Message Broker
- Message queue or event streaming platform
- Justification based on: throughput requirements, ordering guarantees, delivery semantics, durability
- Consider: at-least-once vs exactly-once, partitioning, consumer groups, operational complexity

### Cache
- Caching layer
- Justification based on: access patterns, TTL requirements, invalidation strategy
- Consider: cache-aside vs read-through/write-through, memory limits, persistence options

### Infrastructure
- Deployment infrastructure
- Justification based on: scalability, cost, team expertise, deployment model
- Consider: containerization, orchestration, service mesh, CDN, monitoring

## Decision Principles

When evaluating technology choices, prioritize:

1. **Simplicity**: Choose the simplest technology that meets requirements
2. **Battle-tested**: Prefer technologies with proven production track records
3. **Team expertise**: Prefer technologies the team already knows, unless the learning curve is justified
4. **Operational maturity**: Prefer technologies with good monitoring, tooling, and debugging support
5. **Community and ecosystem**: Prefer technologies with active communities and rich ecosystems
6. **Fit for purpose**: Choose technologies that match the specific data model, access pattern, and consistency requirements

## Anti-Patterns

Avoid:
- Choosing technologies based on hype or fashion without PRD justification
- Choosing different technologies for each service without good reason (polyglot penalty)
- Choosing bleeding-edge technologies without a fallback plan
- Choosing technologies that require significant operational investment without clear benefit
- Choosing technologies that don't match the data model or access pattern

## Knowledge Contract Reference

This deliverable skill works alongside the `storage-knowledge` and `architecture-patterns` knowledge contracts:
- `storage-knowledge` provides detailed comparison of storage technologies
- `architecture-patterns` provides guidance on which patterns suit which technologies

## Anti-Placeholder Rule

Examples in this skill are illustrative only. Do not reuse placeholder technologies, justifications, or alternatives unless explicitly required by the PRD. Every technology selection, justification, and alternative must be grounded in actual requirements and reflect real evaluation for this system.

## Embedding in Architecture Document

Technology stack evaluation must be embedded within the `## System Architecture` section (Technology Stack subsection) of `docs/architecture/{feature}.md`.

For significant technology decisions that affect the overall system structure, also document them as ADRs in the `## ADR` section.

Do NOT produce separate evaluation documents. All technology evaluations must be within the single architecture document.