Retomar a mitad de proyecto

Dejaste un proyecto hace dos semanas, o eres una sesión de agente fresca sin memoria de él. No empieces leyendo archivos y adivinando dónde estabas.

Ejecuta resume primero

/flow resume

Este es el primer verbo que escribes al entrar a un proyecto a mitad de ciclo. Es de solo lectura, no toma candado, y compone un resumen de historia de sesión desde el estado que ya existe en disco:

la última sesión, solo por nombres de comandos — nunca argumentos crudos
la card en vuelo y cuánto lleva parada (dwell)
el estado actual del gate
exactamente una línea NEXT ->

Lee la línea NEXT -> y haz eso. La produce el mismo helper de decisión que usa /flow status, así que los dos nunca discrepan.

Cuándo saltarlo

Salta resume cuando ya tienes contexto vivo en esta conversación — si eres quien acaba de ejecutar next o card hace un minuto, ejecutarlo de nuevo no añade nada. Es para entrada en frío, no para cada comando.

Luego obtén la vista de trabajo

/flow

/flow solo es status: dónde estás, qué bloquea, dwell del stage actual, la lista de cards (compactada a un resumen más allá de diez cards), y un resumen de memoria de una línea. Usa resume para reentrar, status para seguir trabajando.

Recall y promote

/flow recall

Ejecuta recall al inicio de un stage o una card, antes de redactar nada. Lee de vuelta la capa durable: deuda abierta, la retro más reciente, el alcance de la card anterior, fricción y backlog del harness, salud de la auditoría, y cualquier playbook promovido. Trata la salida como contexto que aplicar, no como ruido, para que el trabajo empiece con el dolor previo a la vista en lugar de redescubrirlo.

La captura la dispara el motor, no es voluntaria: avanzar más allá del stage 01 siembra un intake, una comprobación de card que pasa registra una traza con nivel, y un skip deliberado registra su deuda. status muestra un resumen de memoria de una línea; card inyecta automáticamente el alcance de la card anterior. La mejora también es mecánica: harness audit puntúa entropía y deriva, harness propose mina la fricción repetida en un backlog de mejora una vez que un patrón se dispara al menos dos veces, y harness decision outcome cierra el ciclo predicho-versus-real.

Una ventana de conversación olvida. Un registro durable no.

Promote un playbook

Cuando una lección es más grande que un proyecto, elévala:

/flow promote <playbook.md>

Eso copia el playbook a la base de conocimiento entre proyectos en ~/.claude/flow/playbooks. Desde entonces recall lo muestra en todas partes, no solo donde se aprendió.

El ciclo es captura, reutilización, mejora: next y check escriben registros automáticamente, recall los lee de vuelta, y promote comparte los que se lo ganaron.

Para motores extra (Codex y Antigravity) y el resto del ciclo durable, ver Orquestación de agentes.

Desbloquear una sesión obsoleta

flow permite una sesión por proyecto. Dos sesiones compartiendo un plan sobrescriben el estado de la otra. El runner mantiene un flow/.lock: comandos mutantes como next, card, skip y auto rechazan un candado extranjero fresco, status advierte, y el candado se auto-reclama después de su TTL — FLOW_LOCK_TTL, 900 segundos por defecto.

/flow unlock

Úsalo solo cuando la otra sesión esté genuinamente muerta — una terminal caída, una ventana abandonada. Si otra sesión está viva, para y coordina con quien la esté ejecutando. Nunca fuerces ante un candado vivo; las ejecuciones concurrentes corrompen el plan.

FLOW_FORCE=1 toma un candado que estás seguro de que está muerto. /flow unlock lo limpia. Si el runner reporta BLOCKED por el candado de otra sesión, para y coordina — nunca FLOW_FORCE ante una sesión viva.

Para protección dura en lugar de advertencia, exporta un id de sesión estable una vez por sesión y pásalo en cada llamada:

export FLOW_SESSION_ID=$(uuidgen)
FLOW_SESSION_ID=$FLOW_SESSION_ID bash ~/.claude/skills/flow/runner/flow.sh next

Sin él, el runner solo puede advertir — no puede probar una sesión distinta, así que nunca se autobloquea.

Evaluar un brownfield

Un proyecto con código pero sin directorio flow/ es brownfield. Aún no hay historia de sesión que recuperar, así que no empieces con resume. Un código existente no empieza en el stage Idea. /flow assess prepara y pone gates a flow/00-inspect.md — un mapa del estado actual — antes de que se abra cualquier stage de planificación. La planificación de un sistema existente debería basarse en lo que hay, no en lo que dice el README del repositorio que hay.

Los proyectos greenfield saltan esto y empiezan en /flow next (Idea).

Pasos del operador

Desde la raíz del proyecto, ejecuta:
```
/flow assess
```
La primera ejecución copia la plantilla de inspección a flow/00-inspect.md, siembra un auto-escaneo (stack, CI, archivos de contexto, superficies rankeadas), y siembra archivos de ley. Aún no pasa el gate.
Rellena cada sección desde evidencia (lee el código):
- comandos de stack / build / test / run desde archivos reales
- componentes principales, módulos y puntos de entrada
- funcionalidad actual (funciona / parcial / stub / ausente) con evidencia de archivos
- estado UI/UX frente a los objetivos declarados del producto, o nota «sin UI»
- riesgos principales, deuda técnica, issues conocidos
- línea base de tests y calidad (qué está cubierto, cómo ejecutar la suite)
- un Veredicto: ¿el código está lo bastante sano para construir encima, y qué debe arreglarse primero?
Empieza el pase de funcionalidad y riesgo desde el auto-escaneo de Superficies rankeadas. Esos archivos son el código de mayor apalancamiento — las superficies de las que depende la mayor parte del código, donde es más probable que se esconda un riesgo transversal.

Etiqueta cada afirmación material de Funcionalidad / Riesgos / Veredicto en el libro de Evidencia. No escribas política de producto como hecho salvo que la etiqueta sea Authoritative.

Etiqueta	Significado
Authoritative	Instrucción, decisión aceptada, contrato de producto, procedimiento documentado
Observed	El código/config/tests muestran el comportamiento actual
Derived	Consecuencia operativa directa de la implementación observada
Decision required	Elección normativa/de producto sin autoridad aún
Unknown	El repo no establece la respuesta

Un humano revisa la evaluación. Brownfield tiene gates del operador. En modo teach el agente informa; no marca casillas ni redacta el artefacto por ti.
Re-ejecuta /flow assess. PASS mecánico significa que no quedan [FILL] y cada casilla de gate está marcada. FAIL lista los huecos restantes; rellénalos desde evidencia y ejecuta de nuevo.
Después del PASS mecánico, aplica el desafío semántico antes de planificar:
- ¿Las afirmaciones materiales están etiquetadas Authoritative / Observed / Derived / Decision required / Unknown?
- ¿Alguna afirmación Observed o Derived se promueve en silencio a ley de producto que hay que construir sin autoridad del operador?
- ¿Los ítems Decision required / Unknown están listados para el operador — no inventados dentro de Scope/PRD?
- Un libro vacío, o solo filas [FILL] con las casillas marcadas, es hueco: reporta pasado-mecánicamente-pero-cualitativamente-débil.
Cuando ambas capas están de acuerdo, procede a planificar con /flow next.

Puedes reutilizar scout / researcher (o bmad-document-project) para reunir evidencia. El gate sigue juzgando. El operador sigue revisando.

Ejecutar desde un subdirectorio

Si ejecutas flow desde un subdirectorio como frontend/ que no tiene su propio flow/, adopta el proyecto flow ancestro más cercano e imprime una nota de una línea a stderr, en lugar de acuñar una segunda raíz fragmentada. Un subdirectorio con su propio flow/ o cards/ siempre se respeta, igual que un FLOW_PROJECT_ROOT explícito.

Ver también

Homes del mantenedor (no la página pública): skills/flow/SKILL.md, skills/flow/references/command-dispatch.md, skills/flow/_templates/00-inspect.md, skills/flow/references/gate-rules.md.