create-apppaaaul 2.0.35 → 2.0.39
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/templates/nextjs-ts-clean/project/%%.gitignore +6 -3
- package/dist/templates/nextjs-ts-clean/project/AGENTS.md +60 -0
- package/dist/templates/nextjs-ts-landing-prisma/project/%%.gitignore +1 -4
- package/dist/templates/nextjs-ts-landing-prisma/project/AGENTS.md +60 -0
- package/package.json +1 -1
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
## Convenciones
|
|
2
|
+
- Usa pnpm para todo. No usar npm ni yarn bajo ningún concepto
|
|
3
|
+
- TypeScript es obligatorio
|
|
4
|
+
- Usa siempre Tailwind CSS para estilos
|
|
5
|
+
- Iconos de tabler-icons. Importación explícita, nunca barrels
|
|
6
|
+
- Preferir ESM y sintaxis moderna del navegador
|
|
7
|
+
|
|
8
|
+
## Creación de proyectos
|
|
9
|
+
- Si hay que crear un proyecto nuevo, usa Nextjs
|
|
10
|
+
- Configura TypeScript en modo estricto desde el inicio
|
|
11
|
+
- Añade Tailwind usando la integración oficial de Nextjs
|
|
12
|
+
- No añadir dependencias hasta que sean necesarias
|
|
13
|
+
|
|
14
|
+
## Organización
|
|
15
|
+
- Componentes pequeños, con una sola responsabilidad
|
|
16
|
+
- Preferir composición frente a configuraciones complejas
|
|
17
|
+
- Evita abstracciones prematuras
|
|
18
|
+
- El código compartido debe vivir en carpetas claras como `components`, `layouts`, `lib` o `utils`
|
|
19
|
+
|
|
20
|
+
## Reglas de TypeScript
|
|
21
|
+
- Evita `any` y `unknown`
|
|
22
|
+
- Preferir siempre que se pueda inferencia
|
|
23
|
+
- Si los tipos no están claros, parar y aclarar antes de continuar
|
|
24
|
+
|
|
25
|
+
## UI y estilos
|
|
26
|
+
- Tailwind es la única solución de estilos
|
|
27
|
+
- No duplicar clases si se puede extraer un componente
|
|
28
|
+
- Priorizar legibilidad frente a micro-optimizaciones visuales
|
|
29
|
+
- Accesibilidad no es opcional: HTML semántico, roles ARIA cuando aplique y foco gestionado
|
|
30
|
+
|
|
31
|
+
## Testing y calidad
|
|
32
|
+
- Revisar los workflows de CI en `.github/workflows`.
|
|
33
|
+
- Ejecutar los tests con:
|
|
34
|
+
`pnpm test` o `pnpm turbo run test --filter <project_name>`
|
|
35
|
+
- Para Vitest:
|
|
36
|
+
`pnpm vitest run -t "<nombre del test>"`
|
|
37
|
+
- Tras mover archivos o cambiar imports, ejecutar:
|
|
38
|
+
`pnpm lint`
|
|
39
|
+
- No se acepta código con errores de tipos, lint o tests fallidos.
|
|
40
|
+
- Añadir o actualizar tests cuando se cambie comportamiento, aunque no se pida explícitamente.
|
|
41
|
+
|
|
42
|
+
## Rendimiento y decisiones técnicas
|
|
43
|
+
- No adivinar rendimiento, tamaño de bundle o tiempos de carga: medir.
|
|
44
|
+
- Si algo parece lento, añadir instrumentación antes de optimizar.
|
|
45
|
+
- Validar primero en pequeño antes de escalar cambios a todo el proyecto.
|
|
46
|
+
|
|
47
|
+
## Commits y Pull Requests
|
|
48
|
+
- Título del PR: [<project_name>] Descripción clara y concisa.
|
|
49
|
+
- PRs pequeños y enfocados.
|
|
50
|
+
- Antes de commitear:
|
|
51
|
+
- pnpm lint
|
|
52
|
+
- pnpm test
|
|
53
|
+
- Explicar qué ha cambiado, por qué y cómo se ha verificado.
|
|
54
|
+
- Si se introduce una nueva restricción ("nunca X", "siempre Y"), documentarla en este archivo.
|
|
55
|
+
|
|
56
|
+
## Comportamiento del agente
|
|
57
|
+
- Si una petición no está clara, hacer preguntas concretas antes de ejecutar.
|
|
58
|
+
- Tareas simples y bien definidas se ejecutan directamente.
|
|
59
|
+
- Cambios complejos (refactors, nuevas features, decisiones de arquitectura) requieren confirmar entendimiento antes de actuar.
|
|
60
|
+
- No asumir requisitos implícitos. Si falta información, se pide.
|
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
## Convenciones
|
|
2
|
+
- Usa pnpm para todo. No usar npm ni yarn bajo ningún concepto
|
|
3
|
+
- TypeScript es obligatorio
|
|
4
|
+
- Usa siempre Tailwind CSS para estilos
|
|
5
|
+
- Iconos de tabler-icons. Importación explícita, nunca barrels
|
|
6
|
+
- Preferir ESM y sintaxis moderna del navegador
|
|
7
|
+
|
|
8
|
+
## Creación de proyectos
|
|
9
|
+
- Si hay que crear un proyecto nuevo, usa Nextjs
|
|
10
|
+
- Configura TypeScript en modo estricto desde el inicio
|
|
11
|
+
- Añade Tailwind usando la integración oficial de Nextjs
|
|
12
|
+
- No añadir dependencias hasta que sean necesarias
|
|
13
|
+
|
|
14
|
+
## Organización
|
|
15
|
+
- Componentes pequeños, con una sola responsabilidad
|
|
16
|
+
- Preferir composición frente a configuraciones complejas
|
|
17
|
+
- Evita abstracciones prematuras
|
|
18
|
+
- El código compartido debe vivir en carpetas claras como `components`, `layouts`, `lib` o `utils`
|
|
19
|
+
|
|
20
|
+
## Reglas de TypeScript
|
|
21
|
+
- Evita `any` y `unknown`
|
|
22
|
+
- Preferir siempre que se pueda inferencia
|
|
23
|
+
- Si los tipos no están claros, parar y aclarar antes de continuar
|
|
24
|
+
|
|
25
|
+
## UI y estilos
|
|
26
|
+
- Tailwind es la única solución de estilos
|
|
27
|
+
- No duplicar clases si se puede extraer un componente
|
|
28
|
+
- Priorizar legibilidad frente a micro-optimizaciones visuales
|
|
29
|
+
- Accesibilidad no es opcional: HTML semántico, roles ARIA cuando aplique y foco gestionado
|
|
30
|
+
|
|
31
|
+
## Testing y calidad
|
|
32
|
+
- Revisar los workflows de CI en `.github/workflows`.
|
|
33
|
+
- Ejecutar los tests con:
|
|
34
|
+
`pnpm test` o `pnpm turbo run test --filter <project_name>`
|
|
35
|
+
- Para Vitest:
|
|
36
|
+
`pnpm vitest run -t "<nombre del test>"`
|
|
37
|
+
- Tras mover archivos o cambiar imports, ejecutar:
|
|
38
|
+
`pnpm lint`
|
|
39
|
+
- No se acepta código con errores de tipos, lint o tests fallidos.
|
|
40
|
+
- Añadir o actualizar tests cuando se cambie comportamiento, aunque no se pida explícitamente.
|
|
41
|
+
|
|
42
|
+
## Rendimiento y decisiones técnicas
|
|
43
|
+
- No adivinar rendimiento, tamaño de bundle o tiempos de carga: medir.
|
|
44
|
+
- Si algo parece lento, añadir instrumentación antes de optimizar.
|
|
45
|
+
- Validar primero en pequeño antes de escalar cambios a todo el proyecto.
|
|
46
|
+
|
|
47
|
+
## Commits y Pull Requests
|
|
48
|
+
- Título del PR: [<project_name>] Descripción clara y concisa.
|
|
49
|
+
- PRs pequeños y enfocados.
|
|
50
|
+
- Antes de commitear:
|
|
51
|
+
- pnpm lint
|
|
52
|
+
- pnpm test
|
|
53
|
+
- Explicar qué ha cambiado, por qué y cómo se ha verificado.
|
|
54
|
+
- Si se introduce una nueva restricción ("nunca X", "siempre Y"), documentarla en este archivo.
|
|
55
|
+
|
|
56
|
+
## Comportamiento del agente
|
|
57
|
+
- Si una petición no está clara, hacer preguntas concretas antes de ejecutar.
|
|
58
|
+
- Tareas simples y bien definidas se ejecutan directamente.
|
|
59
|
+
- Cambios complejos (refactors, nuevas features, decisiones de arquitectura) requieren confirmar entendimiento antes de actuar.
|
|
60
|
+
- No asumir requisitos implícitos. Si falta información, se pide.
|