Claude Code in Action — Resumen de estudio

Paths: Developer · FDE · 10 lecciones, 9 videos

Sesiones largas y sin supervisión en las que se pueda confiar: dirigir el trabajo → configurar a Claude → automatizar lo repetitivo → verificar y compartir.

1. Dirigir sesiones largas

Dos hábitos: definir el alcance antes de empezar y dirigir mientras corre.

• Plan mode primero: léelo de verdad, no lo hojees. Iterar sobre un plan es mucho más barato que limpiar después.
• /compact <instrucciones>: lo que escribes después del comando define qué conserva el resumen (p. ej. /compact Focus on the --version flag implementation). Sin instrucciones, se puede perder algo importante.
• Rewind: doble Esc con el prompt vacío. Cada prompt es un checkpoint. Opciones:
  • Restaurar código y conversación, solo la conversación o solo el código.
  • Summarize from here: resume lo posterior (útil tras una conversación lateral).
  • Summarize up to here: resume lo anterior (útil tras un setup largo).
• Más autonomía:
  • /goal <condición>: Claude sigue trabajando entre turnos hasta que un evaluador rápido confirma la condición (/goal clear la cancela). ⚠️ El evaluador solo lee la transcripción, así que la condición debe poder comprobarse con lo que Claude imprime (p. ej. la salida de los tests).
  • Loop: repite un prompt a intervalos (fijos o autoregulados) para vigilar algo externo (CI, deploy). Se detiene con Esc.
• Worktrees para trabajo en paralelo: cada sesión tiene su propio árbol de archivos y no se pisan. Un worktree limpio se borra solo al salir. .worktreeinclude lista archivos git-ignorados (como .env) que se copian a cada worktree.

2. Un CLAUDE.md que se respete

• CLAUDE.md es guía, no configuración forzada. Cada línea compite por la atención, así que mientras más corto, más se sigue.
• Las reglas duras van en hooks (p. ej. "nunca push a main" → PreToolUse).
• 4 ubicaciones que se cargan juntas (se suman):
  • Managed policy (de la organización; no se puede excluir).
  • User (tus preferencias en todos los proyectos).
  • Project (del equipo, en el repo).
  • Local (ignorado por git; solo tuyo en ese repo).
• Imports @.claude/conventions/x.md: organizan, pero no reducen contexto (se expanden al inicio).
• Redacción:
  • Específica y verificable ("rutas nuevas en src/api/handlers, una por archivo", no "sigue buenas prácticas").
  • Nombra el reemplazo ("usa named exports, no default exports").
  • El énfasis es un presupuesto ("IMPORTANT" o "YOU MUST" solo para 2–3 reglas).
• Trátalo como código de producción: cada error de Claude es un bug report contra el archivo ("añádelo al CLAUDE.md"). Si no puedes justificar una línea, bórrala.

3. Skills de verificación (el primero que conviene construir)

• Se dispara solo cuando el cambio coincide con su descripción: corre los tests → lee el diff → comprueba que ningún test se haya debilitado → reporta pass/fail con evidencia.
• "Terminado" no es "el diff se ve bien": es pasar los gates y observar los resultados.
• Carpeta del Skill: SKILL.md corto + reference.md (se lee solo si hace falta) + scripts (se ejecutan sin cargarse en contexto, p. ej. check.sh).
• Dónde va cada regla:
  • Convenciones permanentes → CLAUDE.md.
  • Procedimientos y referencia de una tarea → Skill.
  • Lo que no se puede saltar → hook.
• Si escribiste dos veces la misma instrucción de varios pasos, ahí hay un Skill. Versiónalo en .claude/skills para todo el equipo.

4. Permission modes (6)

• Shift+Tab alterna manual → accept edits → plan → auto. La barra de estado muestra el modo actual.
• El clasificador de auto vigila la intención, no la corrección:
  • Bloquea: deploys y migraciones a producción, force push, curl | sh, enviar datos sensibles fuera, destruir archivos.
  • Deja pasar: edits locales, instalar desde el lockfile, lecturas, push a tu propia rama.
  • El código roto pasa ("roto no es peligroso") → combina auto con un Stop hook que corra los tests.

5. Hooks a fondo

• Son código determinista que garantiza el comportamiento. Hay ~30 eventos; los clave:
  • PreToolUse: el mecanismo de enforcement.
  • PostToolUse: formatear o hacer lint.
  • Stop / SubagentStop: puede negarse a terminar el turno.
  • PreCompact / PostCompact.
  • InstructionsLoaded: auditar qué CLAUDE.md o reglas entraron al contexto.
  • SessionStart: con matcher startup, o compact para reinyectar contexto tras compactar (no uses PostCompact para eso).
• PreToolUse con JSON (exit 0): hookSpecificOutput.permissionDecision = allow | deny | ask (defer solo en ejecuciones -p). Lleva permissionDecisionReason y updatedInput para reescribir la llamada (p. ej. redactar un secreto sk_live_ y dejar que el comando corra). ⚠️ updatedInput reemplaza el input completo: repite los campos que no cambias.
• Exit codes:
  • 0: éxito. El texto plano se añade al contexto solo en SessionStart, UserPromptSubmit y UserPromptExpansion.
  • 2: bloquea, y stderr vuelve a Claude.
  • Cualquier otro (incluido 1): no bloquea.
  • Matices: exit 2 puede bloquear Stop ("no has terminado"). En PostToolUse ya es tarde para bloquear, aunque sí devuelve texto. Notification y SessionStart ignoran el bloqueo.

6. Routines y headless

Un espectro: routines (no construyes nada) → headless -p → --bare → Agent SDK.

• Routine: prompt + repo + connectors + trigger, sobre la infraestructura de Anthropic.
  • Triggers: cron, HTTP POST a su endpoint o evento de GitHub.
  • Se crea en claude.ai/code/routines o con /schedule daily dependency audit at 9am.
  • ⚠️ Es un research preview, la frecuencia máxima es cada hora y cada ejecución parte de un clon limpio de la rama default y solo puede hacer push a ramas claude/.
• Headless (claude -p): sin interfaz, se encadena con pipes.
  • Omite el auto-descubrimiento de hooks, Skills, plugins, MCP y CLAUDE.md (arranca más rápido).
  • --output-format json --json-schema '{...}' → el resultado queda en structured_output (jq '.structured_output.functions').
  • --resume <session_id> para flujos de varios pasos.
• --bare: modo determinista para CI.
• Agent SDK (TypeScript/Python): función query con allowedTools, system prompt y permission mode. Es el mismo motor dentro de tu producto.
• Empieza con routines y baja en el espectro solo si lo necesitas.

7. GitHub Actions y Code Review

• Code Review (gestionado):
  • Un admin lo activa en los admin settings de Claude Code, se instala la Claude GitHub app y se eligen los repos.
  • Cuándo corre: al abrir el PR, en cada push o al comentar @claude review.
  • Varios agentes analizan el diff contra todo el codebase y publican comentarios inline con severidad, deduplicados y ordenados, más una tabla resumen.
  • Nunca aprueba ni bloquea y no hay autofix gestionado: los fixes se aplican en local con /code-review --fix.
  • Research preview, solo planes Team y Enterprise.
• GitHub Action (anthropics/claude-code-action@v1): para lo que va más allá de revisar (implementar desde un comentario, reportes programados).
  • Setup con /install-github-app (requiere ser admin del repo).
  • Inputs: anthropic_api_key, github_token, trigger_phrase (@claude), use_bedrock/use_vertex, prompt, claude_args.
  • En claude_args: --max-turns 5, permission mode sin preguntas, tools mínimas (solo lectura para reportes).
  • Workflows típicos: uno para @claude en comentarios y otro con cron (+ workflow_dispatch).
• Regla: reviews → servicio gestionado; hacer cosas en CI → la Action.

8. Verificar ejecuciones sin supervisión

• Verifica en proporción a lo que no viste. En trabajo desatendido, usa auto (no bypass); el clasificador sigue sin juzgar la corrección.
• Empieza por el diff, no por el resumen: /code-review + git diff. Revisa los archivos del plan y busca los que quedaron fuera.
• Tests como gate: Stop hook que corre los tests y rechaza terminar si fallan (exit 2 → Claude lo arregla solo) + PostToolUse con lint y type check.
• Headless: verifica por el JSON del resultado y el exit code.
• Una segunda opinión en frío: una sesión o subagent nuevo, sin memoria de cómo se construyó.

9. Plugins

• Una unidad instalable: Skills, subagents, hooks, MCP, LSP, monitores, temas y una parte de settings.json.
• Instalar: /plugin install org@plugin → /reload-plugins. Marketplace del equipo: /plugin marketplace add your-org/claude-plugins (pestaña Discover).
• ⚠️ Lee antes de instalar: un plugin corre código con tus privilegios, y sus hooks se disparan en cada llamada que coincide (un Stop hook podría llamar a un endpoint externo). Claude Code muestra el contenido y el costo de contexto estimado. "Revisado" no significa "de confianza".
• Sus componentes corren junto a los tuyos:
  • Los hooks se suman.
  • Skills, agentes y comandos llevan el namespace del plugin.
  • Su settings.json solo admite las claves agent y subagent status line. agent promueve un subagent del plugin al hilo principal (cambia el comportamiento por defecto).
• Empaquetar: la misma forma que .claude (una carpeta por Skill, agents/*.md, hooks/hooks.json, .mcp.json) + un manifiesto opcional .claude-plugin/plugin.json (name es el único campo obligatorio y da el namespace; versiónalo).

Quiz (tus respuestas, 87%)

1. Sabes describir "terminado" mejor que los pasos → /goal con una condición verificable (la fallaste).
2. "Nunca push a main" → hook PreToolUse.
3. Un procedimiento repetido con referencia y un script → Skill con SKILL.md corto + reference.md + scripts.
4. Auto mode + autenticación rota → el clasificador lo deja pasar; añade un Stop hook con tests.
5. Auditoría diaria a las 9am sin máquina propia → routine con cron.
6. Revisar todos los PRs sin hosting → Code Review gestionado.
7. Un job de CI dice "éxito" → empieza por el diff y confirma que los tests de verdad pasaron.
8. Plugin de la comunidad → inspecciona sus hooks, agentes y MCP antes de activarlo.