project-intake

name	Project Intake
description	SCAN environment, identify missing information, and produce an architecture plan BEFORE writing code. Prevents context-free code generation, wrong stack assumptions, and underspecified features. Trigger: user says "create a new project", "build an app", "start a new repo", "build a dashboard", "build a saas", or any request to scaffold from scratch.
category	foundation
version	3.0.0
last_updated	2026-06-28T00:00:00.000Z
stacks	["All"]
triggers	[{"pattern":"create a new (project|app|repo|application)","action":"RUN intake workflow before any code"},{"pattern":"start (a|a new) (project|app|repo)","action":"RUN intake workflow before any code"},{"pattern":"(build|scaffold|set up) (a|an) (dashboard|saas|api|website)","action":"RUN intake workflow before any code"}]
related_skills	["requirements-discovery-framework","full-stack-file-tree-architecture","database-schema-design","saas-app-structure"]

Professional Project Intake

IDENTIFY: When to Activate

Activate this skill when:

• User requests building a NEW project from scratch
• User requests a MAJOR new feature that changes architecture
• Current directory is empty (greenfield) or has no config files

Do NOT activate when:

• User is modifying existing code (bug fix, refactor, style change)
• Requirements-discovery-framework is already complete

DECIDE: Execution Path

IF greenfield project (empty directory) →
  RUN Steps 1-3 (environment scan → missing info → architecture plan)
  THEN implement using domain skills

IF brownfield project (existing codebase) →
  RUN Steps 1-4 (environment scan → missing info → architecture plan → match patterns)
  THEN implement following EXISTING conventions

IF requirements-discovery-framework already executed →
  SKIP Step 2 (missing info already identified)
  RUN Steps 1, 3, 4
  THEN implement

EXECUTE: Instructions

Step 1: Scan Environment

Read these files (do NOT run ls or cat, use read_files tool):

Required reads:

• package.json, detect framework, scripts, dependencies
• tsconfig.json or jsconfig.json, detect path aliases, strict mode
• next.config.ts or next.config.mjs, detect Next.js config
• tailwind.config.ts or CSS @theme directive, detect styling solution (Tailwind v3 config file or v4 CSS-native)
• docker-compose.yml, detect container setup
• .env.example, detect required env vars
• .github/ directory, detect CI setup

Key detection rules (2026):

Tailwind:    Check for `@import "tailwindcss"` or `@theme` in CSS → v4 (CSS-native config)
             Check for tailwind.config.ts → v3 (legacy config)
Next.js:     Check for next.config.ts → App Router assumed
             Check for app/ directory → App Router confirmed
             Check for pages/ directory only → Pages Router
             Check for proxy.ts (replaces middleware.ts in Next.js 16)
Auth:        Check for auth.ts or auth.config.ts → Auth.js or Better Auth
Database:    Check for schema.prisma → Prisma
             Check for drizzle.config.ts → Drizzle
             Check for supabase/ directory → Supabase
Package Mgr: Check for pnpm-lock.yaml → pnpm
             Check for yarn.lock → yarn (classic) or yarn.lock + .yarnrc.yml → yarn berry
             Check for bun.lock → bun
             Check for package-lock.json → npm
Monorepo:    Check for turbo.json → Turborepo
             Check for nx.json → Nx
             Check for workspace: in package.json → pnpm/npm workspaces
Build Tool:  Check for vite.config.ts → Vite (any version)
             Check for next.config.ts → Next.js (bundled Turbopack in v16)