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, dependenciestsconfig.json or jsconfig.json, detect path aliases, strict modenext.config.ts or next.config.mjs, detect Next.js configtailwind.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)
Step 2: Identify Missing Information
After the scan, determine what's still unknown. Use the Requirements Discovery Framework for vague requests, or directly ask for specifics here.
ALWAYS clarify these blocking unknowns:
[ ] Framework choice, if not detectable from files
[ ] Auth requirement, "Do users need to log in?" (Changes architecture significantly)
[ ] Data persistence, "Need a database? Preference?"
[ ] Deployment target, "Where deployed?" (Vercel / AWS / Docker / other)
Clarify if project scope warrants:
[ ] Expected user scale → <10 / 10-1K / 1K-100K / 100K+
[ ] Accessibility requirement → WCAG 2.2 AA needed?
[ ] Data sensitivity → PII? Payments? HIPAA? SOC2?
[ ] Browser support → Modern only? Legacy?
NEVER ask about: UI colors, font choices, exact spacing values, features the user didn't mention.
Step 3: Produce Architecture Plan
Write this plan before any implementation code. Use exactly this structure:
ARCHITECTURE PLAN
Framework: [Next.js 16 / Vite 8 / Nuxt / other], [App Router / Pages Router]
Styling: [Tailwind v4 / CSS Modules / styled-components / other]
Language: [TypeScript 6.0], strict mode: [YES/NO]
Database: [PostgreSQL / SQLite / Supabase / none], ORM: [Prisma 7 / Drizzle / none]
Auth: [Better Auth / Auth.js / Clerk / none]
Deployment: [Vercel / Railway / Docker / AWS / other]
Package Mgr: [pnpm / npm / yarn / bun]
Monorepo: [YES/NO], tool: [Turborepo / Nx / workspaces]
ROUTES / PAGES:
- [path] → [description]
- [path] → [description]
DATA MODEL (preliminary):
- [table] ([columns...])
- [table] ([columns...])
KEY DECISIONS:
- [choice] because [rationale]
- [choice] because [rationale]
Step 4: Match Existing Patterns (Brownfield Only)
Read 2-3 existing files per category and follow EXACT conventions:
API patterns: Response envelope shape, error format, validation location, status code usage
Component patterns: Server vs Client Components, naming convention, import style, UI library
Infrastructure: Package manager commands, test setup (Vitest/Jest/Playwright/none), linting (ESLint/Biome)
RULE: If existing routes use { data, meta } envelope → your routes MUST use the same.
RULE: If existing components use default exports → your components MUST use default exports.
Step 5: Create ADR (Significant Choices Only)
For non-obvious architectural decisions, create docs/adr/NNN-title.md:
# ADR NNN: [Title]
**Status**: Accepted
**Date**: YYYY-MM-DD
**Decision**: [chosen option]
**Reasons**:
- [reason 1]
- [reason 2]
**Alternatives considered**:
- [alternative A]: [why rejected]
- [alternative B]: [why rejected]
**Consequences**:
- [tradeoff accepted]
- [new maintenance burden]
- [limitation imposed]
VALIDATE: Quality Gates
Before writing implementation code:
OUTPUT: What This Skill Produces
{
"architecturePlan": {
"framework": "string with version",
"styling": "string with version",
"language": "TypeScript 6.0",
"database": { "type": "string", "orm": "string" },
"auth": "string",
"deployment": "string",
"packageManager": "pnpm | npm | yarn | bun",
"isMonorepo": false,
"routes": [{ "path": "string", "description": "string" }]
ANTI-PATTERNS: ALWAYS Avoid
| Anti-Pattern | Detection Signal | Correction |
|---|
| Starting code immediately | User asks for project, you start creating files | Run Steps 1-3 first |
| 10+ questions in one message | Question list exceeds 3 | Batch to max 3 per message |
| Mocking data instead of asking about backend | You create fake API data | Ask if real API/database exists |
| Assuming deployment platform | You default to Docker, user wanted Vercel | Ask if not specified |
| Creating files before checking existing | You create duplicate config | Always read existing files first |
