SW Tech Stack Planner
Overview
Reads all available requirements files and recommends the best modern, production-ready tech stack for the project. Outputs a clean YAML file at requirements/tech-stack.yaml. Operates silently – no file content shown in the chat.
Language detection: Read the user's input language and respond in that language. Default to German if undetectable.
Required Input – Check in Order
Read all files that exist and combine the information:
requirements/vision.md– project type, complexity, target audiencerequirements/user-stories.md– feature scope, integrations neededrequirements/use-cases.md– flows, actor interactions, edge cases
If none exist and no input is given, stop and respond:
No requirements files found. Run
/sw-idea-analyzerfirst, or describe your project directly:/sw-tech-stack-planner <your description>
Stack Selection Rules
Single-App vs Monorepo
| Use single-app when | Use monorepo when |
|---|---|
| Only one frontend or one backend | Frontend + backend share types or are developed together |
| Simple project, one deployment unit | Multiple apps (web + mobile, web + API + worker) |
| Starter / hobby project | Team works across all parts simultaneously |
| No shared code between services | Shared packages (shared types, UI lib, utils) |
Default to single-app. Only recommend monorepo when the use cases clearly show multiple co-deployed apps.
Set structure: monorepo in tech-stack.yaml and note the implied workspace setup (apps/web/, apps/api/, packages/) so /sw-boilerplate generates the right root layout.
Always Docker-First
Every recommendation must include:
- Full
docker-compose.ymlready to run withdocker compose up - All services (database, cache, backend, frontend) in containers
- Named volumes for data persistence
- Environment variables via
.envfile (never hardcoded) - Health checks on database services
Database
| Project type | Default choice |
|---|---|
| Relational data, complex queries | PostgreSQL |
| Simple relational, small project | MySQL / MariaDB |
| Cache, sessions, queues | Redis (always add if backend has async work) |
| Document / flexible schema | MongoDB |
| Multi-model / graph | Neo4j or ArangoDB |
Always include Testcontainers when the language/framework supports it (Java, Kotlin, Go, .NET, Node.js).
Frontend
| Signal from requirements | Recommendation |
|---|---|
| Complex UI, dashboard, SPA | Next.js 15 (App Router) + TypeScript |
| Static / content site | Astro or Next.js static export |
| Mobile app | React Native + Expo |
| Admin panel only | shadcn/ui + Next.js |
| Simple form / landing page | Next.js or plain HTML |
Backend
| Signal from requirements | Recommendation |
|---|---|
| REST API, moderate complexity | NestJS (Node.js) or FastAPI (Python) |
| High performance, concurrency | Go (Gin / Fiber) or Rust (Axum) |
| Enterprise / Java shop | Spring Boot 3 |
| Full-stack in one repo | Next.js API routes or tRPC |
| Real-time / websockets | NestJS + Socket.io |
| Data-heavy / ML pipeline | FastAPI + Celery |
Auth
| Requirement | Choice |
|---|---|
| SaaS, social login, managed | Clerk or Auth.js |
| Self-hosted, full control | Keycloak (Docker) |
| Simple JWT, own users | NestJS JWT + Passport or Spring Security |
Testing
Always recommend a layered testing strategy:
- Unit: Jest / Vitest (TS), pytest (Python), JUnit 5 (Java)
- Integration: Testcontainers (real DB in Docker per test run)
- E2E: Playwright
- API: Supertest (NestJS) or httpx (FastAPI)
Deployment
| Scale | Choice |
|---|---|
| Small / hobby | Coolify (self-hosted) or Railway |
| Production / team | Docker Compose on VPS + Traefik reverse proxy |
| Kubernetes scale | Helm chart on k3s or managed K8s |
| Serverless preference | Vercel (frontend) + Supabase (backend) |
Output Format
Write requirements/tech-stack.yaml with these exact sections:
project:
name: ""
type: "" # web-app | api | mobile | cli | fullstack
structure: "" # single-app | monorepo
complexity: "" # simple | medium | complex
frontend:
framework: ""
language: ""
ui_library: ""
state_management: ""
notes: ""
backend:
framework: ""
language: ""
runtime: ""
notes: ""
database:
primary: ""
cache: ""
orm: ""
migrations: ""
auth:
solution: ""
strategy: "" # jwt | session | oauth
notes: ""
testing:
unit: ""
integration: ""
e2e: ""
api: ""
testcontainers: true | false
deployment:
strategy: ""
reverse_proxy: ""
ci_cd: ""
registry: ""
docker:
compose_version: "" # leave empty — Compose V2 doesn't require a version field
services: [] # list all service names
volumes: []
networks: []
rationale:
frontend: "" # 1-2 sentences why this choice
backend: ""
database: ""
auth: ""
deployment: ""
Output Rules
- Never output the YAML or any file content in the chat.
- Do not show tech stack details, code blocks, or configuration in the chat response.
- The only chat output allowed is the confirmation lines.
- Use the user's language in the
rationalefield values.
File Output
Steps:
- If
requirements/does not exist:mkdir -p requirements - Analyze all available inputs and select the best stack
- Write the complete YAML to
requirements/tech-stack.yaml - Print only these lines to the chat:
✅ File created:
requirements/tech-stack.yamlThis is now the official tech stack for all following coding skills.
One optional summary sentence max (e.g. "Recommended Next.js 15 + NestJS + PostgreSQL + Docker stack with Testcontainers."). No YAML, no code blocks, no full output.
Next Skill
▶ Next steps:
- Run
/sw-boilerplateto scaffold the full project skeleton from this tech-stack.yaml- Then run
/sw-use-case-coder UC-001(orall MVP) to generate production-ready code for use cases