Claude Code CLI: 7 consejos y automatización en la práctica

La terminal muestra la decimoctava ejecución de tests fallida. Si hubiera conocido antes el comando /clear, no habría llegado tan tarde.

Los datos oficiales indican que Claude Code puede resolver de forma autónoma el 80,9 % de los problemas de código en las pruebas SWE-bench. La pregunta es: ¿estás usando realmente sus capacidades centrales? La mayoría arranca Claude Code, ejecuta claude, charla un poco, modifica algo de código y listo. De más de 50 comandos, usan 3 o 5 como mucho, desperdiciando el 90 % del potencial de eficiencia.

Este artículo comparte 7 consejos de CLI y 3 casos de automatización en la práctica, con un enfoque sistemático por escenario: desde comandos básicos y gestión de contexto hasta Hooks y CI/CD. Al terminar, pasarás de «saber usarlo» a «usarlo de verdad con eficiencia».

Capítulo 1: Los tres pilares del CLI — arranque, modos y comandos

Primero afianza lo básico; solo así tendrán sentido las técnicas avanzadas.

1.1 Tres formas de arranque, cada una con su uso

claude              # Inicia la interfaz interactiva en el directorio actual
claude -c           # Continúa la sesión más reciente
claude --print "Revisa la definición de tipos de esta función"  # Consulta única y sale

Muchos solo conocen la primera. La segunda, -c, es especialmente útil: si acabas de cerrar una sesión y recuerdas que quedó algo pendiente, con claude -c retomas el contexto sin volver a explicar el proyecto.

La tercera, --print, la uso para consultas rápidas. Por ejemplo, confirmar si una definición de tipos es correcta: un comando y listo, sin entrar en modo interactivo completo. Ahorra tiempo.

1.2 Tres modos de trabajo, según el escenario

Es un concepto central en la documentación oficial; el artículo en profundidad de Alibaba Cloud también lo cubre:

En modo Default, cada modificación de archivo o comando requiere confirmación manual. Molesto, pero seguro. Ideal cuando estás explorando un proyecto desconocido.

En modo Auto-Accept, las modificaciones de archivos se ejecutan automáticamente; los comandos shell siguen pidiendo confirmación. En tu propio proyecto, con refactorizaciones masivas, Claude puede terminar de una vez y tú revisas al final. La eficiencia se duplica.

El modo Plan lo uso para analizar problemas complejos. Dejas que Claude lea todo el proyecto y genere un plan detallado. Sin modificar nada, solo planificación. Si el plan convence, cambias a Auto-Accept para ejecutar.

1.3 Tres comandos con barra que debes recordar

De más de 50 comandos oficiales, la mayoría usa menos del 10 %. Estos tres son los que más uso:

/init     # Escanea el proyecto y genera CLAUDE.md
/clear    # Vacía el historial de la sesión
/compact  # Comprime el contexto para ahorrar tokens

/init al arrancar por primera vez en un proyecto nuevo. Claude escanea el repositorio y genera un archivo de configuración con estructura, dependencias y convenciones. Las operaciones posteriores lo tendrán en cuenta.

/clear lo trato aparte más adelante: es el mayor impulso de eficiencia que he encontrado.

/compact cuando el contexto acumula demasiado historial. Claude conserva lo esencial y elimina lo redundante, ahorrando tokens. Útil si en la misma sesión hiciste muchas rondas de cambios.

Capítulo 2: El arte de gestionar el contexto — vaciar, comprimir, paralelizar

Esta parte me la inspiró el artículo de Builder.io: dicen que /clear es «el mayor impulso de productividad». Lo probé una semana y confirmé que es cierto.

2.1 El uso correcto de /clear

¿Cuándo vaciar la sesión?

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

Al cambiar de tarea.

Supón que acabas de corregir un bug, veinte intercambios con Claude, y localizaste el problema. De repente te piden atender otro issue urgente. Muchos siguen en la misma sesión y cambian de tema.

Error.

En ese momento conviene /clear y borrar todo el historial. ¿Por qué? Esas conversaciones consumen tokens y no tienen relación con la nueva tarea. El contexto viejo «contamina» a Claude y baja la calidad al entender el problema nuevo.

Mi hábito: al pasar de una tarea a otra, primero /clear, luego un breve contexto del trabajo nuevo. Funciona mucho mejor que seguir en la sesión anterior.

2.2 Cuándo usar /compact

Si en la misma tarea hiciste muchas rondas — una docena de archivos, más de treinta mensajes — el contexto ya es largo.

/compact comprime ese historial: conserva lo clave (archivos tocados, decisiones importantes) y elimina conversación redundante.

¿Cuándo activarlo? Me puse una regla aproximada: más de 30 mensajes, compact una vez. No hace falta ser exacto; cuando «se siente largo», comprime.

2.3 Estrategia de sesiones en paralelo

Este consejo viene del Help Center oficial de Claude: ejecutar 3-5 sesiones a la vez, cada una en un git worktree distinto trabajando partes diferentes del repositorio.

¿Qué es git worktree? En pocas palabras, varios directorios de trabajo del mismo repo, cada uno en una rama distinta.

# Crear worktrees
git worktree add ../feature-A feature-branch-A
git worktree add ../feature-B feature-branch-B

# Arrancar Claude en cada worktree
cd ../feature-A && claude
cd ../feature-B && claude

Así puedes trabajar en dos terminales: una con feature-A y otra con feature-B. Sesiones independientes, contextos separados.

Otro truco de terminal: Ctrl+B envía comandos bash largos al segundo plano. Útil cuando Claude ejecuta algo pesado (npm install, tests que tardan) y no quieres bloquear la interfaz de la sesión.

Capítulo 3: Las tres piezas de automatización — Hooks, Routines y CI/CD

Lo anterior es manual. Aquí entra la automatización: que Claude haga el trabajo repetitivo mientras tú avanzas.

3.1 Hooks: disparadores por tarea

Los Hooks son el núcleo de automatización de Claude Code. Hay tres tipos principales:

El más útil es PostToolUse. Configuras un hook y, cada vez que Claude modifica código, se lanzan los tests.

// Ejemplo en settings.json
{
  "hooks": {
    "PostToolUse": [{
      "command": "npm test",
      "timeout": 60000
    }]
  }
}

Efecto: tras cada uso de Write, se ejecuta npm test. Si fallan, Claude ve la salida y puede corregir.

3.2 Routines: flujos repetitivos

Las Routines encajan con tareas que se repiten.

El ejemplo oficial: cuando Claude detecta una condición (por ejemplo, que exista un archivo), ejecuta una serie de comandos predefinidos.

La configuración es algo compleja; aún no lo uso a gran escala en producción. Pero la dirección merece explorarse: fijar comprobaciones que siempre haces, sin recordárselas a Claude cada vez.

3.3 Integración CI/CD: GitHub Actions en la práctica

El modo headless oficial es claude -p.

En GitHub Actions puede revisar PR, implementar issues o auditar seguridad.

# .github/workflows/claude-review.yml
name: Claude Code Review
on: [pull_request]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Claude Review
        run: claude -p "Review this PR and suggest improvements"
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

El blog oficial de GitLab describe tres flujos:

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

1. Crear MR desde un issue
2. Analizar regresiones de rendimiento
3. Implementar funcionalidad y dejar que CI valide

Sigo investigando, pero el potencial es claro: integrar Claude Code en todo el flujo de desarrollo como parte del pipeline CI/CD.

Capítulo 4: Casos prácticos — de la configuración a la automatización

Tras la teoría, cómo se usa en la práctica.

Caso 1: Un commit con una frase

Es el escenario que más uso.

Flujo tradicional: git add, git status, redactar mensaje, git commit. Varios minutos.

Con Claude Code:

claude
> commit these changes

Una frase. Claude lee los cambios, genera un mensaje adecuado y hace commit. Analiza el diff y captura la intención del cambio.

En mis pruebas, el mensaje suele ser mejor que el mío: lee el diff de verdad, no inventa.

Caso 2: Hook PostToolUse para tests automáticos

La configuración completa del hook:

// .claude/settings.json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write",
        "command": "npm run test:related",
        "timeout": 30000
      }
    ]
  }
}

matcher: "Write" limita el hook a la herramienta Write. npm run test:related es un script propio que solo ejecuta tests relacionados con los archivos tocados — no la suite completa, mucho más rápido.

Efecto: en 30 segundos ves el resultado tras cada cambio. Si falla, Claude recibe la salida y puede corregir.

Caí en una trampa al principio: configuré npm test completo, demasiado lento y con timeouts frecuentes. Al pasar a tests relacionados, se resolvió.

Caso 3: Revisión automática de PR en GitHub Actions

Configuración basada en la documentación oficial:

# .github/workflows/claude-pr-review.yml
name: Claude PR Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  claude-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - name: Checkout PR
        uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.ref }}

      - name: Claude Review
        uses: anthropics/claude-code-action@v1
        with:
          prompt: |
            Review this PR for:
            - Code quality issues
            - Potential bugs
            - Security vulnerabilities
            - Performance concerns
          api_key: ${{ secrets.ANTHROPIC_API_KEY }}

El workflow se dispara al crear o actualizar un PR; Claude revisa y comenta. Cubre calidad, bugs potenciales, seguridad y rendimiento.

Llevo un mes usándolo y detecta más bugs que mi revisión manual — no se salta archivos.

Capítulo 5: Multiplicar la productividad — configuración simple e integración de herramientas

Últimos consejos de artículos de Marmelab y Builder.io sobre cómo fluir mejor en el día a día.

5.1 La filosofía de un CLAUDE.md breve

Muchos escriben CLAUDE.md muy largo: contexto, stack, estilo, prohibiciones… miles de palabras.

Marmelab recomienda lo contrario: mantener CLAUDE.md lo más corto posible.

¿Por qué? Cuanto más largo, más «sobre-cumple» Claude — consulta la config en cada paso y pierde flexibilidad. Además, consume tokens.

Su recomendación: 3-5 convenciones clave, la config como «función de simplificación forzada» del repositorio. Por ejemplo:

# CLAUDE.md
- TypeScript en modo estricto; todas las variables con tipo
- Componentes en src/components/
- Tests junto al archivo fuente
- No usar var; solo const y let

Unas pocas líneas. Suficiente.

5.2 Estrategia de Bash Wrapper

Builder.io insiste: en lugar de documentación larga, scripts bash wrapper.

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

Para que el equipo arranque el proyecto, mejor un script que un README con «npm install, variables de entorno, dev server»:

#!/bin/bash
# dev.sh - Arranque rápido del entorno de desarrollo

npm install
source .env.local
npm run dev

En Claude Code basta con «run dev.sh». Simple, sin pensar.

Lo mismo aplica a Claude: alias o scripts para combinaciones frecuentes, sin teclear cadenas largas cada vez.

5.3 Integración MCP: seguridad y filtrado de salida

Por último, integración con MCP (Model Context Protocol).

Dos ejemplos útiles:

Snyk MCP Server: Claude comprueba vulnerabilidades y dependencias al escribir código. Al añadir dependencias, puede lanzar un escaneo sin que se lo pidas.

rtk: filtra y comprime la salida de comandos. Muchos CLI generan logs enormes (npm install) que consumen tokens. rtk deja solo lo relevante.

Aún no los tengo del todo integrados, pero la dirección es clara: que Claude Code no solo escriba código, sino que se conecte a seguridad y gestión de dependencias.

Resumen

En esencia:

Domina los comandos básicos — tres formas de arranque, tres modos; cambia según el escenario. No te quedes solo con el más simple.

No descuides el contexto — /clear al cambiar de tarea, /compact cuando la conversación se alarga. Esos hábitos ahorran muchos tokens.

La automatización compensa — Hooks, GitHub Actions: tiempo al principio, ahorro multiplicado después.

Configuración concisa — CLAUDE.md corto, procesos complejos en scripts. Más largo no es mejor.

Mis recomendaciones:

1. Hoy: escribe /clear en tu sesión actual y nota la diferencia
2. Esta semana: configura un hook PostToolUse para tests tras cada cambio
3. A largo plazo: integra Claude Code en tu CI/CD como herramienta estándar del equipo

Para profundizar en la configuración de Claude Code, mira el primer artículo de la serie «¡Deja de dejar que Claude escriba código a lo loco! Un archivo de configuración para subir la precisión de la IA un 10 %» (cómo redactar CLAUDE.md). Para Subagents, el segundo: «¿Respuestas demasiado largas? Construye tu equipo de IA con Subagents». Este es el séptimo de la serie, centrado en consejos de CLI.

Aprendí estos trucos a base de tropiezos. Espero que evites algunos y subas la eficiencia antes.