ESCANEAR el entorno, identificar información faltante y producir un plan de arquitectura ANTES de escribir código. Previene la generación de código sin contexto, suposiciones incorrectas de stack y funcionalidades subespecificadas. Activadores: el usuario dice "create a new project", "build an app", "start a new repo", "build a dashboard", "build a saas", o cualquier solicitud de crear desde cero.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
Project Intake
description
ESCANEAR el entorno, identificar información faltante y producir un plan de arquitectura ANTES de escribir código. Previene la generación de código sin contexto, suposiciones incorrectas de stack y funcionalidades subespecificadas. Activadores: el usuario dice "create a new project", "build an app", "start a new repo", "build a dashboard", "build a saas", o cualquier solicitud de crear desde cero.
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":"EJECUTAR flujo de ingesta antes de cualquier código"},{"pattern":"start (a|a new) (project|app|repo)","action":"EJECUTAR flujo de ingesta antes de cualquier código"},{"pattern":"(build|scaffold|set up) (a|an) (dashboard|saas|api|website)","action":"EJECUTAR flujo de ingesta antes de cualquier código"}]
El usuario solicita construir un proyecto NUEVO desde cero
El usuario solicita una nueva funcionalidad IMPORTANTE que cambia la arquitectura
El directorio actual está vacío (greenfield) o no tiene archivos de configuración
NO activar cuando:
El usuario está modificando código existente (corrección de error, refactorización, cambio de estilo)
Requirements-discovery-framework ya está completo
DECIDIR: Ruta de Ejecución
SI proyecto greenfield (directorio vacío) →
EJECUTAR Pasos 1-3 (escaneo de entorno → info faltante → plan de arquitectura)
LUEGO implementar usando habilidades de dominio
SI proyecto brownfield (base de código existente) →
EJECUTAR Pasos 1-4 (escaneo de entorno → info faltante → plan → igualar patrones)
LUEGO implementar siguiendo convenciones EXISTENTES
SI requirements-discovery-framework ya se ejecutó →
SALTAR Paso 2 (info faltante ya identificada)
EJECUTAR Pasos 1, 3, 4
LUEGO implementar
EJECUTAR: Instrucciones
Paso 1: Escanear Entorno
Leer estos archivos (NO ejecutar ls o cat, usar herramienta read_files):
tsconfig.json o jsconfig.json, detectar alias de ruta, modo strict
next.config.ts o next.config.mjs, detectar configuración Next.js
tailwind.config.ts o directiva CSS @theme, detectar solución de estilos (archivo de configuración Tailwind v3 o CSS nativo v4)
docker-compose.yml, detectar configuración de contenedores
.env.example, detectar variables de entorno requeridas
directorio .github/, detectar configuración CI
Reglas clave de detección (2026):
Tailwind: Verificar `@import "tailwindcss"` o `@theme` en CSS → v4 (configuración CSS nativa)
Verificar tailwind.config.ts → v3 (configuración heredada)
Next.js: Verificar next.config.ts → App Router asumido
Verificar directorio app/ → App Router confirmado
Verificar solo directorio pages/ → Pages Router
Verificar proxy.ts (reemplaza middleware.ts en Next.js 16)
Auth: Verificar auth.ts o auth.config.ts → Auth.js o Better Auth
Base de datos: Verificar schema.prisma → Prisma
Verificar drizzle.config.ts → Drizzle
Verificar directorio supabase/ → Supabase
Gestor de paquetes: Verificar pnpm-lock.yaml → pnpm
Verificar yarn.lock → yarn (clásico) o yarn.lock + .yarnrc.yml → yarn berry
Verificar bun.lock → bun
Verificar package-lock.json → npm
Monorepo: Verificar turbo.json → Turborepo
Verificar nx.json → Nx
Verificar workspace: en package.json → espacios de trabajo pnpm/npm
Herramienta de compilación: Verificar vite.config.ts → Vite (cualquier versión)
Verificar next.config.ts → Next.js (Turbopack incluido en v16)
Paso 2: Identificar Información Faltante
Después del escaneo, determinar qué sigue siendo desconocido. Usar el Marco de Descubrimiento de Requisitos para solicitudes vagas, o preguntar directamente por detalles específicos aquí.
SIEMPRE aclarar estas incógnitas bloqueantes:
[ ] Elección de framework, si no es detectable desde los archivos
[ ] Requisito de autenticación, "¿Los usuarios necesitan iniciar sesión?" (Cambia la arquitectura significativamente)
[ ] Persistencia de datos, "¿Necesita base de datos? ¿Preferencia?"
[ ] Objetivo de despliegue, "¿Dónde se despliega?" (Vercel / AWS / Docker / otro)
Aclarar si el alcance del proyecto lo justifica:
[ ] Escala de usuarios esperada → <10 / 10-1K / 1K-100K / 100K+
[ ] Requisito de accesibilidad → ¿Se necesita WCAG 2.2 AA?
[ ] Sensibilidad de datos → ¿PII? ¿Pagos? ¿HIPAA? ¿SOC2?
[ ] Soporte de navegador → ¿Solo modernos? ¿Legados?
NUNCA preguntar sobre: colores de UI, elecciones de fuentes, valores exactos de espaciado, funcionalidades que el usuario no mencionó.
Paso 3: Producir Plan de Arquitectura
Escribir este plan antes de cualquier código de implementación. Usar exactamente esta estructura:
Leer 2-3 archivos existentes por categoría y seguir EXACTAMENTE las convenciones:
Patrones API: Forma del envoltorio de respuesta, formato de error, ubicación de validación, uso de códigos de estado
Patrones de componentes: Componentes de Servidor vs Cliente, convención de nomenclatura, estilo de importación, biblioteca UI
Infraestructura: Comandos del gestor de paquetes, configuración de pruebas (Vitest/Jest/Playwright/ninguno), linting (ESLint/Biome)
REGLA: Si las rutas existentes usan envoltorio { data, meta } → tus rutas DEBEN usar el mismo.
REGLA: Si los componentes existentes usan exportaciones por defecto → tus componentes DEBEN usar exportaciones por defecto.