Reemplaza Plan Mode con OpenSpec en Cursor y Claude Code

TL;DR

• Plan Mode integrado (el modo Shift+Tab de Cursor y --permission-mode plan de Claude Code) hace bien una cosa: posponer las ediciones de código hasta que apruebes un plan en Markdown.
• OpenSpec reemplaza esa opción predeterminada por un ciclo de planificación integrado al repositorio que sobrevive a los reinicios del chat, facilita la revisión del equipo en git y separa el análisis del compromiso con una solución de forma más explícita que un solo archivo plan.md.
• La correspondencia entre ambos es sencilla:

Plan Mode "research + plan"     ->  /opsx:explore
Plan Mode "approved plan file"  ->  /opsx:propose  (proposal + specs + design + tasks)
Plan Mode "Build"               ->  /opsx:apply
Plan archive / team memory      ->  /opsx:archive   (+ merged specs in openspec/specs/)

• OpenSpec se siente más ligero porque el perfil core predeterminado consiste en cinco comandos de chat y un openspec init, no en una ceremonia de SDD compleja.
• La razón por la que explore se mantiene agnóstico no es magia. Está escrita en los archivos de skills y comandos: no escribir código, no crear una carpeta de cambio, no forzar una conclusión y ofrecer registrar lo conversado en vez de hacerlo automáticamente.
• Mi recomendación: usa OpenSpec como tu capa de planificación predeterminada en Cursor o Claude Code. Reserva Plan Mode nativo para tareas rápidas y puntuales que no necesiten specs duraderas, no como tu sistema principal de planificación de producto.

Qué aprenderás aquí

• Qué hace realmente Plan Mode en Cursor y Claude Code, y dónde se queda corto para mantener planes duraderos
• Por qué OpenSpec es un reemplazo completo viable, no solo un complemento
• Cómo se corresponden /opsx:explore, /opsx:propose y /opsx:apply con las fases conocidas de planificación
• Cómo están escritos los skills y comandos de OpenSpec para evitar cambios no deseados durante la exploración
• Una ruta práctica de configuración para ingenieros y personas sin perfil técnico en un mismo equipo
• Cuándo seguiría usando Plan Mode nativo

El July 6, 2026, revisé la documentación de Plan Mode de Cursor, la guía de flujos de trabajo comunes de Claude Code de Anthropic, el repositorio Fission-AI/OpenSpec (incluidas la guía de explore y la documentación del flujo OPSX) y los skills y comandos de OpenSpec instalados en este repositorio bajo .cursor/skills/ y .cursor/commands/. El comportamiento del producto y la redacción de los límites que se describen a continuación están respaldados por las fuentes citadas. La recomendación de «reemplazar Plan Mode como opción predeterminada» es mi criterio editorial para equipos que ya colaboran con git.

Para configurar OpenSpec de forma práctica, consulta Cómo empezar con OpenSpec. Para conocer el ciclo completo de entrega, incluidos los PR y el momento de archivar, consulta OpenSpec a lo largo de todo el flujo de desarrollo.

El problema de usar Plan Mode como única capa de planificación

Plan Mode resuelve un problema real: los agentes se apresuran a escribir código antes de que las personas acuerden qué quieren lograr.

La documentación de Cursor describe Plan Mode como un flujo en el que el agente investiga el código, hace preguntas para aclarar dudas, crea un plan que puedes revisar y espera a que hagas clic en Build. Puedes activarlo con Shift+Tab en la entrada del agente o desde el selector de modo. Claude Code documenta la misma idea bajo Plan before editing con claude --permission-mode plan (y la posibilidad de activar o desactivar el modo de planificación durante una sesión). Ambas herramientas comparten el mismo contrato básico: primero leer y proponer; editar solo después de la aprobación.

Esa disciplina es valiosa. La limitación está en lo que sucede después del plan:

Plan Mode session
  -> plan.md (often outside git, or saved manually)
  -> Build in Agent mode
  -> chat context eventually resets
  -> "why did we choose Redis?" lives in scrollback, not the repo
  -> next agent session re-discovers the same codebase from scratch

La documentación de Cursor señala que los planes se guardan por defecto en tu directorio personal, con un paso opcional de Save to workspace, normalmente bajo .cursor/plans/. Eso es útil para retomar tu trabajo personal. Es menos sólido como acuerdo de equipo, a menos que todos adopten el mismo hábito de guardado y la misma práctica de revisión.

El planteamiento de OpenSpec en openspec.dev apunta precisamente a cubrir esa brecha: specs que perduran entre sesiones, viven junto al código y se incorporan a una fuente de verdad que crece después de cada entrega. La guía de explore explica claramente la intención del producto: explore sirve para cuando tienes un problema, pero todavía no un plan, y da paso a propose cuando el panorama está claro.

Por qué OpenSpec puede reemplazar por completo a Plan Mode

«Reemplazar por completo» suena categórico. Esta es mi afirmación precisa:

Reemplazar Plan Mode como espacio de planificación predeterminado, no eliminar la función de tu IDE.

OpenSpec gana como opción predeterminada porque te da la mejor propiedad de Plan Mode (pensar antes de escribir código) más propiedades que Plan Mode no estandariza:

El README de OpenSpec (a fecha de July 2026) describe el flujo OPSX renovado como intencionalmente ligero, orientado primero a proyectos existentes y fluido: puedes iterar sobre los artefactos mientras programas, en lugar de fijar un PRD monolítico. Ese es el argumento a favor de su durabilidad: el plan no es un solo archivo Markdown, sino un pequeño conjunto de artefactos vinculados con funciones explícitas.

Para quienes no son ingenieros, la diferencia práctica está en lo que pueden revisar:

• Plan de Plan Mode: «Edita estos 12 archivos, agrega una capa de caché y actualiza las pruebas».
• Paquete de propuesta de OpenSpec: «Por qué hacemos esto, qué comportamiento cambia (escenarios de las specs), cómo lo implementaremos y la lista ordenada de tareas».

Los PMs pueden comentar proposal.md y los escenarios de las specs sin leer diffs. Los ingenieros siguen teniendo tareas a nivel de archivo en tasks.md. La misma carpeta de cambio, dos capas legibles.

Qué revisa realmente un PM (breve recorrido)

Después de /opsx:propose, una carpeta de cambio podría verse así:

openspec/changes/add-guest-checkout/
|-- proposal.md          <- start here: problem, scope, non-goals
|-- specs/
|   `-- checkout/spec.md <- behavior scenarios (WHEN/THEN)
|-- design.md            <- technical approach (optional skim)
`-- tasks.md             <- engineering checklist (usually not PM-owned)

Un PM puede aprobar la propuesta u objetarla usando solo proposal.md y los escenarios de las specs. Preguntas como «¿La compra como invitado requiere un correo electrónico?» pertenecen al archivo de la spec, no a un largo hilo de chat. Esa es la ventaja de durabilidad frente al único plan de Plan Mode, orientado a la implementación.

El flujo de reemplazo

Piensa en OpenSpec como Plan Mode dividido en fases explícitas con límites estrictos:

                    OPEN SPEC AS PLAN-MODE REPLACEMENT
                    ==================================

  Vague idea                Clear idea                 Ready to ship
      |                         |                            |
      v                         v                            v
 /opsx:explore            /opsx:propose                 /opsx:apply
 (think, no artifacts)    (durable plan pack)           (task-by-task build)
      |                         |                            |
      |    "let's propose"      |                            |
      +------------------------>|                            |
                                |                            v
                                +----------------------> /opsx:archive
                                                         (merge specs, history)

Fase 1 — Explore en lugar de la «investigación de Plan Mode»

La guía de explore de OpenSpec define explore como una conversación, no un generador. Lee código, compara opciones, dibuja diagramas y ayuda a delimitar el alcance, pero explícitamente no crea una carpeta de cambio, escribe artefactos ni modifica código.

Es el sustituto directo de la mitad de investigación de Plan Mode, con una diferencia crucial: explore se niega a producir un «documento de plan» que parezca terminado antes de que realmente hayas tomado una decisión.

Fase 2 — Propose en lugar de «guardar el plan en el workspace»

Cuando ejecutas /opsx:propose add-rate-limiting, OpenSpec crea openspec/changes/add-rate-limiting/ con el paquete de planificación. La CLI determina el orden de los artefactos mediante openspec status --change ... --json para que el agente no omita dependencias.

Esto reemplaza el momento de Plan Mode en el que revisas plan.md y haces clic en Build, con la diferencia de que el resultado está estructurado tanto para la revisión de producto como para la ejecución técnica.

Fase 3 — Apply en lugar de «Build» en modo Agent

/opsx:apply lee el contexto del cambio, muestra el avance de las tareas, implementa las pendientes y marca las casillas en tasks.md. Los límites del skill de apply exigen leer los archivos de contexto proporcionados por la CLI, hacer una pausa ante la ambigüedad y mantener las ediciones dentro del alcance. La intención es la misma que en el paso Build de Plan Mode —no desviarse del plan aprobado—, pero vinculada a una lista de tareas auditable.

Fase 4 — Archive en lugar de «cerrar el ticket del plan»

Después del merge, /opsx:archive mueve el cambio a openspec/changes/archive/ y ofrece sincronizar las specs delta con openspec/specs/. Plan Mode no tiene un paso estándar equivalente; OpenSpec considera que registrar lo que se entregó es parte de la planificación, no documentación opcional.

Cómo están escritos los skills para evitar cambios no deseados

El temor más común al reemplazar Plan Mode es: «¿El agente seguirá saltando a la implementación o eligiendo una solución demasiado pronto?»

OpenSpec aborda ese problema en el texto de los skills y comandos que carga tu asistente, no solo en el marketing del producto. Las copias de este repositorio en .cursor/skills/openspec-explore/SKILL.md y .cursor/commands/opsx-explore.md son representativas de lo que instala openspec init.

Explore: una postura, no un flujo de trabajo

El skill de explore comienza con una restricción estricta. Este es el texto real que openspec init escribe en .cursor/skills/openspec-explore/SKILL.md:

Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.

**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.

**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.

El comando slash complementario repite el mismo límite al comienzo de .cursor/commands/opsx-explore.md, de modo que tanto el mecanismo de descubrimiento del skill como la invocación explícita de /opsx:explore cargan los mismos límites.

Esa redacción importa para dos públicos:

• Los ingenieros pueden investigar sin provocar un commit con la estructura inicial de un cambio.
• Las personas sin perfil técnico cuentan con un modo que no editará el producto silenciosamente porque la conversación «parecía concluyente».

Explore: agnóstico por diseño

Tres decisiones de diseño impiden que explore imponga una solución inferida:

1. Curioso, no prescriptivo

La sección sobre la postura incluye «Curioso, no prescriptivo» y «Hilos abiertos, no interrogatorios»: presenta varias direcciones en lugar de conducir la conversación mediante un único cuestionario.

2. Ningún artefacto obligatorio

En «Lo que no tienes que hacer»:

• No tienes que producir un artefacto específico
• No tienes que llegar a una conclusión
• No tienes que mantenerte en el tema si una digresión es valiosa

Compáralo con Plan Mode, cuya condición de éxito está optimizada para producir un plan listo para implementar. Explore permite explícitamente terminar con claridad, pero sin ningún archivo.

3. Ofrecer registrar lo conversado; nunca hacerlo automáticamente

Cuando ya existe un cambio, el skill indica al agente que ofrezca actualizaciones, no que las realice silenciosamente:

4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.

La sección de límites refuerza la misma idea:

## Guardrails

- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
- **Don't fake understanding** - If something is unclear, dig deeper
- **Don't rush** - Discovery is thinking time, not task time
- **Don't force structure** - Let patterns emerge naturally
- **Don't auto-capture** - Offer to save insights, don't just do it

Ese es el límite que las personas sin perfil técnico más perciben en la práctica: el asistente sugiere; la persona decide qué se registra.

La documentación oficial de explore coincide con los skills

La guía oficial de explore enumera los mismos límites:

• Sí hace: leer y buscar en el código, comparar opciones, crear diagramas, delimitar el alcance y dar paso a propose
• No hace: crear una carpeta de cambio, escribir artefactos ni escribir o modificar código

También recomienda: «Trae el problema, no la solución». Por ejemplo, di «el inicio de sesión se siente lento» en lugar de «agrega Redis», para que la investigación no parta de una solución predeterminada.

Propose y apply: límites complementarios

Explore está diseñado para no requerir permisos previos. Las fases siguientes imponen más disciplina:

Propose (skill openspec-propose):

• Exige entender qué se va a construir antes de crear un cambio
• Usa las dependencias de artefactos de la CLI: no permite saltar directamente a las tareas sin specs cuando el esquema las requiere
• Trata context y rules de las instrucciones de la CLI como restricciones para el agente, no como texto que debe pegar en los archivos

Apply (skill openspec-apply-change):

• Lee todos los archivos de contexto de openspec instructions apply --json antes de programar
• Marca las tareas como completadas una por una
• Hace una pausa ante la ambigüedad en lugar de adivinar
• Permite actualizar los artefactos cuando la implementación revela problemas de diseño: es fluido, no está limitado rígidamente por fases

El bloque de límites del skill de apply indica explícitamente que se debe hacer una pausa en lugar de adivinar:

**Guardrails**
- Keep going through tasks until done or blocked
- Always read context files before starting (from the apply instructions output)
- If task is ambiguous, pause and ask before implementing
- If implementation reveals issues, pause and suggest artifact updates
- Keep code changes minimal and scoped to each task
- Update task checkbox immediately after completing each task
- Pause on errors, blockers, or unclear requirements - don't guess
- Use contextFiles from CLI output, don't assume specific file names

En conjunto, estos skills implementan un modelo de compromiso progresivo:

explore     -> zero repo commitment
propose     -> planning commitment (artifacts in git)
apply       -> code commitment (scoped to tasks.md)
archive     -> historical commitment (merged specs)

Plan Mode combina las dos primeras etapas en un solo modo de interfaz. OpenSpec las separa para que «pensar» y «llegar a un acuerdo» tengan distintos niveles de seguridad.

Implementación: cambia tu opción predeterminada en Cursor o Claude Code

Configuración inicial

npm install -g @fission-ai/openspec@latest
cd your-project
openspec init

Selecciona Cursor o Claude Code, o ambos, durante la inicialización. Reinicia el IDE para que se registren los comandos slash. OpenSpec crea skills y comandos (en .cursor/ o en rutas específicas de la herramienta), además de openspec/config.yaml.

Cambia tu hábito de planificación

Ejemplo: pedidos duplicados al finalizar la compra (de la documentación de OpenSpec)

La guía de explore de OpenSpec muestra una transición realista:

You: /opsx:explore
     Our checkout sometimes creates duplicate orders.

AI:  [reads order service, webhook handler, client submit logic]
     Two root causes: double client submit vs duplicate webhook handling.
     Three fixes ranked; idempotency key fits existing payment-intent storage.

You: /opsx:propose add-order-idempotency-key

AI:  Created change folder with proposal + delta spec grounded in exploration.

Observa la separación: la exploración podría haber terminado en «todavía no vale la pena corregirlo» sin generar ruido en el repositorio. Plan Mode seguiría presionando hacia un plan listo para implementar.

Regla de trabajo del equipo (ingenieros y PMs)

1. PM or engineer opens /opsx:explore for fuzzy requests
2. Engineer runs /opsx:propose when scope is concrete
3. PM reviews proposal.md + spec scenarios (behavior, not files)
4. Engineer runs /opsx:apply on a feature branch
5. PR links to the change folder
6. After merge, /opsx:archive

Las personas sin perfil técnico participan en los pasos 1–3 y 5 sin usar el modo Agent. Los ingenieros se encargan del 4 y el 6. Esa división es más difícil de mantener cuando el plan vive solo en el chat o en un archivo del directorio personal que no se guardó.

Opcional: reglas de proyecto que refuercen el cambio

Agrega una regla breve a .cursor/rules o CLAUDE.md:

## Planning default

- Use OpenSpec instead of Plan Mode for non-trivial work.
- Fuzzy idea -> /opsx:explore (no artifacts, no code)
- Ready to agree -> /opsx:propose
- Ready to build -> /opsx:apply on a feature branch
- Do not skip propose and jump to apply for multi-file features.

Esto no desactiva Plan Mode. Orienta al equipo hacia artefactos duraderos.

ASCII: flujo de control de Plan Mode vs OpenSpec

PLAN MODE (single mode, two outcomes)
=====================================
        +------------------+
        |    Plan Mode     |
        |  read + question |
        +--------+---------+
                 |
       +---------+---------+
       |                   |
       v                   v
  plan.md (optional    Build -> code
  git save)            (same session)


OPEN SPEC (explicit gates)
==========================
 +----------+    +----------+    +--------+    +---------+
 | explore  | -> | propose  | -> | apply  | -> | archive |
 | no write |    | artifacts|    | code   |    | history |
 +----------+    +----------+    +--------+    +---------+
      |               |
      |               +--> proposal.md  (why)
      |               +--> specs/       (what behavior)
      |               +--> design.md    (how)
      |               +--> tasks.md     (steps)
      |
      +--> safe to stop with zero files

A qué renuncias y cuándo sigo usando Plan Mode

OpenSpec tiene sus costos:

• Archivos adicionales en el repositorio (normalmente una ventaja para equipos, pero una fricción para experimentos individuales que se descartarán)
• Configuración inicial (openspec init, descubrimiento de comandos) frente al uso inmediato de Shift+Tab
• Explore es más lento cuando ya sabes cuál es el cambio exacto: la documentación oficial indica que, en ese caso, puedes omitir explore

Sigo usando Plan Mode nativo cuando:

• el cambio realmente afecta a un solo archivo y es reversible
• no necesito specs de comportamiento ni revisión del equipo
• quiero el ciclo personal más rápido posible de plan → implementación, sin un artefacto en git

Para todo lo que pueda durar más de una semana —funcionalidades, correcciones de bugs que afectan el comportamiento, solicitudes entre equipos—, OpenSpec es la mejor opción predeterminada.

En qué se diferencia este artículo de otros sobre planificación en este devlog

• Herramientas de planificación con IA: Claude Code, Cursor y Beads compara tres herramientas distintas y trata la planificación como una capa entre muchas. Este artículo plantea una afirmación más específica: OpenSpec puede ser tu capa de planificación predeterminada dentro de Cursor o Claude Code.
• Las partes 1–2 de la serie sobre flujos de OpenSpec cubren los primeros pasos y OPSX avanzado. Este artículo se centra en por qué los límites de explore/propose reemplazan Plan Mode, con el diseño interno de los skills como evidencia.

Si estás evaluando OpenSpec frente a GitHub Spec Kit o necesitas comandos ampliados como /opsx:verify, lee OpenSpec avanzado en lugar de considerar este artículo como la única guía de OpenSpec.

Fuentes

Fuentes primarias (consultadas o verificadas el July 6, 2026):

• Documentación de Cursor: Plan Mode — comportamiento de planificar antes de construir, Shift+Tab y guardado opcional en el workspace
• Blog de Cursor: presentación de Plan Mode — editor de planes, preguntas para aclarar dudas e implementación a partir del plan
• Blog de Cursor: mejores prácticas para agentes — cuándo planificar y cuándo usar el agente directamente, y consejo sobre .cursor/plans/
• Documentación de Anthropic Claude Code: flujos de trabajo comunes — claude --permission-mode plan y guía para planificar antes de editar
• OpenSpec — openspec.dev — enfoque de planificación ligera, orientada a proyectos existentes y persistente entre sesiones
• README de Fission-AI/OpenSpec — flujo OPSX y comandos del perfil core (explore, propose, apply, sync, archive)
• Documentación de OpenSpec: explore.md — límites de lo que explore hace y no hace, y transición a propose
• Documentación de herramientas compatibles de OpenSpec — integraciones de asistentes instaladas por openspec init
• Artefactos de instalación local en este repositorio: .cursor/skills/openspec-explore/SKILL.md, .cursor/commands/opsx-explore.md, .cursor/skills/openspec-propose/SKILL.md, .cursor/skills/openspec-apply-change/SKILL.md

Lecturas relacionadas en este devlog:

• Cómo empezar con OpenSpec
• OpenSpec a lo largo de todo el flujo de desarrollo
• OpenSpec avanzado: flujos ampliados y esquemas personalizados
• Herramientas de planificación con IA: Claude Code, Cursor y Beads — enfoque de herramientas complementarias (Beads para la persistencia de tareas)