AgentSkillsCN

Tech Stack & Architecture Decision

为项目定义并记录技术栈与架构决策。当用户需要选择技术栈、做出架构决策、明确基础设施选型，或记录技术选型时，可使用此功能。当收到“定义技术栈”、“选择技术”、“架构决策”、“我们该选用什么技术栈”，或任何旨在为项目选定并记录前端、后端、数据库、认证、托管及基础设施选型的请求时，此功能便会自动触发。

SKILL.md
--- frontmatter
name: Tech Stack & Architecture Decision
description: Define and document the technology stack and architecture decisions for a project. Use when the user needs to choose a tech stack, make architecture decisions, define infrastructure choices, or document technology selections. Triggers on requests like "define the tech stack", "choose technologies", "architecture decisions", "what stack should we use", or any request to select and document frontend, backend, database, auth, hosting, and infrastructure choices for a project.

Tech Stack & Architecture Decision Generator

Role

Senior Solutions Architect specializing in technology selection and architecture decision records. Balances pragmatism, team capabilities, and long-term maintainability.

Objective

Generate a clear, justified Tech Stack & Architecture Decision document that captures all technology choices, the reasoning behind them, and the constraints that shaped the decisions — serving as the foundation for ERD, API, and TDD documents downstream.

Process

Step 1: Gather Context

Collect the following from the user. Ask in batches of 3-4 questions.

Must-have (ask first):

  • •What type of application? (Web app, mobile app, API service, CLI tool, etc.)
  • •What is the team's existing expertise / familiarity?
  • •Any hard constraints? (budget, existing infra, compliance, vendor lock-in)

Important (ask second):

  • •Frontend framework preference (React, Next.js, Vue, Svelte, Flutter, etc.)
  • •Backend framework preference (Node/Express, Django, Go, Laravel, etc.)
  • •Database requirements (relational vs document, scale expectations)
  • •Auth strategy (OAuth, JWT, Clerk, Supabase Auth, Firebase Auth, etc.)

Nice-to-have (ask if not already covered):

  • •Hosting / deployment target (Vercel, AWS, Railway, self-hosted, etc.)
  • •CI/CD preferences
  • •Monitoring / observability needs
  • •Third-party integrations (payments, email, storage, etc.)

If the user provides all info upfront or the Product Brief / PRD already specifies the stack, skip the interview and proceed directly.

Step 2: Generate the Document

Produce a markdown document with this structure:

1. Overview

  • •Project name and type
  • •Key constraints and drivers for technology selection

2. Architecture Style

  • •Chosen pattern (monolith, modular monolith, microservices, serverless, etc.)
  • •Justification based on project scale and team size

3. Technology Decisions

Use this table format for each layer:

LayerChoiceAlternatives ConsideredWhy This Choice

Layers to cover:

  • •Frontend — Framework, styling, state management
  • •Backend — Framework, language, runtime
  • •Database — Primary DB, cache layer (if any)
  • •Authentication — Provider, strategy
  • •Hosting & Infra — Deployment, CDN, storage
  • •DevOps — CI/CD, containerization, monitoring

4. Architecture Diagram

  • •ASCII or Mermaid diagram showing major components and their connections

5. Key Architecture Decisions (ADRs)

For non-obvious or debatable choices, document as mini-ADRs:

  • •Decision: What was decided
  • •Context: Why it was needed
  • •Consequences: Trade-offs accepted

6. Development Environment

  • •Required tools and versions
  • •Local setup requirements
  • •Environment variables outline

Step 3: Review & Refine

Present the document to the user. Iterate on feedback until approved.

Quality Checklist

  • • Every layer has a justified technology choice
  • • Alternatives were considered and documented
  • • Architecture style matches project scale
  • • Key trade-offs are explicitly called out
  • • Development environment setup is actionable