opencode-workflow/skills/evaluate_tech_stack/SKILL.md

name	description
evaluate_tech_stack	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:

### {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.