Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

project-scaffolding

Estrellas1

Forks0

Actualizado6 de junio de 2026 a las 03:00

Use when starting a new SaaS app or adding structure to one — sets up a Next.js (App Router) + TypeScript project with a sane folder layout, path aliases, server/client boundaries, and the conventions the rest of the stack builds on.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

param087

param087/saas-starter-skills

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

SKILL.md

readonly

name	project-scaffolding
description	Use when starting a new SaaS app or adding structure to one — sets up a Next.js (App Router) + TypeScript project with a sane folder layout, path aliases, server/client boundaries, and the conventions the rest of the stack builds on.

Project Scaffolding

Overview

A SaaS codebase lives or dies by its boundaries. Pick Next.js App Router + TypeScript and commit to one rule: business logic lives in server-only modules, the UI imports from a typed data-access layer, and secrets never cross into client components. Get the skeleton right and every later skill (auth, billing, jobs) slots in cleanly.

When to use

Bootstrapping a new SaaS app from zero.
An existing app has logic scattered across components and route handlers.
You need a layout that supports multi-tenancy, billing, and background jobs later.

Folder layout

src/
  app/                      # routes (App Router)
    (marketing)/            # public pages
    (app)/                  # authenticated app, wrapped in a layout that checks session
      [org]/                # tenant-scoped routes (see multi-tenancy)
    api/                    # route handlers (webhooks, integrations)
  server/                   # SERVER-ONLY. never imported by client components
    db/                     # schema + drizzle client (database-schema)
    services/               # business logic, one file per domain
    auth/                   # session helpers (authentication)
  lib/                      # isomorphic helpers (pure, no secrets)
  components/               # UI (ui/* are shadcn primitives)
  env.ts                    # typed env (environment-and-config)

Conventions that pay off

import "server-only" at the top of every file in server/ — turns a leaked import into a build error.
Path alias @/* → src/* in tsconfig.json so imports don't rot.
Server Actions for mutations, route handlers for webhooks/integrations. Don't build a REST layer you don't need.
One service per domain (server/services/billing.ts), called by actions and route handlers alike — never duplicate logic in the UI.
strict: true plus "noUncheckedIndexedAccess": true in tsconfig from day one; retrofitting strictness is misery.

Recommended baseline

npx create-next-app@latest --ts --app --tailwind --eslint
# then add: drizzle-orm + drizzle-kit, your auth lib, stripe, zod

Keep next.config minimal; add experimental.serverActions only if your version needs it.

Pitfalls

Putting DB calls in client components — they can't run there and you'll leak the connection string. Use the data-access layer + server components/actions.
A utils.ts dumping ground — split lib/ (pure) from server/ (privileged).
Deferring strict mode — every week without it adds any you'll never remove.
Route handlers for everything — Server Actions are less boilerplate for first-party mutations.
No route groups — mixing marketing and app routes makes auth layouts awkward.

Hand-off

A typed skeleton with clear server/client boundaries. Next: environment-and-config for typed secrets, then database-schema to model data.

Más de este repositorio

mismo repositorio

api-routes-and-validation

param087/saas-starter-skills

Use when building API endpoints or server actions — validate every input with zod, return consistent typed JSON errors, set correct status codes, and authenticate/authorize before touching data.

2026-06-061

authentication

param087/saas-starter-skills

Use when adding sign-in/sign-up or session handling to a SaaS app — set up Auth.js (NextAuth) or a hosted provider with secure sessions, OAuth + email, and server-side session checks that protect routes and actions.

2026-06-061

authorization-rbac

param087/saas-starter-skills

Use when controlling what a user may do — implement role-based access control with a central permission map, server-side checks on every mutation, and a typed `can()` helper instead of scattered role string comparisons.

2026-06-061

background-jobs

param087/saas-starter-skills

Use when work shouldn't run in the request path — offload emails, webhooks, exports, and scheduled tasks to a queue or job runner with retries, idempotency, and dead-letter handling instead of blocking the user.

2026-06-061

data-access-layer

param087/saas-starter-skills

Use when querying or mutating the database from the app — wrap Drizzle in server-only, tenant-scoped functions instead of calling the ORM from components, so every read/write is typed, testable, and isolation-safe.

2026-06-061

database-schema

param087/saas-starter-skills

Use when designing the Postgres schema or setting up Drizzle ORM — model users, organizations, memberships, and tenant-scoped tables with the right keys, indexes, timestamps, and migrations from day one.

2026-06-061

Project Scaffolding

Overview

When to use

Bootstrapping a new SaaS app from zero.

An existing app has logic scattered across components and route handlers.

You need a layout that supports multi-tenancy, billing, and background jobs later.

Folder layout

src/ app/ # routes (App Router) (marketing)/ # public pages (app)/ # authenticated app, wrapped in a layout that checks session [org]/ # tenant-scoped routes (see multi-tenancy) api/ # route handlers (webhooks, integrations) server/ # SERVER-ONLY. never imported by client components db/ # schema + drizzle client (database-schema) services/ # business logic, one file per domain auth/ # session helpers (authentication) lib/ # isomorphic helpers (pure, no secrets) components/ # UI (ui/* are shadcn primitives) env.ts # typed env (environment-and-config)

Conventions that pay off

import "server-only" at the top of every file in server/ — turns a leaked import into a build error.

Path alias @/* → src/* in tsconfig.json so imports don't rot.

Server Actions for mutations, route handlers for webhooks/integrations. Don't build a REST layer you don't need.

One service per domain (server/services/billing.ts), called by actions and route handlers alike — never duplicate logic in the UI.

strict: true plus "noUncheckedIndexedAccess": true in tsconfig from day one; retrofitting strictness is misery.

Recommended baseline

npx create-next-app@latest --ts --app --tailwind --eslint # then add: drizzle-orm + drizzle-kit, your auth lib, stripe, zod

Keep next.config minimal; add experimental.serverActions only if your version needs it.

Pitfalls

Putting DB calls in client components — they can't run there and you'll leak the connection string. Use the data-access layer + server components/actions.

A utils.ts dumping ground — split lib/ (pure) from server/ (privileged).

Deferring strict mode — every week without it adds any you'll never remove.

Route handlers for everything — Server Actions are less boilerplate for first-party mutations.

No route groups — mixing marketing and app routes makes auth layouts awkward.

Hand-off

A typed skeleton with clear server/client boundaries. Next: environment-and-config for typed secrets, then database-schema to model data.