Configura la plantilla de contexto para Claude Code
- Agrega CLAUDE.md como documento orquestador - Estructura .claude/ en codigo/, decisiones/ y referencias/ - Documenta decisiones de codigo, commits, documentacion, notas y minutas - Incorpora las skills recontextualizar e inicializarProyecto - Corrige rutas rotas y agrega designPatterns, sobreCLAUDE y sobreREADME al orquestador
This commit is contained in:
@@ -0,0 +1,29 @@
|
||||
# Patrones de diseño para Claude Code
|
||||
|
||||
> Las decisiones generales de código están en [codigo.md](../decisiones/codigo.md).
|
||||
|
||||
## Cómo usar este archivo
|
||||
- Antes de implementar un patrón, consultar aquí si el proyecto ya definió cómo aplicarlo.
|
||||
- Si el patrón no está listado, proponerlo al usuario antes de implementarlo; no improvisar variantes.
|
||||
|
||||
## Patrones creacionales
|
||||
- **Factory Method / Abstract Factory** — cuándo usarlo, convención de nombres del proyecto.
|
||||
- **Builder** — para objetos con muchos parámetros opcionales (ver [codigo.md](../decisiones/codigo.md) sobre nombres claros).
|
||||
- **Singleton** — restringido a: (conexión a base de datos, configuración global). Motivo: evitar abuso como reemplazo de inyección de dependencias.
|
||||
|
||||
## Patrones estructurales
|
||||
- **Adapter** — para integrar librerías externas sin acoplar el resto del código.
|
||||
- **Facade** — para exponer una interfaz simple sobre un subsistema complejo (ej. capa de acceso a datos).
|
||||
- **Repository** — patrón de acceso a datos si el proyecto usa base de datos; separar consultas de la lógica de negocio.
|
||||
|
||||
## Patrones de comportamiento
|
||||
- **Strategy** — cuando existan variantes intercambiables de un algoritmo.
|
||||
- **Observer** — para eventos o notificaciones entre componentes desacoplados.
|
||||
- **Chain of Responsibility** — para validaciones o middlewares en cadena.
|
||||
|
||||
## Patrones arquitectónicos (si aplica al stack)
|
||||
- **MVC / MVVM** — según el framework elegido en el stack tecnológico de [CLAUDE.md](../../CLAUDE.md).
|
||||
- **Capas (Controller-Service-Repository)** — separación entre entrada, lógica de negocio y persistencia.
|
||||
|
||||
## Registro de decisiones del proyecto
|
||||
- A medida que se elija un patrón concreto para un caso real del proyecto, documentar aquí: qué problema resuelve, dónde se aplicó, y por qué se descartaron alternativas.
|
||||
@@ -0,0 +1,12 @@
|
||||
# Decisiones globales de comportamiento para Claude Code
|
||||
**Los lineamientos a seguir por los modelos de Claude se alojan en este archivo.**
|
||||
|
||||
1. CLAUDE.md sirve como documento guia que orquestra .claude entre otras cosas como las etapas que se deben seguir
|
||||
|
||||
2. .claude/ es donde vive toda la documentación necesaria para que los modelos puedan trabajar y guardar las referncias de código y demás documentación que entiendan necearia
|
||||
|
||||
2.1. .claude/codigo/ Aquí vive lo que sea necesario para que los modelos coordinen correctamente los aspectos del código.
|
||||
|
||||
2.2. .claude/decisiones/ Es donde el usuario pauta las decisiones tomadas que deben ser respetadas por el agente de IA. Este archivo explica las decisiones globales del proyecto; las decisiones específicas de código están en [codigo.md](codigo.md).
|
||||
|
||||
2.3. .claude/referencias/ Contiene archivos que pueden ser resumenes o textos que sirven para que el modelo se guíe en determinados momentos, al evaluar las prácticas de programación por ejemplo.
|
||||
@@ -0,0 +1,25 @@
|
||||
# Decisiones en cuanto a código para Claude Code
|
||||
|
||||
> Las decisiones generales del proyecto están en [DECISIONS.md](DECISIONS.md).
|
||||
|
||||
## Buenas prácticas de programación
|
||||
- El modelo de Claude deberá siempre que desarrolle código apegarse a las buenas prácticas de pogramación establecidas por la comunidad.
|
||||
- 'Clean code' por Robert C. Martin es la referencia principal en cuanto a buenas prácticas en el desarrollo de proyectos como este. Un archivo con un resumen de los aspectos principales del libro está en .claude/references/clean_code_RobertCMartin.md
|
||||
Referencia "principal" en este sentido quiere decir que a medida que se vayan cargando nuevas referencias es posible que se encuentren contradicciones, en ese caso las prácticas de 'Clean code' por Robert C. Martin tienen prioridad.
|
||||
|
||||
## Estilo del usuario
|
||||
- Los nombres de las variables, métodos y clases se deben escribir en formato **camelCase** .
|
||||
- Los nombres de las variables, métodos y clases deben reflejar el nombre claro de lo que se quiere representar:
|
||||
- `const configuracionDb = {...}`
|
||||
- `async function verificarConexion() {...}`
|
||||
- `async function resolverUuidUsuario() {...}`
|
||||
- Hay casos donde se aplican excepciones como si una buenas práctica o una práctica habitual es escribir de una manera especifica algo que es practicamente un estandar como las clases en Java, en ese caso no usamos camelCase, usamos las buenas prácticas de programación.
|
||||
- `public class Algoritmo {...}`
|
||||
- `public class Conexion {...}`
|
||||
- En caso de trabajar con digramas que documenten lo desarrollado en una base de datos usaremos los nombres reservados por los lenguajes de programación para los tipos de datos.
|
||||
- Ej: `STRING` en lugar de "CADENA"
|
||||
- Ej: `INTEGER` en lugar de "ENTERO"
|
||||
|
||||
## Scripts de uso puntual de Claude Code
|
||||
- Los scripts que crea Claude Code para una tarea puntual (generar artefactos, transformar datos, etc.) y que **no forman parte del proyecto** se crean dentro de `.claude/codigo/scripts/`.
|
||||
- Motivo: separar las herramientas internas del agente del código.
|
||||
@@ -0,0 +1,6 @@
|
||||
# Decisiones en cuanto a los commits creados por Claude Code
|
||||
|
||||
- Los commits deben ser sencillos de leer por humanos.
|
||||
- No deben firmarse por la IA (a menos que se indique lo contrario).
|
||||
- Deben reflejar la etapa en la que se está trabajando.
|
||||
- Ej / Referencia: [ejemplo_commit.md](../referencias/ejemplo_commit.md).
|
||||
@@ -0,0 +1,21 @@
|
||||
# Decisiones en cuanto a la documentación creada por Claude Code
|
||||
|
||||
## README.md
|
||||
- El archivo README.md no se utilizará como archivo que incorpore un índice sobre la documentación del proyecto.
|
||||
- Este archivo README.md contendrá un resumen de la organización de las etapas del proyecto, plazos por etapa, planes de acción por etapa, requisitos indispensables establecidos por los docentes.
|
||||
- Más información sobre como construir el archivo [README.md](README.md) en [.claude/decisiones/sobreREADME.md](.claude/decisiones/sobreREADME.md)
|
||||
|
||||
## Estilos
|
||||
- Si el usuario no indica lo contrario usar Markdown como tipo de documento predeterminado para crear documentación.
|
||||
- No se usarán emojis en la documentación
|
||||
- No se firmará como en colaboración con IA
|
||||
|
||||
## Índices
|
||||
- Todos los grandes directorios de documentación deberán contar con un índice.
|
||||
- En [Indice.md](docs/Indice.md) se encontrará el índice que mantiene actualizada la documentación de cada etapa.
|
||||
|
||||
## Estructura
|
||||
- Es posible que a medida que se avance con las etapas la documentación crezca y se haga insostenible tener todo dentro de un único archivo con la documentación.
|
||||
- Dentro de la carpeta [docs/](docs) va a alojarse la documentación.
|
||||
- Dentro de [docs/](docs) encontraremos sub-carpetas correspondientes a cada hito, [Hito 1](docs/H1/) es una de ella.
|
||||
- Dentro de cada sub-carpeta de etapa habrán archivos que corresponderán a secciones, estas secciones pueden definirse anteriormente al iniciar una nueva etapa dentro de [secciones.md](docs/H1/secciones.md) o puede actualizarse a medida que se vayan creando las secciones si no se precargó.
|
||||
@@ -0,0 +1,21 @@
|
||||
# Decisiones en cuanto a las minutas de sesión de trabajo creadas por Claude Code
|
||||
|
||||
## Evitar la mención de ajustes de configuracione de Claude o del repositorio
|
||||
- No es relevante para registrar en la minuta las acciones realizadas dentro de .claude o CLAUDE.md o de caracter IA.
|
||||
- Evitar cualquier punto que mencione la IA, en caso de haber trabajado en conjunto únicamente mencionar sobre lo que se trabajó.
|
||||
|
||||
## Nombre del archivo sobre el cual guardar la minuta de trabajo
|
||||
- Minuta_00N_DD-MM-YYYY
|
||||
- Donde N en el número de la minuta - 001, 005
|
||||
|
||||
## Pequeño recuadro con información sobre la minuta
|
||||
- Campo y Detalle
|
||||
- **Fecha** Fecha de la minuta en formato DD-MM-YYYY
|
||||
- **Duración estimada** Duración estimada de la sesión de trabajo. Suele rondar las 2 horas.
|
||||
- **Etapa** Etapa sobre la que se trabajó en la sesión de trabajo, pese a estar atrasado o adelantado del cronograma
|
||||
|
||||
## Títulos que deberán aparecer en la minuta con doble almohadilla.
|
||||
- Temas tratados
|
||||
- Decisiones tomadas
|
||||
- Tareas pendientes de la etapa actual
|
||||
- Proxima sesión prevista
|
||||
@@ -0,0 +1,8 @@
|
||||
# Decisiones en cuanto a los comentarios creados por Claude Code
|
||||
|
||||
- No se debe usar emojis.
|
||||
- Debe ser claro y usar la menor cantidad de comentarios posibles.
|
||||
- Si existe un archivo o sección de un archivo que documente el funcionamiento del código que se creó ajustar esa documentación en lugar de agregar un comentario sobre el código.
|
||||
|
||||
> Las decisiones sobre la forma de escribir en la documentación está en [documentacion.md](documentacion.md).
|
||||
> Las decisiones sobre la forma de escribir los commits está en [commits.md](commits.md).
|
||||
@@ -0,0 +1,17 @@
|
||||
# Acerca de la construicción adecuada de [CLAUDE.md](CLAUDE.md)
|
||||
|
||||
- En este archivo se encontraran las decisiones tomadas sobre como se organizará el archivo [CLAUDE.md](CLAUDE.md).
|
||||
- Es posible y recomendable modificar este archivo para que refleje el conteneido de [CLAUDE.md](CLAUDE.md) a medida que el proyecto avance. Esto es solo una plantilla para ayudarle a empezar.
|
||||
|
||||
## Guías para Claude al ajustar [CLAUDE.md](CLAUDE.md)
|
||||
- Estamos hablando de una archivo que routea y orquestra al agente hacia [.claude/](.claude) donde encontrará deciciones, ajustes respecto al código, referencias para tomar como ejemplo.
|
||||
|
||||
## Estructura
|
||||
- Una sección '# Datos generales del proyecto' que incluirá aspectos globales a todo proyecto. 1. **Nombre:** 2. **Repositorio oficial:** 3. **Institución:** puede ser una organización o un particular
|
||||
- Equipo trabajando sobre el desarrollo '## Equipo' que incluirá nombres de los integrantes con **Integrantes: ** Nombre y Apellido
|
||||
- Otra sección '## Descripción general' incluirá entre 1 o 2 párafos describiendo el proyecto.
|
||||
- Sección '## Stack tecnológico' donde se incluirán detalles como tecnologías utilizadas, versiones especificas de lenguajes o frameworks, así como herramientas utilizadas.
|
||||
- Sección de '## Restricciones técnicas obligatorias de programación' donde se especifican desde el vamos del proyecto restricciones para el desarrollo.
|
||||
- Sección '## Etapas del proyecto' puede ser dificil al comienzo pero si el poroyecto avanza será neceario organizar y planear tiempos.
|
||||
- Sección '## Complejidad esperada' es una nota del usuario hacia el agente de IA para basarse sobre una linea de compleijidad, no es lo mismo un proyecto que se desarrolla en los tiempos libres a un proyecto de empresa que necesita cumplir ciertos strandares.
|
||||
- Sección '## Notas de trabajo' incluirá un redireccionamiento
|
||||
@@ -0,0 +1,7 @@
|
||||
# Acerca de la construicción adecuada de [README.md](README.md)
|
||||
|
||||
En este archivo se encontraran las decisiones tomadas sobre como se organizará el archivo [README.md](README.md).
|
||||
- Es posible y recomendable modificar este archivo para que refleje el conteneido de [README.md](README.md) a medida que el proyecto avance. Esto es solo una plantilla para ayudarle a empezar.
|
||||
|
||||
## Guías para Claude al ajustar [README.md](README.md)
|
||||
- Estamos hablando de una archivo que es la puerta de entrada a usuarios interesados en el proyecto, donde encontrarán la información más importante del proyecto, plazos del proyecto, una guía sobre como usar o implementar los servicios que levanta el código.
|
||||
@@ -0,0 +1,88 @@
|
||||
Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.
|
||||
_____________________________________
|
||||
|
||||
## General rules
|
||||
1. Follow standard conventions.
|
||||
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
|
||||
3. Boy scout rule. Leave the campground cleaner than you found it.
|
||||
4. Always find root cause. Always look for the root cause of a problem.
|
||||
|
||||
## Design rules
|
||||
1. Keep configurable data at high levels.
|
||||
2. Prefer polymorphism to if/else or switch/case.
|
||||
3. Separate multi-threading code.
|
||||
4. Prevent over-configurability.
|
||||
5. Use dependency injection.
|
||||
6. Follow Law of Demeter. A class should know only its direct dependencies.
|
||||
|
||||
## Understandability tips
|
||||
1. Be consistent. If you do something a certain way, do all similar things in the same way.
|
||||
2. Use explanatory variables.
|
||||
3. Encapsulate boundary conditions. Boundary conditions are hard to keep track of. Put the processing for them in one place.
|
||||
4. Prefer dedicated value objects to primitive type.
|
||||
5. Avoid logical dependency. Don't write methods which works correctly depending on something else in the same class.
|
||||
6. Avoid negative conditionals.
|
||||
|
||||
## Names rules
|
||||
1. Choose descriptive and unambiguous names.
|
||||
2. Make meaningful distinction.
|
||||
3. Use pronounceable names.
|
||||
4. Use searchable names.
|
||||
5. Replace magic numbers with named constants.
|
||||
6. Avoid encodings. Don't append prefixes or type information.
|
||||
|
||||
## Functions rules
|
||||
1. Small.
|
||||
2. Do one thing.
|
||||
3. Use descriptive names.
|
||||
4. Prefer fewer arguments.
|
||||
5. Have no side effects.
|
||||
6. Don't use flag arguments. Split method into several independent methods that can be called from the client without the flag.
|
||||
|
||||
## Comments rules
|
||||
1. Always try to explain yourself in code.
|
||||
2. Don't be redundant.
|
||||
3. Don't add obvious noise.
|
||||
4. Don't use closing brace comments.
|
||||
5. Don't comment out code. Just remove.
|
||||
6. Use as explanation of intent.
|
||||
7. Use as clarification of code.
|
||||
8. Use as warning of consequences.
|
||||
|
||||
## Source code structure
|
||||
1. Separate concepts vertically.
|
||||
2. Related code should appear vertically dense.
|
||||
3. Declare variables close to their usage.
|
||||
4. Dependent functions should be close.
|
||||
5. Similar functions should be close.
|
||||
6. Place functions in the downward direction.
|
||||
7. Keep lines short.
|
||||
8. Don't use horizontal alignment.
|
||||
9. Use white space to associate related things and disassociate weakly related.
|
||||
10. Don't break indentation.
|
||||
|
||||
## Objects and data structures
|
||||
1. Hide internal structure.
|
||||
2. Prefer data structures.
|
||||
3. Avoid hybrids structures (half object and half data).
|
||||
4. Should be small.
|
||||
5. Do one thing.
|
||||
6. Small number of instance variables.
|
||||
7. Base class should know nothing about their derivatives.
|
||||
8. Better to have many functions than to pass some code into a function to select a behavior.
|
||||
9. Prefer non-static methods to static methods.
|
||||
|
||||
## Tests
|
||||
1. One assert per test.
|
||||
2. Readable.
|
||||
3. Fast.
|
||||
4. Independent.
|
||||
5. Repeatable.
|
||||
|
||||
## Code smells
|
||||
1. Rigidity. The software is difficult to change. A small change causes a cascade of subsequent changes.
|
||||
2. Fragility. The software breaks in many places due to a single change.
|
||||
3. Immobility. You cannot reuse parts of the code in other projects because of involved risks and high effort.
|
||||
4. Needless Complexity.
|
||||
5. Needless Repetition.
|
||||
6. Opacity. The code is hard to understand.
|
||||
@@ -0,0 +1,57 @@
|
||||
{
|
||||
"$schema": "https://json.schemastore.org/claude-code-settings.json",
|
||||
|
||||
"permissions": {
|
||||
"allow": [
|
||||
"Bash(node *)",
|
||||
"Bash(npm *)",
|
||||
"Bash(npx *)",
|
||||
"Bash(yarn *)",
|
||||
"Bash(pnpm *)",
|
||||
|
||||
"Bash(python *)",
|
||||
"Bash(python3 *)",
|
||||
"Bash(pip *)",
|
||||
"Bash(pip3 *)",
|
||||
"Bash(pytest *)",
|
||||
"Bash(uv *)",
|
||||
"Bash(poetry *)",
|
||||
|
||||
"Bash(make *)",
|
||||
|
||||
"Bash(docker *)",
|
||||
"Bash(docker compose *)"
|
||||
],
|
||||
|
||||
"deny": [
|
||||
"Bash(git *)",
|
||||
|
||||
"Read(.env)",
|
||||
"Read(.env.*)",
|
||||
|
||||
"Read(**/.ssh/**)",
|
||||
"Read(**/.aws/**)",
|
||||
"Read(**/secrets/**)",
|
||||
|
||||
"Read(**/*.pem)",
|
||||
"Read(**/*.key)",
|
||||
"Read(**/*.p12)",
|
||||
"Read(**/*.pfx)",
|
||||
|
||||
"Bash(sudo *)",
|
||||
"Bash(rm -rf /)",
|
||||
"Bash(reboot *)",
|
||||
"Bash(shutdown *)"
|
||||
]
|
||||
},
|
||||
|
||||
"tools": {
|
||||
"allowed": ["Read", "Bash", "Write", "WebSearch"]
|
||||
},
|
||||
|
||||
"env": {
|
||||
"NODE_ENV": "development",
|
||||
"PYTHONUNBUFFERED": "1",
|
||||
"PYTHONDONTWRITEBYTECODE": "1"
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
name: inicializarProyecto
|
||||
description: Inicializa el proyecto cargando por lenguaje natural los datos indispensables (nombre, institución, stack, etapas, complejidad, entre otros) y los vuelca en las secciones de CLAUDE.md. Úsala cuando el proyecto sea una plantilla recién clonada, o cuando los campos de "Datos generales del proyecto" en CLAUDE.md estén vacíos o incompletos y el usuario quiera completarlos.
|
||||
---
|
||||
|
||||
# Inicializar el proyecto
|
||||
|
||||
Esta skill completa los datos iniciales indispensables del proyecto conversando con el usuario en lenguaje natural y volcando el resultado en la sección `# Datos generales del proyecto` de `CLAUDE.md`. A diferencia de [recontextualizar](../recontextualizar/SKILL.md), sí edita archivos, pero solo para rellenar esos datos; no toca decisiones, referencias ni código.
|
||||
|
||||
`CLAUDE.md` es el documento orquestador. La estructura y el significado de cada sección están definidos en [sobreCLAUDE.md](../../decisiones/sobreCLAUDE.md), documento vinculante que se debe respetar al escribir. También aplican las decisiones de [documentacion.md](../../decisiones/documentacion.md) (Markdown, sin emojis, sin firma de IA) y de [codigo.md](../../decisiones/codigo.md) (camelCase en nombres) para cualquier identificador o ejemplo que se genere.
|
||||
|
||||
## Antes de empezar
|
||||
|
||||
1. Lee el estado actual. Lee `CLAUDE.md` completo y [sobreCLAUDE.md](../../decisiones/sobreCLAUDE.md). Identifica qué campos ya están completos y cuáles vacíos. No sobrescribas datos ya cargados sin confirmación del usuario.
|
||||
2. No inventes datos. Todo campo indispensable proviene del usuario. Si un dato aún no lo sabe, déjalo vacío y anótalo como pendiente; no lo rellenes con suposiciones.
|
||||
|
||||
## Datos a recoger
|
||||
|
||||
Recorre estas secciones de `CLAUDE.md`, definidas en `sobreCLAUDE.md`. Pregunta de a grupos temáticos, en lenguaje natural, evitando un interrogatorio campo por campo:
|
||||
|
||||
1. Identidad del proyecto: nombre, repositorio oficial, institución (organización o particular).
|
||||
2. Equipo: integrantes con nombre y apellido. Mateo Saldain ya figura; consulta si hay más.
|
||||
3. Descripción general: uno o dos párrafos sobre qué es y qué resuelve el proyecto.
|
||||
4. Stack tecnológico: lenguajes con versiones si las hay, base de datos, build, testing, herramientas.
|
||||
5. Restricciones técnicas obligatorias de programación: tecnologías obligadas o prohibidas, límites del entorno, requisitos de docentes o cliente.
|
||||
6. Etapas del proyecto: etapas o hitos con sus plazos y objetivos en la medida en que el usuario los conozca. Es esperable que al inicio estén parcialmente definidas; captura lo disponible.
|
||||
7. Complejidad esperada: línea de complejidad de referencia (proyecto de tiempo libre frente a estándar de empresa o curso).
|
||||
|
||||
Para campos con opciones acotadas, como la complejidad esperada o la elección entre stacks candidatos, usa `AskUserQuestion`. Para descripciones y listados abiertos, conversa en texto libre.
|
||||
|
||||
## Pasos
|
||||
|
||||
1. Muestra el estado inicial. Resume brevemente qué campos están vacíos y cuáles ya tienen datos.
|
||||
2. Recoge los datos por grupos temáticos según la lista anterior. Confirma dudas antes de escribir y deja constancia de lo que quede pendiente.
|
||||
3. Vuelca los datos en `CLAUDE.md`, en sus secciones correspondientes, respetando la estructura de `sobreCLAUDE.md` y el estilo de `documentacion.md`. No alteres las secciones `## Guías para Claude Code` ni `## Reglas del proyecto`.
|
||||
4. No ejecutes Git. Rige la regla del proyecto de nunca ejecutar comandos de Git. Si el usuario quiere versionar la inicialización, pídele que lo haga manualmente.
|
||||
|
||||
## Salida esperada
|
||||
|
||||
- Confirmación de qué secciones de `CLAUDE.md` quedaron completadas.
|
||||
- Lista de datos pendientes que el usuario aún no proporcionó, para retomarlos luego.
|
||||
- Sugerencia de correr [recontextualizar](../recontextualizar/SKILL.md) si quiere reflejar el nuevo contexto en la sesión.
|
||||
|
||||
No completes campos con datos inventados ni edites archivos fuera de `CLAUDE.md` salvo que el usuario lo pida.
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
name: recontextualizar
|
||||
description: Relee CLAUDE.md y toda la carpeta .claude/ para refrescar el contexto del proyecto SIENEP. Úsala cuando el usuario indique que es momento de actualizar el contexto, tras agregar o modificar decisiones, pautas de código, referencias, o nuevas secciones en CLAUDE.md o .claude/.
|
||||
---
|
||||
|
||||
# Recontextualizar el proyecto
|
||||
|
||||
Esta skill recarga el contexto de trabajo releyendo el documento orquestador `CLAUDE.md` y toda la carpeta `.claude/`. Es de **solo lectura**: no edites archivos salvo que el usuario lo pida explícitamente.
|
||||
|
||||
`CLAUDE.md` es el documento orquestador; `.claude/` contiene el detalle. Los roles de cada carpeta están definidos en `.claude/decisiones/DECISIONS.md`:
|
||||
- `.claude/codigo/` — coordinación de aspectos del código (build, arquitectura, reglas).
|
||||
- `.claude/decisiones/` — decisiones del usuario que **debes respetar** (no renegociar); divididas en `DECISIONS.md` (proyecto y organización del contexto) y `codigo.md` (desarrollo de código).
|
||||
- `.claude/referencias/` — material de apoyo para evaluar prácticas de programación (ej. Clean Code).
|
||||
|
||||
## Pasos
|
||||
|
||||
1. **Descubre todos los archivos de contexto.** Lista de forma recursiva `.claude/` (`find .claude -type f` o glob equivalente) y registra `CLAUDE.md`. No asumas que solo existen las carpetas/archivos ya conocidos: detecta archivos, carpetas o secciones nuevas.
|
||||
|
||||
2. **Lee CLAUDE.md completo.** Identifica secciones nuevas o modificadas (hitos, módulos, restricciones, contexto del curso).
|
||||
|
||||
3. **Lee cada archivo de `.claude/`.** Cubre como mínimo `codigo/`, `decisiones/` y `referencias/`, más cualquier archivo o carpeta nuevo encontrado en el paso 1.
|
||||
|
||||
4. **Trata `.claude/decisiones/` como vinculante.** Cualquier decisión nueva o cambiada ahí tiene prioridad y condiciona cómo trabajas de ahora en más.
|
||||
|
||||
5. **Incorpora las referencias.** Si hay referencias nuevas o actualizadas en `.claude/referencias/` (ej. guías de estilo, Clean Code), tenlas presentes al desarrollar o revisar código.
|
||||
|
||||
## Salida esperada
|
||||
|
||||
Entrega un resumen conciso (no repitas los archivos verbatim) que cubra:
|
||||
|
||||
- **Mapa de orquestación al día:** qué hay hoy en `CLAUDE.md` y en cada subcarpeta de `.claude/`.
|
||||
- **Novedades destacables:** decisiones nuevas, pautas de código nuevas, referencias cargadas, o secciones nuevas en `CLAUDE.md` — solo lo que cambia cómo debes trabajar.
|
||||
- **Inconsistencias o contradicciones** entre archivos que convenga que el usuario resuelva.
|
||||
- **Hitos del proyecto** y qué implica para el trabajo inmediato, si está claro en CLAUDE.md.
|
||||
|
||||
Cierra confirmando que el contexto quedó recargado. No edites archivos ni propongas cambios salvo que el usuario lo pida.
|
||||
@@ -0,0 +1,70 @@
|
||||
# CLAUDE.md
|
||||
|
||||
Este archivo proporciona orientación a Claude Code (claude.ai/code) para trabajar con el código de este repositorio.
|
||||
|
||||
## Guías para Claude Code
|
||||
|
||||
Este archivo es el **documento orquestador**: define las etapas e hitos del proyecto y deriva el detalle de trabajo a `.claude/`. Antes de codificar, consultar la carpeta correspondiente.
|
||||
|
||||
**`.claude/codigo/`** — coordinación de los aspectos del código:
|
||||
- [`.claude/codigo/compilacion.md`](.claude/codigo/compilacion.md) — comandos para compilar, ejecutar y empaquetar
|
||||
- [`.claude/codigo/arquitectura.md`](.claude/codigo/arquitectura.md) — flujo de llamadas, patrones de diseño, estado actual del código
|
||||
- [`.claude/codigo/reglas.md`](.claude/codigo/reglas.md) — restricciones obligatorias de codificación y reglas de negocio
|
||||
- [`.claude/codigo/designPatterns.md`](.claude/codigo/designPatterns.md) — patrones de diseño a aplicar; consultar antes de implementar cualquier patrón
|
||||
|
||||
**`.claude/decisiones/`** — decisiones del usuario que el agente **debe respetar** (no renegociar):
|
||||
- [`.claude/decisiones/DECISIONS.md`](.claude/decisiones/DECISIONS.md) — decisiones sobre el proyecto y la organización del contexto (`.claude/`, hitos)
|
||||
- [`.claude/decisiones/codigo.md`](.claude/decisiones/codigo.md) — decisiones sobre el desarrollo de código (mandato de buenas prácticas / Clean Code)
|
||||
- [`.claude/decisiones/commits.md`](.claude/decisiones/commits.md) — decisiones sobre los commits (legibles, sin firma de IA, reflejan las tareas completadas de la etapa)
|
||||
- [`.claude/decisiones/documentacion.md`](.claude/decisiones/documentacion.md) — decisiones sobre la documentación (Markdown por defecto, sin emojis, sin firma de IA, índices)
|
||||
- [`.claude/decisiones/notas.md`](.claude/decisiones/notas.md) — decisiones sobre los comentarios en el código (mínimos, sin emojis, preferir ajustar documentación existente)
|
||||
- [`.claude/decisiones/minutas.md`](.claude/decisiones/minutas.md) — decisiones sobre las minutas (nombre `Minuta_00N_DD-MM-YYYY`, recuadro Fecha/Duración/Etapa, títulos fijos, sin mencionar `.claude`/`CLAUDE.md`/repo ni la IA)
|
||||
- [`.claude/decisiones/sobreCLAUDE.md`](.claude/decisiones/sobreCLAUDE.md) — guia para construir y mantener CLAUDE.md correctamente
|
||||
- [`.claude/decisiones/sobreREADME.md`](.claude/decisiones/sobreREADME.md) — guia para construir y mantener README.md correctamente
|
||||
|
||||
**`.claude/referencias/`** — material de apoyo para guiar al modelo al evaluar prácticas de programación:
|
||||
- [`.claude/referencias/clean_code_RobertCMartin.md`](.claude/referencias/clean_code_RobertCMartin.md) — *Clean Code* (R. C. Martin), referencia máxima de buenas prácticas; aplicarlo al desarrollar código
|
||||
- [`.claude/referencias/ejemplo_commit.md`](.claude/referencias/ejemplo_commit.md) — ejemplo/plantilla de commit del usuario; referencia para redactar los mensajes de commit
|
||||
|
||||
|
||||
---
|
||||
|
||||
# Datos generales del proyecto
|
||||
|
||||
**Nombre:**
|
||||
**Repositorio oficial:**
|
||||
**Institución:**
|
||||
|
||||
## Equipo
|
||||
|
||||
**Integrantes:**
|
||||
- Mateo Saldain
|
||||
|
||||
## Descripción general
|
||||
|
||||
|
||||
## Stack tecnológico
|
||||
|
||||
- **Lenguajes:**
|
||||
- **Base de datos:**
|
||||
- **Build:**
|
||||
- **Testing:**
|
||||
- **Herramientas:**
|
||||
|
||||
|
||||
## Restricciones técnicas obligatorias de programación
|
||||
|
||||
|
||||
## Etapas del proyecto
|
||||
|
||||
|
||||
## Complejidad esperada
|
||||
|
||||
|
||||
## Reglas del proyecto
|
||||
Las reglas aquí marcadas deben tenerse siempre en cuenta a meenos que el usuario lo solicite explicitamente. Estas órdenes complementan la configuración en [settings.json](.claude/settings.json)
|
||||
|
||||
- Nunca ejecutar comandos de Git.
|
||||
- No crear commits, ramas, tags o pull requests.
|
||||
- No ejecutar `git add`, `git commit`, `git push`, `git pull`, `git merge`, `git rebase`, `git reset`, `git checkout` ni `git switch`.
|
||||
- Si una tarea requiere operaciones de Git, solicitar al desarrollador que las ejecute manualmente.
|
||||
@@ -1,2 +1,25 @@
|
||||
# plantillaClaude
|
||||
# Nombre del proyecto
|
||||
|
||||
> Este README.md es de carácter temporal y corresponde a la plantilla base. Se recomienda reemplazarlo lo antes posible para que refleje apropiadamente el proyecto real.
|
||||
|
||||
Plantilla de trabajo para proyectos que usan Claude Code. Reemplazar este encabezado y completar las secciones siguientes una vez inicializado el proyecto.
|
||||
|
||||
## Organización de etapas
|
||||
|
||||
Pendiente de definir. Reflejar aquí las etapas, plazos y planes de acción cargados en `## Etapas del proyecto` de [CLAUDE.md](CLAUDE.md).
|
||||
|
||||
## Requisitos indispensables
|
||||
|
||||
Pendiente de definir.
|
||||
|
||||
## Puesta en marcha con Claude Code
|
||||
|
||||
[CLAUDE.md](CLAUDE.md) trae vacía la sección `# Datos generales del proyecto`. La skill `inicializarProyecto` completa esos datos conversando en lenguaje natural con el usuario y los vuelca en `CLAUDE.md`, sin inventar información ni tocar decisiones, referencias o código.
|
||||
|
||||
Para usarla:
|
||||
|
||||
```
|
||||
/inicializarProyecto
|
||||
```
|
||||
|
||||
Es el primer paso recomendado al empezar a usar esta plantilla, y conviene repetirlo si cambian datos generales del proyecto más adelante. Al terminar, sugiere correr `recontextualizar` para refrescar el contexto de la sesión.
|
||||
|
||||
Reference in New Issue
Block a user