Cómo instalar Claude Code y sacarle partido la primera semana

Claude Code es un agente que trabaja desde la terminal sobre los archivos de tu proyecto: lee lo que necesita, propone cambios, ejecuta comandos y lanza los tests. La instalación son dos minutos. Lo que decide si a la semana sigues usándolo es otra cosa: el orden en que aprendes a darle contexto, a acotarle el permiso y a dejarle las instrucciones por escrito.

Esta guía va de eso. Primero los comandos exactos, luego el orden.

Qué necesitas antes de empezar

• Una terminal abierta. Terminal o iTerm en macOS, cualquiera en Linux, PowerShell o CMD en Windows.
• Un proyecto con el que trabajar. Vale cualquier carpeta con archivos; si además es un repositorio de Git, aprovecharás la mitad de lo bueno desde el primer día.
• Una cuenta con acceso. Una suscripción de Claude (Pro, Max, Team o Enterprise) o una cuenta de la consola de desarrollador con crédito. Sin una de las dos, la instalación se completa pero no podrás iniciar sesión.

Instalar en macOS, Linux o Windows

El instalador nativo es el camino recomendado y el único que se actualiza solo en segundo plano. Elige la línea de tu sistema:

macOS, Linux o WSL:

curl -fsSL https://claude.ai/install.sh | bash

Windows, en PowerShell:

irm https://claude.ai/install.ps1 | iex

Windows, en CMD:

curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

Si al pegar la línea de CMD te contesta que && no es un separador válido, estás en PowerShell y no en CMD. Si al pegar la de PowerShell te dice que irm no se reconoce, es al contrario. El indicador lo delata: PowerShell muestra PS C:\ y CMD solo C:\.

Si prefieres un gestor de paquetes, también están disponibles:

Homebrew ofrece dos cascos: claude-code sigue el canal estable, que va aproximadamente una semana por detrás y se salta las versiones con regresiones graves, y claude-code@latest recibe cada versión en cuanto sale. Si te molesta que una herramienta cambie de comportamiento a media tarde, el estable es tu canal. En Debian, Fedora, RHEL y Alpine hay además paquetes para apt, dnf y apk.

Para comprobar que ha entrado:

claude --version

Debe imprimir un número de versión seguido de (Claude Code).

Iniciar sesión: qué plan hace falta

Arranca una sesión y te pedirá autenticarte en el navegador:

claude

Sirven las cuentas de suscripción (Pro, Max, Team, Enterprise), las de la consola de desarrollador con crédito prepagado y el acceso a través de proveedores de nube corporativos. Para cambiar de cuenta más adelante, /login dentro de la sesión.

Sobre el dinero, con precios de agosto de 2026 consultados en la página oficial: Pro está en unos 17 $ al mes con pago anual y 20 $ con pago mensual; Max arranca en 100 $ con dos escalones de uso; los planes de equipo rondan los 20-25 $ por puesto. La regla práctica es sencilla: si vas a usarlo todos los días, la suscripción sale mejor que el crédito de API; si es para probar un par de tardes, el crédito te deja pagar solo lo que gastes.

La primera sesión, paso a paso

Colócate en la carpeta del proyecto y arranca:

cd /ruta/a/tu/proyecto
claude

La tentación es pedirle inmediatamente que implemente algo. Es el error clásico. Las tres primeras peticiones deberían ser de lectura, porque son las que te enseñan a ti si te está entendiendo:

1. ¿qué hace este proyecto?
2. ¿dónde está el punto de entrada y cómo se arranca en local?
3. explícame la estructura de carpetas

Si las respuestas son correctas, ya sabes que está leyendo el proyecto de verdad. Si son vagas, tienes un problema de contexto que ninguna instrucción posterior va a arreglar, y la solución está dos apartados más abajo.

El primer cambio que le pidas conviene que sea pequeño y verificable: renombrar una función, añadir una validación, escribir el test que falta. No «refactoriza el módulo de autenticación». Lo que buscas en ese primer cambio no es ahorrar tiempo, es ver cómo te presenta el diff y decidir cuánto vas a confiar.

Los comandos que se usan de verdad

Hay decenas. Estos son los que aparecen a diario:

De estos, el que más tiempo ahorra es /clear, y casi nadie lo usa al principio. Una conversación que arrastra dos horas de contexto irrelevante responde peor y cuesta más que una recién abierta. Cuando cambies de tarea, vacía.

El segundo es -p. Convierte la herramienta en algo que puedes meter dentro de un script o de un hook de Git: revisar el mensaje de un commit, resumir un diff, comprobar si un cambio toca ficheros sensibles.

CLAUDE.md: el archivo que lo cambia todo

Un archivo CLAUDE.md en la raíz del proyecto se lee al empezar cada sesión. Es donde escribes lo que un compañero nuevo necesitaría saber y no puede deducir del código:

• Cómo se arranca, cómo se pasan los tests y con qué comando exacto.
• Las convenciones que no son evidentes: dónde va la lógica de negocio, qué no se toca, cómo se nombran las cosas.
• Las trampas conocidas. Este es el apartado más valioso y el que nadie escribe: «la caché de este proyecto corrompe los objetos serializados, guarda solo escalares», «no lances el indexador sobre vendor/».

Cada trampa que documentas es un error que no vuelve a repetirse. Empieza con diez líneas y añade una cada vez que tengas que corregir lo mismo por segunda vez; un archivo de doscientas líneas escrito de golpe se queda desfasado en dos semanas y nadie lo mira.

Permisos: hasta dónde le dejas llegar

La pregunta no es si confías en la herramienta, sino qué pasa si se equivoca en esta carpeta concreta. Con Shift+Tab cambias el modo de permisos de la sesión en cualquier momento, y esa es la tecla que conviene aprender el primer día:

• Manual: pide confirmación para cada edición y cada comando. Es lo que quieres en un repositorio con cambios sin confirmar, en producción o el día que lo instalas.
• Automático: el modo de arranque en las suscripciones Pro, Max y Team para sesiones interactivas de terminal. Un clasificador revisa las acciones y la mayoría se ejecutan sin preguntarte. Va bien en una rama de trabajo con todo confirmado, donde git diff y git checkout . son tu red.
• Planificación: lee y propone un plan sin tocar nada. Es el modo correcto para tareas grandes: primero acuerdas el plan, luego ejecutas.

La regla que evita todos los disgustos no es un ajuste, es una costumbre: trabaja siempre en una rama, con el árbol limpio antes de empezar. Deshacer un cambio que no te gusta pasa a costar un comando.

Un plan para la primera semana

1. Día 1. Instalar, tres preguntas de lectura, un cambio pequeño en una rama.
2. Día 2. Escribir un CLAUDE.md de diez líneas: arranque, tests, dos convenciones.
3. Día 3. Git conversacional: pedirle el resumen de tus cambios, que redacte un mensaje de commit, que te explique un diff que no entiendes.
4. Día 4. Una tarea repetitiva completa de las que te tocan cada semana, con el método de automatizar tareas con IA.
5. Día 5. Convertir esa tarea en un skill, para no volver a explicarla nunca: cómo crear un skill.

Si llegas al día 5 tienes ya el bucle completo: contexto en el proyecto, procedimiento guardado y una tarea menos en tu semana. A partir de ahí, lo demás —plugins y conexiones MCP— es acumular, no aprender.

Errores de principiante que cuestan una tarde

1. Pedir tareas enormes el primer día. «Migra esto a la nueva API» sin plan previo acaba en un diff de mil líneas que no puedes revisar y no te atreves a aceptar. Usa el modo de planificación.
2. No leer los diffs. Aprobar sin mirar funciona nueve veces y la décima te mete un cambio silencioso en un fichero de configuración. Si no vas a revisar, no aumentes los permisos.
3. Trabajar con el árbol sucio. Mezclar tus cambios a medias con los del agente convierte cualquier vuelta atrás en arqueología.
4. Arrastrar una conversación eterna. Sin /clear, el contexto se llena de ruido y la calidad de las respuestas baja sin que sepas por qué.
5. Repetir las mismas instrucciones cada día. Si has explicado tres veces la misma convención, no es un problema del modelo: es una línea que falta en CLAUDE.md o un skill que no has escrito.