Organizamos de forma breve en el CLAUDE.md del proyecto el comando de ejecución, las reglas de datos, las prohibiciones y la forma de comprobar resultados que antes se repetían en cada solicitud. Distinguimos la función de `/init` para crear un borrador y el propósito de cada ubicación de archivo, y terminamos un archivo de reglas de 35 líneas adaptado al ejemplo del CSV de gastos.
Contenido revisado 2026.09.22Instrucciones para copiar
Ver el índice
Para quién esUsuarios principiantes que modifican varias veces un mismo proyecto con Claude Code y quieren reducir la repetición de las mismas reglas en cada solicitud
Preparación
Tener expenses.csv y summarize.py en la carpeta vibe-expenses
Conocer el comando de ejecución de la herramienta de total mensual y su salida esperada
Entender que CLAUDE.md es contexto del proyecto, no una configuración coercitiva
01Mover al archivo del proyecto solo las reglas que se repiten
En el artículo anterior, cada solicitud a Claude Code incluía directamente el archivo de entrada, el uso de la biblioteca estándar, la prohibición de modificar el CSV original, el comando de ejecución y la salida esperada. Si se sigue trabajando en el mismo proyecto, estas reglas pueden organizarse en CLAUDE.md en lugar de escribirlas de nuevo cada vez. Claude Code lee este archivo al inicio de la sesión y lo usa como contexto del proyecto.
Sin embargo, CLAUDE.md no debe considerarse un mecanismo de control de acceso ni una regla absoluta. Según la documentación oficial, este archivo aporta contexto y resulta más fácil de seguir cuanto más concreto y conciso sea. Por tanto, no hay que suponer que «siempre se cumplirá perfectamente»; los cambios reales deben seguir revisándose.
Regla repetida
Ejemplo que se puede escribir en CLAUDE.md
Motivo
Entrada
expenses.csv / UTF-8 / columnas fijas
Reduce la posibilidad de asumir arbitrariamente otros archivos o columnas
Implementación
Usar solo la biblioteca estándar de Python
Aclara el límite para añadir paquetes
Ejecución
python summarize.py expenses.csv
Fija el comando de verificación
Prohibición
No modificar expenses.csv
Define el criterio de conservación de los datos originales
Criterio de finalización
Dos líneas con los valores mensuales esperados
Proporciona valores que la persona puede comparar después del trabajo
02Distinguir las ubicaciones para reglas compartidas por el equipo, comunes personales y personales del proyecto
La documentación oficial describe ubicaciones con propósitos distintos. `./CLAUDE.md`, en la raíz del proyecto, es adecuado para reglas del proyecto compartidas con el equipo. `~/.claude/CLAUDE.md` contiene notas personales comunes a todos los proyectos, y `./CLAUDE.local.md` sirve para notas personales de un proyecto concreto y puede añadirse a .gitignore.
Instrucción
./CLAUDE.md
~/.claude/CLAUDE.md
./CLAUDE.local.md
En este ejemplo usamos `./CLAUDE.md` porque contiene información propia del proyecto, como el comando de ejecución y las reglas de datos. Es más fácil de mantener si las preferencias personales o las rutas locales no se mezclan en un archivo compartido por el equipo.
03Crear un borrador con /init sin aceptarlo tal cual
Al usar `/init` dentro de una sesión, Claude Code puede analizar la base de código y crear un borrador de CLAUDE.md con comandos de compilación, pruebas y convenciones. La documentación oficial explica que, si ya existe CLAUDE.md, no lo sobrescribe, sino que propone mejoras. Por tanto, conviene entender `/init` no como un comando que decide las reglas automáticamente, sino como un punto de partida para obtener un borrador que una persona revisará.
Instrucción
/init
Cuando se genere el borrador, comprueba si incluye comandos que no encajan con el proyecto real, pruebas inexistentes o instrucciones demasiado generales. Como en este artículo no se ejecutó realmente Claude Code, no inventamos una respuesta de ejemplo atribuyéndole frases concretas generadas por `/init`.
04Organizar en 35 líneas el CLAUDE.md del ejemplo de gastos
El siguiente ejemplo es un CLAUDE.md que reúne solo las reglas necesarias para el proyecto ficticio de esta serie. La documentación oficial recomienda menos de 200 líneas por archivo, y este ejemplo se mantiene en 35 líneas. Separamos objetivo, datos, reglas de Python, comandos de ejecución, resultado esperado y reglas de trabajo para que también resulte claro para una persona.
Instrucción
# Project: vibe-expenses
## Goal
- Read expenses.csv and summarize expense amounts.
- Keep the example small and understandable for beginners.
## Data
- Input file: expenses.csv
- Encoding: UTF-8
- Columns: date, category, amount
- date format: YYYY-MM-DD
- category values stay in English.
- amount is treated as an integer.
## Python rules
- Use only the Python standard library.
- Prefer csv for reading CSV files.
- Do not add third-party packages.
- Keep functions short and names descriptive.
- Do not modify expenses.csv.
## Commands
- Run: python summarize.py expenses.csv
- On Windows, py summarize.py expenses.csv is also acceptable.
## Expected result
- 2026-09 = 26600
- 2026-10 = 9800
## Working rules
- Explain the planned change before editing files.
- Change only files needed for the requested task.
- Do not invent extra input columns or business rules.
- If a requirement is unclear, ask before expanding scope.
- After editing, show what changed and how to verify it.
No incluimos aquí contraseñas, claves de API ni rutas reales de clientes. Un archivo de instrucciones del proyecto sirve para transmitir contexto de trabajo, por lo que es más seguro centrarse en reglas que no causen problemas aunque el archivo se publique o se comparta.
05Priorizar reglas verificables frente a explicaciones largas
Un CLAUDE.md no es mejor por ser más largo. Son más útiles reglas que se puedan contrastar con el resultado real, como «no añadir paquetes externos», «no modificar expenses.csv» o «este es el comando de ejecución», que frases difíciles de evaluar como «escribe buen código». Si fuera necesario, se puede usar la sintaxis `@ruta` para incorporar el contenido de otros archivos, pero este ejemplo pequeño no necesita incluir archivos adicionales.
Escribir solo nombres de archivo y comandos que existan realmente en el proyecto.
No acumular en CLAUDE.md instrucciones para tareas que solo se necesitan una vez.
Escribir las prohibiciones de forma concreta, indicando qué no debe hacerse.
Dejar valores esperados o comandos de comprobación que permitan decidir si el trabajo está terminado.
No incluir secretos personales ni claves de API en el archivo de reglas del proyecto.
Incluso después de añadir reglas, hay que revisar por separado qué archivos modifica realmente Claude Code. CLAUDE.md no sustituye la revisión; reduce el contexto del proyecto que tendría que explicarse repetidamente.
06Volver a leer el archivo de reglas antes del siguiente trabajo
Después de guardar CLAUDE.md, conviene que una persona lo lea una vez antes de pedir la siguiente función. Si han cambiado el código actual o el comando de ejecución pero quedan instrucciones antiguas, el archivo puede aportar contexto incorrecto. En particular, si cambian la salida esperada o los nombres de archivo, también debe actualizarse el archivo de reglas.
Pregunta de revisión
Respuesta que debe tener el ejemplo
Señal de que hay que corregir
¿Es correcto el archivo de entrada?
expenses.csv
Queda otro nombre de archivo
¿Es correcto el comando de ejecución?
python summarize.py expenses.csv
Queda el nombre de un script anterior
¿Es correcta la regla de paquetes?
Usar solo la biblioteca estándar
Exige un paquete externo innecesario
¿Son correctos los valores esperados?
26600 / 9800
Aparecen números distintos a los del ejemplo actual
¿Está claro lo que no debe modificarse?
No modificar expenses.csv
Solo hay expresiones ambiguas
En el siguiente artículo mantendremos estas reglas y, en lugar de implementar de inmediato una nueva función, la diseñaremos primero en modo plan. El objetivo será revisar durante la planificación qué cambios requiere una opción `--by-category` que muestre para 2026-09 food 20500, transport 2900 y supplies 3200.
Qué comprobar por tu cuenta
Redactado con base en la documentación oficial de Claude Code (consultada el 2026-09-22) y en el ejemplo ficticio de esta serie · Claude Code no se ejecutó realmente · Este artículo no contiene código Python que deba ejecutarse
Comprobar que las ubicaciones y usos de `./CLAUDE.md` del proyecto, `~/.claude/CLAUDE.md` personal global y `./CLAUDE.local.md` personal del proyecto coincidan con la documentación oficial
Comparar con la documentación oficial la explicación de que `/init` analiza la base de código para crear un borrador y, si ya existe CLAUDE.md, propone mejoras en lugar de sobrescribirlo
Comprobar que CLAUDE.md se describa como contexto del proyecto y no como una configuración coercitiva
Comprobar que el CLAUDE.md de ejemplo tenga 35 líneas y esté por debajo de la recomendación oficial de menos de 200 líneas por archivo
Comprobar que las reglas de ejemplo incluyan comando de ejecución, reglas de datos, prohibiciones, resultado esperado y flujo de verificación
Comprobar que no se afirme haber creado resultados reales de `/init` ni respuestas reales de Claude Code
Límites de la verificación
En este artículo no se ejecutaron realmente `/init` ni las funciones de archivos de memoria de Claude Code. El ejemplo de CLAUDE.md es un texto editorial basado en los requisitos del proyecto ficticio de esta serie; en un proyecto real, una persona debe revisarlo según la estructura de archivos y los comandos vigentes.
Entendemos el vibe coding no como «decírselo con palabras y dejar que la IA lo haga todo», sino como una forma de trabajo en la que la persona define los requisitos y los criterios de comprobación y después revisa el resultado generado por la IA. Con una herramienta ficticia para sumar un CSV de gastos domésticos, organizamos en una sola nota la entrada, la salida, lo que no debe hacerse y cómo verificar el resultado.
Comprobamos el comando de instalación de Claude Code y las condiciones de cuenta según el sistema operativo, y comenzamos la primera sesión en una carpeta ficticia de práctica. En lugar de generar código de inmediato, hacemos solo tres preguntas para leer la carpeta y el CSV en modo plan y después cerramos la sesión de forma segura.
Practicamos el flujo para crear una primera herramienta pequeña en Python usando el expenses.csv ficticio y la nota de requisitos preparados antes. La solicitud incluye un ejemplo de entrada, la salida esperada y las restricciones, y después ejecutamos el summarize.py terminado en la herramienta Python del chat de GPT, no en Claude Code, para comprobar el resultado.
A partir del ejemplo de añadir la opción `--by-category` a una herramienta ya funcional que suma gastos por mes, aprenderás a revisar primero el plan de cambios en el modo plan de Claude Code. Antes de implementar, fijarás el alcance de la modificación y el formato de salida; después de aprobar el plan, ejecutarás el código final para comprobar tanto los totales mensuales existentes como los totales por categoría.
Aprenderás un flujo mínimo para dejar un punto de referencia con git antes de que Claude Code modifique archivos y, después del trabajo, revisar los cambios reales con `git status` y `git diff`. Puedes pedir a la IA que explique el diff, pero el proceso se basa en que una persona compruebe el diff y los resultados de ejecución antes de hacer staging y commit directamente.
En lugar de limitarte a decirle a la IA que «da error», practicarás un flujo en el que primero reproduces el problema con la misma entrada, acotas la causa a partir del mensaje de excepción real y solicitas solo el cambio mínimo. Usaremos un CSV cuyo amount contiene una coma para reproducir un ValueError en Python y volveremos a ejecutar el código corregido para comprobar el resultado.
Partiendo de que Claude Code puede leer y modificar archivos y ejecutar comandos, este artículo reúne las comprobaciones de seguridad que una persona principiante debe hacer antes, durante y después del trabajo. Conecta en una sola lista las diferencias entre modos de permiso, los cambios que los checkpoints no pueden restaurar, la diferencia de función respecto de git y la regla de no introducir información secreta.