Cómo gastar menos y trabajar mejor con Claude Code

Hola, bienvenido. En la lección anterior llevamos Claude a GitHub para que revise cada pull request, y con esta lección empezamos el cierre del curso. Es una lección de repaso con una pieza nueva: vamos a revisar las reglas de oro que te ahorran uso y correcciones, ver dónde mirar cuando el uso sube más de la cuenta con /usage y la línea de caché, repasar la configuración con /doctor y /skill-doctor. Después dejaremos escrita la checklist antes de cada commit y montaremos una statusline que te enseñe el modelo, el contexto y tus límites sin abrir ningún comando.

¿Por qué una lección de repaso? Porque a lo largo del curso cada una de estas ideas ha salido en su lección, junto a la herramienta que la explicaba, y en el día a día lo que necesitas es tenerlas juntas. Así que no vamos a volver a explicarlas: cada regla y cada comando llevan el enlace a la lección donde lo vimos con calma, y aquí nos quedamos con el criterio y con lo que ha cambiado desde entonces.

Para seguir la lección necesitas claude-tasks con el último commit, una sesión de Claude Code abierta en la raíz del proyecto y jq, que ya usan nuestros hooks. La statusline vive en tu carpeta personal, fuera del proyecto, así que no vamos a cambiar ningún archivo de claude-tasks.

Estas son las 7 reglas de la versión anterior del curso, puestas al día con lo que hemos visto:

1. Un CLAUDE.md corto. Por debajo de 200 líneas y solo con lo que Claude haría mal sin él, como vimos en la lección Cómo escribir un buen CLAUDE.md para un proyecto Laravel. Lo que es de una carpeta va a una rule y lo que es un procedimiento, a una skill, porque solo entran en el contexto cuando hacen falta.
2. Lo que Claude no debe leer se bloquea con deny. respectGitignore solo decide qué te ofrece el selector de archivos con @, y no impide que Claude lea nada, como vimos en la lección Configurar Claude Code en un proyecto con .claude y settings.json.
3. El modelo según el riesgo. Hoy la sesión arranca con Opus 5.5, y la guía de costes de la documentación recuerda que Sonnet resuelve bien la mayoría de las tareas de programación y cuesta menos. Elige al principio de la sesión, porque cambiar a mitad rompe la caché. Lo vimos en la lección Qué modelo usar en Claude Code: Sonnet, Opus, Haiku o Fable.
4. El effort, antes que el modelo. Opus 5.5 arranca en medium y el resto de modelos en high. La documentación reserva low para tareas cortas y acotadas en las que importa la velocidad, y avisa de que max tiende a pensar de más.
5. /clear entre tareas y /compact en los cortes naturales. /clear no cuesta nada, y /compact lee la conversación que resume, así que en un contexto grande es una petición grande. Lo vimos en la lección Ventana de contexto y compactación en Claude Code.
6. Plan mode cuando el diff no cabe en una frase. Plan mode añade trabajo, y si puedes describir el cambio en una frase, te lo puedes saltar, como vimos en la lección Plan mode en Claude Code: revisar antes de ejecutar.
7. Una sesión nueva cuando corriges lo mismo más de 2 veces. El contexto está lleno de intentos fallidos, y un prompt mejor en una sesión limpia suele llegar antes.

Fíjate en que ninguna regla va de escribir menos. La mayoría van de lo mismo: que en cada petición viaje solo lo que Claude necesita, porque cada turno reenvía el contexto entero, y lo que sobra lo pagas en uso y en calidad.