agentleFS
sorawit-wsorawit-w/agent-skills/skills/tech-stack-recommendations/SKILL.md

tech-stack-recommendations

Skill2 starsChanged 5 months agoMITView on GitHub

Opinionated technology stack guidance for new projects and migrations. **You MUST use this skill whenever the user is starting a new project, picking a runtime (Bun/Deno/Node), choosing a frontend framework, database, auth provider, hosting platform, styling system, mobile stack, i18n library, or AI-agent framework that the project doesn't yet have, setting up a monorepo, or migrating between stacks.** Do not assume a stack decision is too obvious to need this skill — consult it before recommending any specific technology. Does NOT trigger on: debugging existing code, maintaining or extending the current stack's existing components, library-version or package-manager migrations within the same stack, configuring tools already installed, or 'how do I do X in [framework I already use]' questions.

  • Installs packages

The file

Show its rules and text

We split this skill into the rules it gives an agent

18 rules. About 0 are common, 16 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈16

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If the user's request is recent and the skill hasn't been updated in a while, flag the age — e.g., "this was written against 2026 tooling.

    line 30
  2. Distinctive:

    If a named framework is clearly deprecated or superseded, say so instead of recommending it.

    line 32
  3. Distinctive:

    State the override factors that apply: before recommending a stack.

    line 59
  4. Distinctive:

    Compliance and policy are vetoes, not tiebreakers: If self-hosting is mandatory, Clerk is out — don't argue.

    line 62
  5. Distinctive:

    If business requirements don't specify platforms, infer from the application's nature:

    line 71
  6. Distinctive:

    Rule: When in doubt, build web first.

    line 80
  7. Distinctive:

    After selecting a runtime, load any of these guides that apply to your project:

    line 147
  8. Distinctive:

    All monorepos follow this logical layout:

    line 190
  9. Very specific:

    Use Bun → load stacks/bun.md

    line 231
  10. Distinctive:

    All use Neon + Drizzle by default

    line 256
  11. Distinctive:

    Bun/Node: Use Expo for native feel

    line 275
  12. Distinctive:

    Web-first apps: Use Capacitor (wraps your web app)

    line 276
  13. Distinctive:

    Use this table if you're given conflicting requirements:

    line 283
  14. Distinctive:

    New TypeScript/JavaScript projects: Start with Bun (unless you have specific signals)

    line 300
  15. Distinctive:

    Monorepos: Use native workspaces (Bun) or Nx (Node)

    line 301
  16. Distinctive:

    Defaults rule: Use Bun + SvelteKit + Elysia + Neon + Drizzle + Clerk unless you have a reason not to

    line 302
  17. Distinctive:

    Unsure?: Default to Bun + SvelteKit + Elysia + Neon + Drizzle + Clerk

    line 337
  18. Very specific:

    Graceful degradation: if mcp-builder, web-artifacts-builder, or doc-coauthoring aren't installed, the stack recommendations in this skill …

    line 351

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Tech Stack Recommendations

Complete guide for choosing opinionated technology stacks for new projects and migrations. Read this first to pick your runtime, then load the appropriate reference guides below.


When to Use This Skill

  • New projects: Starting from scratch and need stack guidance
  • Stack migrations: Moving from Node → Bun, moving off Deno, etc.
  • Framework selection: Choosing between SvelteKit, Next.js, Angular, Nuxt, etc.
  • Architecture decisions: Building monorepos, multi-platform apps, or complex systems
  • Infrastructure choices: Selecting databases, auth, hosting, styling, mobile frameworks

NOT for: Existing projects with established stacks (unless actively migrating).


This Skill Has a Shelf Life

Framework ecosystems drift fast. The specific names in this skill (Bun, SvelteKit, Elysia, Neon, Drizzle, Clerk, etc.) reflect 2026-era tooling and will age. Before recommending any named tool:

  • If the user's request is recent and the skill hasn't been updated in a while, flag the age — e.g., "this was written against 2026 tooling; double-check pricing/status for [vendor] before committing."
  • For syntax or API details, defer to the project's current docs, not a snippet pasted from here.
  • If a named framework is clearly deprecated or superseded, say so instead of recommending it.

The shape of the advice (pick one runtime, name the override factors, prefer what the team can debug) ages more slowly than the specific names. Prefer the shape over the names when the two disagree.


This Skill Is Opinionated. Override When the Context Says So.

The defaults here (Bun + SvelteKit + Elysia + Neon + Drizzle + Clerk) are one person's taste, not universal truth. Before applying them, surface the context that should shift the recommendation, and say so out loud rather than silently enforcing the default.

Override the default runtime or framework when any of these apply:

FactorExample override
Team expertiseTeam has deep Angular/NestJS background → use Node + Next.js/Angular + Nx, not Bun.
Hiring poolHiring at scale in a market where Node is dominant → Node > Bun, even for greenfield.
Compliance / data residencySOC 2, HIPAA, GDPR with strict self-hosting or region pinning → prefer self-hostable auth (Ory, Supabase Auth, Lucia) over Clerk; prefer regionally-pinned DB over serverless Neon by default.
Vendor / third-party policyOrg forbids third-party auth providers → custom JWT (e.g. @elysiajs/jwt) or self-hosted Kratos.
Ecosystem maturityA required SDK is Node-only → use Node; don't contort Bun.
Runtime constraintsTarget is edge (Cloudflare Workers), or strictly AWS Lambda Node runtime → choose accordingly, not Bun by default.
Existing infraMonorepo already on pnpm + Nx, or org-wide CI assumes Node → extending that is usually cheaper than forking the toolchain.
Cost profile at scaleClerk's per-MAU pricing breaks at your scale → self-host. Neon autoscaling costs > a single RDS → switch.
Realtime / collaborative featuresSupabase (realtime channels) > Neon. Worth breaking the default DB choice.
Latency-sensitive global appsCloudflare Workers + Hono on the edge > Bun+SvelteKit on a single region.

Rules of thumb when applying this skill:

  1. State the override factors that apply before recommending a stack. Don't just output the default and hope no one notices.
  2. Name the trade-off. "Bun is faster, but your team is Node-fluent — picking Bun costs you ~2 weeks of ramp."
  3. Prefer the stack the team can debug over the one with the best benchmark. Developer fluency beats synthetic performance in almost every real project.
  4. Compliance and policy are vetoes, not tiebreakers. If self-hosting is mandatory, Clerk is out — don't argue.
  5. If you can't tell which factors apply, ask one crisp question (team makeup, compliance, deployment target, scale) rather than assuming the default is safe.

The default exists so small-team greenfield projects don't burn a week on stack selection. It is not a recommendation for every project that could technically run on it.


Platform Inference: What Should You Build?

If business requirements don't specify platforms, infer from the application's nature:

SignalSuggestsExample
On-the-go usage, notifications, offlineMobile (Expo)Ride-sharing, delivery, fitness tracking
Data-heavy dashboards, complex workflowsWeb (SvelteKit / Next.js)Analytics, CRM, project management
Consumer-facing product with users everywhereWeb + MobileSocial media, messaging, banking
Internal tool for staff onlyWeb onlyAdmin dashboards, internal workflows

Rule: When in doubt, build web first. Mobile can be added later via Expo (Bun/Node) or Capacitor (wraps any web build).


Runtime Selection: Bun vs. Cloudflare Workers vs. Node

Default: Bun for all new TypeScript/JavaScript projects.

RuntimeUse WhenStrengthsTrade-offs
Bun (default)Fast builds, modern stacksLightning-fast, native TS, built-in test runner, smallest footprintLimited ecosystem maturity; some packages missing
Cloudflare WorkersEdge-first, global low latencyRuns in every Cloudflare region, Hono runs natively, D1/KV bindingsPer-request CPU and memory limits; not every Node API; bindings tie you to Cloudflare
Node (Active LTS)Legacy compatibility, team expertiseMature ecosystem, stable, battle-tested toolingSlower than Bun, heavier

Decision tree (ask in this order; the first "yes" wins):

  1. Do you need edge deployment? → Use Cloudflare Workers + Hono
  2. Do you have legacy dependencies or Angular/NestJS expertise? → Use Node (Active LTS)
  3. Otherwise → Use Bun (default)

Do not recommend Deno for new projects. Cloudflare acquired Deno on 2026-10-09. Deno Deploy closes about six months later; the runtime gets about one year of security fixes, then active development ends. For a project already on Deno, load stacks/deno.md — it is a migration page, not a stack. If Deno's permission sandbox was the reason for choosing it, say plainly that no stack here replaces it: Node's --permission model guards trusted code against mistakes but its own docs say it is not a sandbox for untrusted code.

Pin your runtime version in .tool-versions or package.json → engines field.

Which Node version: the current Active LTS line, never one already in maintenance. That is Node 26 from 2026-10-28 (Node 24 enters maintenance on 2026-10-20). Check the Node release schedule before pinning.


Quick Stack Selection Matrix

Choose based on your primary use case and platform target:

Use CaseRecommended StackLoad Guide
New web + API (default)Bun + SvelteKit + Elysia + Neon + Drizzlestacks/bun.md
Edge-first, global low latencyCloudflare Workers + Hono + SvelteKit + Neon or D1 + Drizzlestacks/bun.md for tooling, then guides/hosting.md § Cloudflare Workers
Already on DenoMigrate off Denostacks/deno.md (migration page)
Large ecosystem or Angular/NestJSNode + Next.js + NestJS + Nx + Neon + Drizzlestacks/node.md
Need to choose a frontend frameworkLoad guides belowguides/frontend-frameworks.md
Choosing deployment platformLoad guides belowguides/hosting.md
Setting up database + authLoad guides belowguides/database-auth.md
Adding mobile supportLoad guides belowguides/mobile.md

Step 1: Choose Your Runtime

Load exactly one of these based on your signals:

FileWhen to LoadStack Includes
references/stacks/bun.mdMost new projects (default)Bun + SvelteKit + Elysia + Eden RPC + Neon + Drizzle + Clerk + Tailwind
references/stacks/node.mdLegacy compat, Angular, team expertiseNode (Active LTS) + Next.js/Angular + NestJS + Nx + Neon + Drizzle + Clerk + Tailwind

Edge-first projects load bun.md (Bun is the local package manager and test runner), then swap the API and hosting layers using guides/hosting.md § Cloudflare Workers: Hono instead of Elysia, Workers instead of Cloud Run.

Projects already on Deno load references/stacks/deno.md — a migration page with the shutdown timeline and a layer-by-layer move to Workers or Bun. Never load it to start a new project.

Each stack file includes:

  • Complete layer-by-layer stack overview
  • Monorepo setup (Bun Workspaces or Nx)
  • Standard project structure (apps/, packages/)
  • Quick-start commands

Step 2: Load Topic Guides On-Demand

After selecting a runtime, load any of these guides that apply to your project:

GuideLoad WhenFile
Frontend FrameworksChoosing between SvelteKit, Next.js, Astro, Remix, Angular, etc.references/guides/frontend-frameworks.md
Backend HostingSelecting deployment platform (Cloud Run, Railway, Vercel, Cloudflare Workers, etc.)references/guides/hosting.md
Database & AuthSetting up Postgres + Clerk (or Supabase, Turso alternatives)references/guides/database-auth.md
Styling & UISetting up Tailwind + component systems (shadcn/ui, shadcn-svelte, etc.)references/guides/styling.md
Mobile SupportAdding Expo, Capacitor, Flutter, or Dioxus to your monoreporeferences/guides/mobile.md
InternationalizationSetting up i18n (translations, locales, RTL support)references/guides/i18n.md
Font AwesomeUsing Font Awesome v7 icons in your stackreferences/guides/font-awesome.md
AI Coding Assistant ConfigSetting up Claude Code / skills / MCP for your repo (context files, .ai/ folder, tool definitions)references/guides/ai-agents.md
Building AI Agent ProductsOut of scope for this skill. This skill covers the web / backend / DB layer for an agent app, but NOT the agent framework itself. Use Claude Agent SDK, MCP, LangChain, or LlamaIndex per project needs.—

Monorepo Patterns: Pick One

Bun and Node both support monorepos with the same logical structure; edge-first (Workers) projects use Bun workspaces. Pick based on your runtime:

Bun Monorepos: Native Workspaces

{
  "name": "my-monorepo",
  "workspaces": ["apps/*", "packages/*"]
}

Command: bun install (installs all workspaces)

Node Monorepos: Nx + pnpm Workspaces

npx create-nx-workspace@latest my-monorepo --preset=apps

Command: pnpm install && nx serve web (runs specific app)


Standard App Structure

All monorepos follow this logical layout:

my-monorepo/
├── apps/
│   ├── web/              # Customer-facing web (SvelteKit / Next.js)
│   ├── mobile/           # Mobile app (Expo / Capacitor)
│   ├── admin/            # Internal admin dashboard
│   └── api/              # Backend API (Elysia / Hono / NestJS)
└── packages/             # Bun workspaces use this name
    └── shared/           # Shared types, utils, components

Workspace directory naming: Bun workspaces use packages/ (shown above). Nx (Node) uses libs/ instead — this is Nx's own default, and references/stacks/node.md follows it. Do not mix the two within one monorepo; pick the convention that matches your runtime's tooling.

When to include each app:

AppInclude When
apiAlways — backend is required
adminAlmost always — manage users, data, content
webMost customer-facing projects
mobileWhen users need on-the-go access (infer from signals above)

Rule: When in doubt, include admin — it's easier to remove later than add.


Decision Flow: Pick a Stack in 3 Steps

Step 1: Does your project need edge deployment?

  • Yes → Use Cloudflare Workers + Hono → load stacks/bun.md, then guides/hosting.md § Cloudflare Workers
  • No → Go to Step 2

(Already on Deno? Load stacks/deno.md to plan the move, then pick a destination with these steps.)

Step 2: Do you need large Node ecosystem or Angular/NestJS?

  • Yes → Use Node (Active LTS) → load stacks/node.md
  • No → Go to Step 3

Step 3: Proceed with default

  • Use Bun → load stacks/bun.md

After You Pick Your Stack

  1. Read your runtime stack file (Bun or Node; edge-first projects use Bun)
  2. Load topic guides on-demand as you make specific choices
  3. Initialize your monorepo using the command from your stack file
  4. Build your first app (usually api or web)
  5. Deploy using the hosting guide

Platform-Specific Rules

For Web Apps

  • Default frontend: SvelteKit (Bun) / Next.js (Node)
  • Default styling: Tailwind + Plain CSS
  • Load guides/frontend-frameworks.md if you want alternatives

For Backend APIs

  • Default (Bun): Elysia + Eden RPC (end-to-end types)
  • Default (Workers): Hono
  • Default (Node): NestJS with modules and DI
  • All use Neon + Drizzle by default

For Databases

  • Default: Neon (serverless Postgres) + Drizzle ORM
  • Alternative: Supabase, Turso, Prisma
  • Load guides/database-auth.md for detailed comparisons

For Authentication

  • Default: Clerk (best auth DX, 10k MAU free)
  • Override when: self-hosting is mandatory, strict data-residency rules apply, or policy bars third-party vendors. Alternatives: Supabase Auth (self-hostable), Ory Kratos, Lucia, Auth.js, or custom JWT (e.g. @elysiajs/jwt).
  • Load guides/database-auth.md for setup

For Deployment

  • Web frontends: Vercel (Next.js) or Cloud Run (SvelteKit)
  • APIs: Cloud Run (default) or Railway (MVP)
  • Edge-first apps: Cloudflare Workers
  • Load guides/hosting.md for deployment commands

For Mobile

  • Bun/Node: Use Expo for native feel
  • Web-first apps: Use Capacitor (wraps your web app)
  • Load guides/mobile.md for integration steps

Signals → Stack Recommendation Table

Use this table if you're given conflicting requirements:

SignalRecommendationRationale
"We're a startup building fast"Bun + SvelteKit + RailwayFastest iteration, smallest bundles
"We have legacy Angular code"Node + Angular + Nx + NestJSLeverage existing team expertise
"We need global edge deployment"Cloudflare Workers + Hono + SvelteKitBuilt for edge, global deploys
"We're on Deno today"Migrate — see stacks/deno.mdDeno Deploy closes ~2027-04; runtime fixes end ~2027-10
"We're migrating from Node to TypeScript"Bun + SvelteKit + Elysia10x faster builds, native TS
"We need OAuth + complex auth flows"Clerk + [any stack]Pre-built, battle-tested components
"We're building an admin dashboard"[Any stack] + Tailwind + shadcnFast, accessible component library
"We need real-time or collaborative features"Supabase (realtime) instead of NeonBuilt-in realtime subscriptions

Summary

  1. New TypeScript/JavaScript projects: Start with Bun (unless you have specific signals)
  2. Monorepos: Use native workspaces (Bun) or Nx (Node)
  3. Defaults rule: Use Bun + SvelteKit + Elysia + Neon + Drizzle + Clerk unless you have a reason not to
  4. Scope rule: Recommend only what the user asked for. If the ask is narrow — a CLI, a script, an AI agent, a library, a microservice — do NOT auto-scaffold the full-stack default. Name only the pieces needed; mention additional layers (persistence, auth, UI) as optional "when you need X."
  5. Load topic guides as needed: Backend hosting, frontend frameworks, mobile, etc.
  6. Build fast: This stack prioritizes developer experience and iteration speed

Reference Map

tech-stack-recommendations/
├── SKILL.md (you are here)
├── references/
│   ├── stacks/
│   │   ├── bun.md          # Bun + SvelteKit + Elysia + Neon + Drizzle
│   │   ├── deno.md         # Migration only — moving existing Deno projects off Deno
│   │   └── node.md         # Node + Next.js/Angular + NestJS + Nx
│   └── guides/
│       ├── frontend-frameworks.md    # SvelteKit vs Next.js vs Remix vs Angular
│       ├── hosting.md                # Cloud Run vs Railway vs Vercel vs Cloudflare Workers
│       ├── database-auth.md          # Neon + Clerk vs Supabase vs Turso
│       ├── styling.md                # Tailwind + Plain CSS + component systems
│       ├── mobile.md                 # Expo vs Capacitor vs Flutter
│       ├── i18n.md                   # Internationalization setup
│       ├── font-awesome.md           # Font Awesome v7 reference
│       └── ai-agents.md              # AI coding assistant config (skills, MCP, context files)

Need Help?

  • New project: Load your runtime stack file first (Bun / Node)
  • Migrating: Decide on new runtime, then load stack file
  • Specific choice (frontend, DB, auth, mobile): Load the matching topic guide
  • Unsure? Default to Bun + SvelteKit + Elysia + Neon + Drizzle + Clerk

Cross-Skill Integration

SkillWhen to Use
mcp-builder (Anthropic)When the stack decision includes building an MCP server — whether to expose tools from the chosen backend, or to author a custom connector. This skill picks the runtime/framework; mcp-builder owns MCP authoring conventions (FastMCP for Python, MCP SDK for Node/TS) and tool-design best practices.
web-artifacts-builder (Anthropic)When the recommendation is "prototype first, commit later" — e.g., a claude.ai artifact with React + shadcn/ui before scaffolding a full Next.js repo. This skill advises the long-term stack; web-artifacts-builder ships a same-day prototype against which the stack decision can be tested.
doc-coauthoring (Anthropic)When the founder/team wants the recommendation written up as an ADR (architecture decision record) or decision doc rather than a raw chat summary. Hand off after the choice is made; don't attempt long-form co-authoring inline.
team-composer (our own)When the stack decision is entangled with product, org, or operational constraints and a single-role recommendation isn't enough — e.g., @senior_software_architect + @platform_engineer + @security_engineer should weigh in together. Prefer team-composer when the question is "what stack fits this org" vs. "what's the best stack for this workload".
engineering:architecture (official)When the downstream need is a formal ADR with trade-offs and consequences. This skill's recommendation is upstream — a sharp-ended opinion — and feeds into that ADR.

Graceful degradation: if mcp-builder, web-artifacts-builder, or doc-coauthoring aren't installed, the stack recommendations in this skill still stand. The referenced skills are handoff destinations, not hard dependencies.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.