Mapa de comandos de la primera semana con Claude Code: 12 comandos en orden

Por qué merece su propio artefacto

Este artículo construye un mapa de comandos de primera semana para principiantes que instalaron Claude Code y necesitan una primera semana ordenada. El fallo común es simple: los usuarios nuevos saltan del install a pedidos enormes y no saben qué comando prueba el avance. Un workflow con Claude Code no termina con una respuesta segura. Debe dejar un artefacto que otra persona pueda revisar. En este caso el artefacto es un mapa por día que va de leer el repo a verificar un cambio pequeño.

Trata el artefacto como contrato entre prompt, línea de comandos y página pública. Debe mostrar qué leyó Claude Code, qué cambió, qué comando probó el resultado y qué ruta de ingresos verá después el lector. Por eso conecta con harness engineering, getting started y permissions.

El loop operativo

Ejecuta el loop en cinco pasadas: definir la acción, elegir la prueba, dejar que Claude Code haga el trabajo mínimo útil, verificar la salida y registrar la siguiente acción de ingresos. Aquí la prueba útil no es solo que el código corra. Mira builds exitosos, diffs pequeños, menos sorpresas de aprobación y más inicios de PDF. Con esos campos visibles puedes mejorar sin adivinar.

1. El día uno es solo lectura: archivos, comandos y carpetas riesgosas antes de pedir un patch.

2. El día tres permite una edición reversible, pero la prueba se elige antes de editar.

3. El día cinco escribe un handoff para que la siguiente sesión empiece desde evidencia.

Starter para copiar

$checks = @(
  "git status --short",
  "rg --files | Select-Object -First 40",
  "npm.cmd run build"
)

foreach ($cmd in $checks) {
  Write-Host "NEXT:" $cmd
}

Tres ejemplos reales

Ejemplo 1. El día uno es solo lectura: archivos, comandos y carpetas riesgosas antes de pedir un patch.

Ejemplo 2. El día tres permite una edición reversible, pero la prueba se elige antes de editar.

Ejemplo 3. El día cinco escribe un handoff para que la siguiente sesión empiece desde evidencia.

Checklist de auto-revisión

Antes de convertir este workflow en hábito, revisa el artículo como si fuera una nota de release. El primer control es el alcance: el lector debe saber cuándo usar un mapa de comandos de primera semana y cuándo basta un checklist más pequeño. El segundo control es la prueba: cada recomendación debe apuntar a un comando, una URL, un diff o una métrica. El tercer control es el routing: el PDF gratuito, la guía de Gumroad y la consultoría no deben competir, sino responder a distintos niveles de urgencia.

Añade una regla pequeña de ownership. Una persona es dueña del artefacto, otra de la verificación y otra del siguiente experimento de CTA. En un flujo individual pueden ser la misma persona, pero los roles deben quedar escritos. Eso evita que Claude Code mezcle publicación, medición y venta en una sola tarea borrosa. También permite que la siguiente ejecución continúe desde un punto concreto.

La pregunta práctica es: ¿qué haría este artículo más fácil de verificar mañana por la mañana? Si la respuesta es una captura, guárdala. Si es un prompt más fuerte, súbelo al prompt pack. Si es un límite más claro, añádelo a las notas de setup. un mapa por día que va de leer el repo a verificar un cambio pequeño solo sirve cuando sobrevive a la siguiente sesión.

Fallos comunes

El primer fallo es tratar las páginas vistas como único score. El segundo es aprobar cambios sin comando de prueba. El tercero es enviar a todos los lectores al mismo producto pagado aunque un PDF gratuito o una consulta encaje mejor. Escribe la regla de routing antes de tocar el CTA.

Ruta de ingresos

Rutea por cuello de botella. Si falta fluidez de comandos, manda al PDF gratuito o al cheatsheet gratuito en Gumroad. Si repiten el mismo trabajo cada semana, usa 50 Prompt Templates o Setup Guide. Si el problema es rollout, riesgo o diseño de ingresos, usa consultoría. En este artículo, el free cheatsheet ayuda a recordar comandos, y Setup Guide sirve cuando el mapa necesita reglas de equipo.

Métricas de verificación

Después de publicar, no basta HTTP 200. Confirma h1, canonical, hero image, inicio del cuerpo, enlaces CTA, mobile layout e idioma. Luego mira builds exitosos, diffs pequeños, menos sorpresas de aprobación y más inicios de PDF. Si la métrica no se mueve, revisa el CTA cerca del primer ejemplo concreto antes de reescribir todo.