Plan Mode en Claude Code: guía paso a paso y 4 fases en 2026

Encontrarás instrucciones adicionales en la documentación de Ailoot.

¿Qué es Plan Mode en Claude Code y qué permite hacer?#

En modo normal, Claude Code escribe código de inmediato y, si no estás pendiente, puedes obtener de la nada un diff que abarque muchos archivos. Plan Mode invierte el orden: primero la investigación y la planificación, después la aprobación y, por último, los cambios.

Anthropic describe Plan Mode así en su documentación oficial:

Parece sencillo, pero esconde el cambio principal. Plan Mode cambia el ritmo del trabajo: primero ponerse de acuerdo y después actuar. Es un cambio de modo, no un retoque cosmético. El problema para quienes programan por intuición es que los agentes de IA tienden a precipitarse. Si pides «Añade autenticación con Google» en modo normal, Claude escribirá el código en un minuto, pero la mitad de los archivos serán los equivocados. En Plan Mode, la misma petición se convierte en un plan de texto que puedes leer en dos minutos y corregir antes de tocar ningún código.

Esta es una trampa de la que nadie habla en las guías internacionales. Plan Mode por sí solo es una herramienta débil: el plan solo existe en la conversación actual. Cierra la ventana y el plan se pierde. No puedes delegarlo a otro agente. No hay versiones ni historial. Si la tarea es grande (refactorizar un módulo de 30 archivos, migrar a una nueva base de datos), el plan alcanzará enseguida el límite de la ventana de contexto y empezará a degradarse.

Por eso Plan Mode funciona bien junto con una carpeta plans/ en el repositorio. El plan se guarda como plans/2026-05-21-google-oauth.md, se divide en fases con casillas y cualquier agente siguiente puede retomarlo. Así funciona la ingeniería de contexto: gestionar el contexto antes del prompt, no durante la conversación.

¿Cómo se activa Plan Mode en Claude Code?#

La forma más rápida durante una sesión es con el teclado:

Shift+Tab           # cycles through modes: default → acceptEdits → plan

Después de pulsarlo dos veces, aparecerá el indicador ⏸ plan mode on en la parte inferior del terminal. Una tercera pulsación devuelve al modo normal. Es el método más práctico: puedes activarlo sobre la marcha cuando veas que la tarea crece.

El segundo método es añadir un prefijo antes de un único prompt:

/plan write a plan to migrate the database from MySQL to Postgres

Esta opción es útil si estás en modo de aceptación automática y no quieres cambiarlo para toda la sesión. Una petición en Plan Mode y luego el trabajo continúa como antes.

El tercer método se usa al iniciar la sesión:

claude --permission-mode plan

Úsalo cuando sepas de antemano que una tarea requiere planificación. Por ejemplo, antes de una refactorización importante o una migración.

El cuarto método consiste en establecer el valor predeterminado en .claude/settings.json del proyecto:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

¿Cuándo resulta útil? Cuando un equipo trabaja en un sistema complejo en el que cualquier cambio podría afectar a módulos cercanos. En ese caso, Plan Mode como modo predeterminado protege a todos de cambios accidentales.

Un quinto truco que suele pasar desapercibido: Ctrl+G abre el plan en un editor de texto. Úsalo cuando el plan esté casi bien, pero necesites reformular 2-3 puntos o añadir una restricción. Edítalo manualmente, guárdalo y Claude continuará con tu versión.

¿Cuáles son las 4 fases canónicas de Anthropic en Plan Mode: Explore, Plan, Implement y Commit?#

Muchas guías describen 3 fases (Explore-Plan-Execute) o solo 2 (Plan-Implement). Son simplificaciones. En su guía oficial de buenas prácticas, Anthropic describe exactamente 4 fases. La diferencia importa: al separar Commit como fase, registras el resultado en vez de dejarlo en «He hecho algunos ajustes más aquí, ya haré el commit después», la causa más común de pérdida de trabajo.

Cuanto más preciso sea el plan, menos iteraciones requerirá la implementación. Si dedicas 10 minutos al plan, la implementación llevará un solo prompt. Si lo esbozas en un minuto, la implementación te llevará una hora de correcciones.

Así son las 4 fases al añadir Google OAuth (un ejemplo de Anthropic Docs):

Los prompts también son distintos en cada fase. En Explore: «lee /src/auth y averigua cómo gestionamos las sesiones y el inicio de sesión». En Plan: «Quiero añadir Google OAuth. ¿Qué archivos hay que cambiar? Crea un plan». En Implement: «implementa el flujo OAuth del plan, escribe pruebas, ejecuta la suite y corrige los fallos». En Commit: «crea un commit con un mensaje descriptivo y abre una PR».

Un matiz importante: Plan Mode no impide que Claude ejecute comandos con fines de investigación. Read, LS, Glob, Grep, web fetch y los comandos de shell para explorar están permitidos. Solo están prohibidos Edit, Write y cualquier operación del sistema de archivos que lo modifique. Esto significa que Claude puede leer la estructura del proyecto, ejecutar git log y revisar las pruebas, pero no podrá cambiar nada por accidente.

¿Cómo lees el plan de Claude y decides si lo apruebas?#

Cuando Claude termina de crear un plan, muestra opciones para decidir qué hacer a continuación:

• Aprobar y empezar en modo automático
• Aprobar y aceptar las ediciones
• Aprobar y revisar cada edición manualmente
• Seguir planificando y enviar comentarios
• Refinar con Ultraplan (revisión en el navegador)

Saber si debes aprobar un plan es la habilidad clave en Plan Mode. Es fácil pulsar «Aprobar» automáticamente y luego tener que revertir commits. La IA aduladora quiere dar una respuesta rápida y tú quieres llegar antes al código. Los dos os equivocáis.

Un buen plan cumple 7 criterios:

1. Nombres de archivos concretos. No «Actualizaré la autenticación», sino «Cambiaré src/auth/login.ts:42-58, crearé src/auth/oauth-callback.ts y actualizaré src/auth/session.ts:103».
2. La secuencia está especificada. El plan se divide en fases o pasos, en lugar de «Haré todo esto por ahí».
3. Se nombran las dependencias externas. Si la tarea requiere una biblioteca nueva, se indica. Si hacen falta variables de entorno, también.
4. Se enumeran los riesgos. Un buen plan dice: «La migración podría romper las sesiones existentes; hay que comprobar X». Uno malo no menciona los efectos secundarios.
5. Hay criterios de éxito. «Las pruebas de test/auth pasan, el linter no detecta problemas y el servidor de desarrollo se inicia sin errores».
6. No hay suposiciones sacadas de la nada. Si Claude dice «Usaré la biblioteca Z», comprueba si siquiera la has instalado en el proyecto. Si la IA se la ha inventado, verás que no aparece en package.json.
7. El plan cabe en la pantalla. Si el plan de una función sencilla ocupa 200 líneas, probablemente la tarea sea demasiado grande para un solo plan. Divídela.

Si un plan no supera la revisión, tienes tres opciones:

• Seguir planificando y enviar comentarios: haz un comentario concreto sobre lo que no te gusta y Claude reescribirá el plan.
• Ctrl+G: abre el plan en un editor, modifícalo manualmente y guárdalo. Claude continuará con tu versión.
• Refinar con Ultraplan: el plan pasa al modo de navegador de Claude Code en la web, donde revisas las secciones y comentas; luego lo ejecutas localmente o en la nube.

Si algo sale mal a mitad de la implementación, no lo fuerces. Vuelve a Plan Mode y reescribe el plan. Es 10 veces más barato que revertir 40 commits más tarde.

Plan Mode + una carpeta plans/: una combinación para contextos largos#

Plan Mode es un modo de Claude Code. La carpeta plans/ es una metodología construida sobre él. Si usas Plan Mode sin una carpeta, alcanzarás el límite después de una hora de trabajo.

La lógica es esta. La ventana de contexto de Claude es la memoria de la sesión. En Opus 4.7 caben 1 millón de tokens, pero esa cifra corresponde a toda la conversación. Si planificas una tarea compleja en una conversación, luego pides que la implemente, después hablas de un error y luego de otra cosa, la ventana se «infla». Claude empieza a olvidar decisiones anteriores, confunde contextos y vuelve a hacer preguntas.

La solución es la regla de oro: una tarea, una conversación.

Así se hace:

1. Conversación 1: preparar el plan. Activa Plan Mode, describe la tarea y Claude creará un plan. Guarda el plan en plans/2026-05-21-feature-name.md. Cierra la ventana.
2. Conversación 2: dividirlo en fases. Abre un chat nuevo. Pide: «toma plans/2026-05-21-feature-name.md y divídelo en fases». Guarda el archivo actualizado.
3. Conversación 3: implementar la fase 1. Abre un chat nuevo. Pide: «implementa la fase 1 de plans/2026-05-21-feature-name.md y marca las casillas a medida que completes los elementos». Cierra la ventana.
4. Conversación 4: implementar la fase 2. Haz lo mismo.

¿Qué consigues con esto? La ventana de contexto de cada conversación se mantiene despejada. Claude en la fase 3 no conoce los detalles de la fase 1, pero sí el plan porque el archivo plans/ está en el repositorio. Cualquier agente posterior (un subagente, una sesión nueva o una ejecución mediante /goal) puede retomar el plan y continuar.

Comparación de enfoques:

Cada función tiene su propio archivo de plan. Si tres meses después necesitas recordar por qué elegiste un proveedor de pagos frente a una alternativa, puedes abrir el plan correspondiente y leer el historial de decisiones: qué se debatió, qué opciones se consideraron y por qué se eligió ese camino.

Son planes de trabajo vivos; la documentación estática queda obsoleta en cuestión de meses.

¿Cómo puedes conseguir que Claude trabaje mientras duermes con Plan Mode y /goal?#

La principal limitación de las sesiones largas de IA no es el modelo, sino la persona que pulsa Intro. Cada vez que Claude llega al final de un turno, espera tu respuesta. /goal elimina esa espera.

La sintaxis es sencilla:

/goal all tests in test/auth pass and lint is clean, or stop after 20 turns

La condición puede tener hasta 4000 caracteres. Un objetivo por sesión. Después de cada turno, el min modelo Haiku lee la transcripción y decide: «condición cumplida: terminar» o «no cumplida: siguiente turno». El evaluador no usa herramientas; solo lee.

Alias para borrarlo: /goal stop, /goal off, /goal reset, /goal none, /goal cancel.

La combinación con Plan Mode funciona así:

1. Activa Plan Mode (pulsa Shift+Tab dos veces).
2. Pide: «crea un plan para migrar la base de datos de MySQL a Postgres y guárdalo en plans/2026-05-21-postgres-migration.md con fases y criterios».
3. Revisa el plan, edítalo y apruébalo.
4. Sal de Plan Mode (pulsa Shift+Tab una vez más).
5. Establece un objetivo: «completa todas las fases de plans/2026-05-21-postgres-migration.md, marca las casillas y haz que pasen todas las pruebas, o para tras 50 turnos».
6. Cierra el portátil y vete a dormir.

Por la mañana, comprueba el resultado: «✓ objetivo completado» o «◎ detenido tras 50 turnos», junto con el historial de lo que se hizo.

Hay tres reglas esenciales para /goal; de lo contrario, malgastarás tokens:

Regla 1: Un estado final medible. «Haz que quede bonito» es una mala condición. «npm test devuelve 0, npm run lint devuelve 0 y se ha añadido una entrada a CHANGELOG.md» es una buena condición.

Regla 2: Verificación explícita. La condición debe referirse a algo verificable: un comando, un archivo o un endpoint. No «todo funciona», sino «curl localhost:3000/api/users devuelve 200».

Regla 3: Limita el número de turnos. Añade siempre «o parar tras N turnos». Anthropic lo recomienda expresamente en la documentación:

Si activas /goal sin «parar tras», tu presupuesto podría desaparecer durante la noche.

¿Qué ciclo de 4 pasos convierte Plan Mode en un proceso de ingeniería?#

Un error habitual es preguntar «¿cómo lo arreglo?»: Claude da una solución, la aplicas, pero nada funciona o las cosas empeoran. Esta es la «IA aduladora»: está entrenada para responder rápido y tú quieres llegar antes al código. Un ciclo de 4 pasos lo soluciona.

El ciclo de 4 pasos evita este modo de actuar. Se sigue secuencialmente en una sola sesión de Plan Mode:

Paso 1. Establecer los hechos sin proponer una solución.

Prompt: «Estoy experimentando lo siguiente: [descripción del síntoma]. Tu tarea ahora es establecer los hechos. Se prohíben todas las soluciones, ideas y consejos. Solo: qué observo, qué pasos se pueden reproducir, qué datos están disponibles y qué datos faltan. Condición estricta de parada: NO propongas soluciones; registra únicamente el diagnóstico».

Esto frena el primer impulso de la IA: «aquí está la solución». Claude debe detenerse en «qué se sabe y qué se desconoce».

Paso 2. Desarrollar opciones con precedentes.

Prompt: «Ahora que el diagnóstico está establecido, busca en Internet precedentes para resolver problemas parecidos. Al menos 3 enfoques distintos. Para cada uno: un enlace a la fuente primaria, una breve descripción y ventajas e inconvenientes para nuestra situación».

Esto frena el segundo impulso de la IA: «inventar una solución sobre la marcha». Hacemos que salga al mundo y nos traiga enfoques que podamos comprobar.

Paso 3. Plan detallado con riesgos.

Prompt: «Toma la mejor opción del paso 2 y elabora un plan detallado: qué archivos concretos tocar, qué añadir, qué eliminar, qué pruebas escribir, qué podría fallar y qué riesgos hay a 2-3 pasos vista».

Es la conocida fase Plan, pero con una diferencia: se basa en las opciones verificadas del paso 2, no en las conjeturas de Claude.

Paso 4. Autocomprobación del plan.

Prompt: «Haz ahora una autocomprobación obligatoria. Revisa tu plan con sinceridad: ¿hay partes en las que te hayas sacado algo de la nada y no lo hayas comprobado con el código, la documentación o un precedente del paso 2? Si es así, señálalas y revisa el plan».

Este es el filtro final. Claude debe revisar su propio razonamiento y admitir dónde ha alucinado. En este paso suelen revisarse al menos 2 elementos del plan.

Tras los 4 pasos, el plan está listo para aprobarlo. Puedes pasar a la implementación con la confianza de que la tarea se entiende, se han evaluado las opciones y se han tenido en cuenta los riesgos.

Esta metodología está pensada para diagnosticar errores difíciles y tomar decisiones arquitectónicas, situaciones en las que equivocarse sale caro. Aplicada a Plan Mode, elimina el principal problema de quienes programan por intuición: «la IA me dio una solución, la apliqué y todo se rompió».

¿Qué 5 prompts listos para usar funcionan en Plan Mode para tareas habituales?#

Plantilla 1. Refactorizar un módulo.

Voy a activar Plan Mode. Tarea: refactorizar el módulo {module-name}.

Paso 1: Estudia la estructura actual del módulo {module-path}. Describe:
- qué archivos forman parte del módulo
- qué dependencias externas tiene
- qué partes están duplicadas
- qué funciones son demasiado complejas

Paso 2: Busca en Internet 2-3 ejemplos de refactorización de módulos similares.
Al menos 1 fuente debe ser documentación oficial de Anthropic o del framework relacionado.

Paso 3: Crea un plan de refactorización en plans/YYYY-MM-DD-refactor-{module}.md:
- qué archivos renombrar
- qué funciones extraer a módulos independientes
- qué pruebas conservar y cuáles reescribir
- riesgos: qué podría fallar para los usuarios

Paso 4: Autocomprobación. ¿Hay suposiciones en el plan sacadas de la nada?
Reescríbelas o elimínalas.

Plantilla 2. Migración de base de datos.

Voy a activar Plan Mode. Tarea: migrar la base de datos de {old} a {new}.

Paso 1: Estudia el esquema actual de la base de datos mediante {schema-reading-command}. Describe:
- qué tablas existen y qué tamaño tienen
- qué relaciones, índices y restricciones hay
- dónde se guardan las migraciones
- qué datos son críticos

Paso 2: Busca precedentes de migraciones de {old → new} en proyectos de producción.
Al menos 3 enfoques distintos: pg_dump, dual-write, blue-green.
Para cada uno, enumera las ventajas y los riesgos para nuestro volumen de datos.

Paso 3: Crea un plan de migración en plans/YYYY-MM-DD-db-migration.md:
- fases (copia de seguridad, migración, verificación, cambio)
- criterios de éxito para cada fase
- plan de reversión si algo sale mal
- interrupción del servicio o sin interrupción

Paso 4: Autocomprobación. ¿Están respaldadas todas las cifras por la documentación?
¿Se han contrastado mentalmente todos los pasos con el entorno de desarrollo?

Plantilla 3. Añadir una función nueva.

Voy a activar Plan Mode. Tarea: añadir la función {description} al proyecto.

Paso 1: Estudia cómo funcionan actualmente en el proyecto otras funciones similares.
Fíjate especialmente en:
- {file-1}
- {file-2}
- qué patrones arquitectónicos se utilizan
- qué pruebas se han escrito para funciones similares

Paso 2: Busca cómo se implementa esta función en proyectos de código abierto
con una arquitectura similar. Al menos 2 enfoques distintos.

Paso 3: Crea un plan en plans/YYYY-MM-DD-feature-{name}.md:
- lista de archivos nuevos
- lista de archivos modificados con líneas concretas
- secuencia de implementación
- qué pruebas añadir
- qué añadir a CLAUDE.md como regla para futuras sesiones

Paso 4: Autocomprobación. ¿Sigue el plan la arquitectura del proyecto?
¿Da por supuestas bibliotecas que aún no están instaladas?

Plantilla 4. Escribir pruebas.

Voy a activar Plan Mode. Tarea: cubrir el módulo {name} con pruebas.

Paso 1: Estudia el módulo {path}. Identifica:
- funciones públicas y sus firmas
- funciones internas que NO vamos a probar (detalles de implementación)
- casos límite: entrada vacía, errores, acceso concurrente

Paso 2: Busca ejemplos de pruebas para una clase de tareas similar
en proyectos populares de código abierto que utilicen el mismo framework.

Paso 3: Crea un plan de pruebas en plans/YYYY-MM-DD-tests-{module}.md:
- una lista de pruebas para cada función pública
- qué mocks se necesitan
- qué fixtures hacen falta
- qué método de verificación se usará (estilo de aserción)

Paso 4: Autocomprobación. ¿Comprueban todas las pruebas el comportamiento y no la implementación?
¿La cobertura incluye los casos límite?

Plantilla 5. Depurar un error complejo.

Voy a activar Plan Mode. Tarea: averiguar la causa del error {symptom-description}.

Paso 1: ESTABLECE LOS HECHOS. Se prohíben las soluciones y las ideas. Solo:
- qué observo (el texto exacto del error)
- pasos reproducibles
- qué datos están disponibles (registros, trazas, versiones de bibliotecas)
- qué datos faltan (qué se debe recopilar adicionalmente)

Paso 2: Busca precedentes de este error.
Al menos 3 fuentes: incidencias de GitHub y documentación.
Para cada una, proporciona un enlace y un breve resumen de la solución.

Paso 3: Crea un plan de diagnóstico en plans/YYYY-MM-DD-bug-{name}.md:
- qué hipótesis comprobar (ordenadas por probabilidad)
- qué comandos/scripts ejecutar para comprobar cada una
- el resultado esperado de cada comprobación

Paso 4: Autocomprobación. ¿Hay hipótesis en el plan sacadas de la nada?
¿Están todas las hipótesis vinculadas a hechos del paso 1?

Copia cada plantilla, sustituye {parameters} por tus propios valores y pégala en Claude Code en Plan Mode. El resultado será un plan de trabajo en plans/ que podrás aprobar y utilizar para la implementación.

Plan Mode o modo normal: ¿cuál deberías elegir?#

Anthropic lo dice claramente en su documentación:

La guía de buenas prácticas de Anthropic presenta la planificación como una herramienta útil que añade trabajo. Valora el alcance real, el conocimiento del código y el riesgo; poder describir un objetivo en una frase no demuestra que el cambio sea de bajo riesgo.

Omite un plan separado solo si el diff real es pequeño, entendido y de bajo riesgo. Planifica si debes descubrir el enfoque o coordinar cambios arriesgados entre componentes. Conocer los archivos o resumir el objetivo en una frase no elimina riesgos de migración, autenticación o integridad de datos.

Tabla para decidir:

Antes de elegir modo, pregunta si entiendes enfoque, efectos secundarios y verificación. Actúa directamente en un cambio pequeño, localizado y de bajo riesgo con prueba evidente. Planifica primero ante incertidumbre, código desconocido, migraciones, autenticación o coordinación entre componentes, aunque puedas nombrar los 3–5 archivos afectados.

¿Cómo combinas Plan Mode + CLAUDE.md + subagentes para trabajar con fiabilidad?#

CLAUDE.md es un archivo que Claude lee al comienzo de cada sesión, también en Plan Mode. Si CLAUDE.md dice «no codifiques fechas directamente; obténlas siempre de la base de datos», el plan nunca propondrá codificarlas. Si no existe esa regla, el plan puede proponer cualquier cosa.

La combinación funciona así:

Capa 1. CLAUDE.md establece las reglas.

El archivo especifica la pila tecnológica del proyecto, sus principios arquitectónicos, prohibiciones («no uses API obsoletas») y requisitos («todos los correos deben pasar por una plantilla compartida»). Guía detallada: Cómo configurar CLAUDE.md.

Capa 2. Plan Mode aplica las reglas a la tarea.

Cuando activas Plan Mode y pides «añade OAuth», Claude lee CLAUDE.md, ve las reglas («guarda los tokens en Redis, no en la base de datos») y las incorpora de inmediato al plan. El plan se ajusta a la arquitectura del proyecto.

Capa 3. Los subagentes dividen el trabajo.

Si el plan se divide en fases, puedes asignar cada fase a un subagente distinto. Cada subagente trabaja en su propia ventana de contexto sin saturar la principal. El plan de plans/ sigue siendo la fuente central de la verdad: los subagentes lo leen, ejecutan su fase y actualizan las casillas.

¿Qué 7 errores hacen fracasar Plan Mode?#

Error 1. El plan solo existe en el chat.

Síntoma: escribiste un plan, cerraste la ventana y necesitas retomarlo al día siguiente, pero no hay nada; el contexto se ha perdido. Solución: guarda siempre el plan en plans/YYYY-MM-DD-feature-name.md dentro del repositorio. El chat es el escritorio; el archivo es el archivo histórico.

Error 2. Todas las tareas están en un solo chat.

Síntoma: en una sesión hablas de autenticación, luego de una migración, después del diseño de la interfaz y luego de un error. La ventana de contexto se «infla» y Claude olvida lo anterior. Solución: una tarea, una conversación. ¿Has terminado el plan? Cierra la ventana. ¿Vas a empezar la implementación? Abre otra.

Error 3. Un plan de 3000 líneas sin fases.

Síntoma: tienes un plan, pero no hay casillas ni divisiones. Es imposible saber qué está hecho y qué no. No puedes delegar. Solución: divide cada plan en 3-7 fases. Cada fase debe ser una lista de casillas con acciones concretas.

Error 4. No investigar a fondo antes de preparar el plan.

Síntoma: Claude propone una solución sobre la marcha porque no le pediste que buscara precedentes. Una semana más tarde descubres que el código abierto lleva mucho tiempo ofreciendo un enfoque mejor. Solución: el paso 2 del ciclo de 4 pasos: haz que Claude encuentre 2-3 precedentes en Internet antes de crear un plan.

Error 5. La IA aduladora propone una solución sin diagnosticar.

Síntoma: preguntas «¿cómo arreglo el error X?», Claude te da una solución, la aplicas y nada funciona o todo empeora. Solución: empieza siempre por «establece los hechos; las soluciones están prohibidas». Pasa a las opciones solo después del diagnóstico.

Error 6. Saltarse la autocomprobación.

Síntoma: el plan parece razonable, pero incluye 2-3 suposiciones sacadas de la nada (una biblioteca inventada, una API inexistente o una versión equivocada). La implementación falla en esos puntos. Solución: paso 4 del ciclo de 4 pasos: pide a Claude que vuelva a comprobar honestamente el plan y señale las suposiciones.

Error 7. Condiciones vagas en /goal.

Síntoma: configuras /goal que quede bonito, lo dejas toda la noche y al despertar descubres que se han consumido $200 de tu cuota. Solución: usa solo condiciones medibles, con un comando de verificación y un límite obligatorio: «o parar tras N turnos». Nada de «hazlo bien» o «púlelo».

El octavo error, el más común entre quienes programan por intuición, es ignorar la propia idea de una carpeta plans/. Plan Mode sin una carpeta plans/ no es una metodología; es un juguete. Si usas Plan Mode sin crear archivos, obtienes el 10% de sus capacidades.

¿Qué deberías hacer después de tu primera experiencia con Plan Mode?#

Tres pasos concretos, de menor a mayor dificultad:

Paso 1. Configura CLAUDE.md si aún no tienes uno.

Sin CLAUDE.md, Plan Mode funciona «en el vacío»: Claude no conoce las reglas del proyecto y propone planes que rompen la arquitectura. Guía completa: Cómo configurar CLAUDE.md. Un CLAUDE.md mínimo tiene 50-80 líneas que describen la pila tecnológica, las reglas y las prohibiciones. La longitud es secundaria; lo que importa es la especificidad.

Paso 2. Crea una carpeta plans/ en el repositorio.

Añade una carpeta plans/ a la raíz del proyecto. Acuerda un formato de nombres: YYYY-MM-DD-feature-name.md. Cada plan tendrá su propio archivo. Al cabo de un mes tendrás 20-30 archivos; al cabo de seis meses, 100+. Ese es el historial vivo de las decisiones del proyecto.

Paso 3. Prueba /goal con una tarea.

Elige una tarea que normalmente haces a mano en 30-40 minutos. Activa Plan Mode, crea un plan y guárdalo en plans/. Sal de Plan Mode. Establece /goal completa todas las fases de plans/file.md, pasan todas las pruebas o para tras 30 turnos. Cierra el portátil durante una hora y haz otra cosa. Vuelve y comprueba el resultado.

Esos tres pasos son lo mínimo. Esto se construye poco a poco; no intentes montarlo todo en una noche. Empieza con CLAUDE.md, añade plans/ después de una semana y prueba /goal durante la noche al cabo de un mes.

Cuando estés listo, descubre Ailoot.