Abre la nota de una tarea

La puerta del momento ②. Una tarea de la ruta entra por aquí y sale como nota ejecutable: contenedor antes de trabajar, historia después de trabajar.

Fuente única

No repitas doctrina: léela donde vive y cítala por su título.

• Anatomía de la nota de tarea → Lineamientos, «Anatomía de las notas».
• Captura de build (redacción canónica de las 5 preguntas) → Lineamientos, «Gate de experiencia» — se copian literales, no se parafrasean.
• Ciclo por tarea (3 momentos) → Prompt Maestro, «Los dos pipelines (carriles)» / Lineamientos, «Ciclo de producción y día del cierre».
• Estado, carpetas y checkbox → Lineamientos, «Estado en el vault» y «Convenciones» (nombre atómico; la nota vive en notasEnTramite/proyectos/<slug>/<slug-tarea>.md, plana en la carpeta del proyecto — la jerarquía vive en los enlaces, jamás en el nombre).
• Doble CTA → DD-05: se lee del frontmatter de la ruta; nunca se inventa.
• Voz → Lineamientos, «Voz (por defecto del motor)», especializada por el Norte.
• Marcas del mapa (⛓ 📦 📸 💎) → Lineamientos, «La familia de marcas».

⚙️ Runtime

Claude Code sobre el vault. Lees y escribes archivos; no grabas, no subes nada, no programas publicaciones. Trabajas sobre el working set mínimo y nunca escaneas el vault completo.

Qué hace y qué NO hace

Sí: localiza la línea de tarea en su ruta y la lee entera (orientación, «hecho» verificable, marcas) · despierta el estado en cascada · crea el archivo con la anatomía de «Anatomía de las notas» y el frontmatter (publicable: no) · redacta los pasos ejecutables con el detalle que la ruta tiene prohibido llevar · monta la captura de build literal + las dos de cierre de sesión · invoca escribe-articulo-tutorial-tarea en sub-rutina · escribe sintesis: · deja los PENDIENTES con su comando exacto · monta el checklist (lista de verificación) del paquete GitHub si la tarea lleva 📦.

No: no ejecuta la tarea (eso es del viajero) · no inventa pasos que no se han probado · no redacta el artículo (sub-rutina) · no monta bloque de estudio — los conceptos se referencian, no se re-explican · no crea video propio (v2.12) · no toca la ruta salvo el despertar declarado · no marca el checkbox de la tarea (es acción manual del viajero) · no rellena los huecos [TU EXPERIENCIA: ...] · no escribe la experiencia antes de que se viva.

🎓 El skill explicado al viajero (las 17 preguntas)

🧭 En el viaje: el capataz de la jornada.

Una tarea de tu camino es una jornada de obra. Esto entrega lo que hace falta para trabajarla: la orden del día y la bitácora donde contar, al final, qué pasó de verdad.

La nota nace ANTES de ejecutar, y eso es el punto. No es un informe que se escribe después: es el contenedor con el que te sientas a trabajar. Dentro están los pasos ejecutables —que viven aquí y jamás en la ruta, porque la ruta dice qué hay que hacer y la nota dice cómo—, el «hecho» verificable que define cuándo la tarea está terminada de verdad, y los conceptos que tienes que haber estudiado antes.

Los pasos son una hipótesis, no un dogma. El terreno siempre corrige el plan, y cuando eso pase no estás fallando: estás descubriendo lo que este sistema vino a capturar. Ese desvío es material.

La historia de construir se cuenta UNA vez, y es aquí. Al terminar respondes en viñetas qué esperabas, qué salió distinto, qué te costó más de lo previsto y qué harías diferente. Nada de eso va en las notas de estudio: ahí vive el entendimiento, aquí vive el build. De esta bitácora sale después tu artículo tutorial, sin que tengas que escribir nada dos veces.

Y su campana despierta el camino. La primera jornada de un tramo lo pasa de trazado a en-curso, y ese cambio sube solo hasta el mapa. Nadie mantiene un estado a mano: el estado es consecuencia de haber empezado.

Esta sección no es doctrina de ejecución: es el mapa para que cualquier persona —incluido quien llega al motor con 37 skills delante y ninguno vivido— sepa qué es esto, cuándo le toca y cómo saber si lo está usando bien.

1 · ¿Cuándo corre? Al abrir el momento ② de cada tarea: los conceptos ⛓ vírgenes ya tienen su nota (momento ①) y el viajero está por ejecutar. Una corrida por tarea, ANTES de ejecutarla — la nota nace contenedor y se completa después con la vivencia.

2 · ¿Por qué existe? Porque los pasos viven en la nota, jamás en la ruta (la ruta lleva UNA línea de orientación por tarea), y porque la historia de construir se cuenta UNA sola vez, donde ocurre — esta nota es esa casa. Sin ella, el detalle ejecutable no tiene dónde vivir y el build se contaría disperso o nunca.

3 · ¿Cómo lo hace? Localiza la línea exacta de la tarea en su ruta (fase, posición, «hecho» verificable, marcas), despierta el estado en cascada si es la primera nota de la ruta, redacta los pasos ejecutables como HIPÓTESIS (se escriben antes de ejecutar), monta la captura de build literal (5 preguntas + cierre de sesión), invoca escribe-articulo-tutorial-tarea en sub-rutina y deja los pendientes con comando exacto.

4 · ¿Dónde actúa? Crea notasEnTramite/proyectos/<slug>/<slug-tarea>.md (nombre atómico) y hace UNA escritura externa declarada: el despertar trazada → en-curso subiendo por padre: hasta el MAPA. El checkbox de la tarea NO se marca (acción manual).

5 · ¿Qué pasa cuando corre? La tarea queda ejecutable: pasos con su señal de éxito, validación con el «mira, funciona», captura vacía esperando, artículo tutorial con huecos colocado (publicable: no), y checklist de GitHub si lleva 📦.

6 · ¿Para qué? Para que UNA sesión de trabajo pague en varios carriles: el proyecto avanza, el tutorial (piso gratis del embudo) queda a una narración de publicarse, el corto y el carrusel esperan su día, y el bloque alimentará al mini-proyecto de la fase.

7 · ¿Cómo encaja en el motor y su propósito? Es la puerta de la segunda clase de nota (DD-02) y quien ejecuta la apertura perezosa de la invariante 14: la primera nota de tarea despierta la ruta. Su captura de build es la mitad «build» de la invariante 10 afinada: cada pregunta se responde solo cuando su experiencia ya se vivió.

8 · ¿Cómo ayuda al viajero? Le baja el detalle que la ruta tiene prohibido llevar: comandos exactos, señales de que cada paso salió bien, y la decisión explícita marcada cuando algo depende de su entorno. El viajero solo ejecuta con la lista de vigilancia a la vista y responde viñetas al final.

9 · ¿Qué pasa si NO corre? La tarea se ejecuta «suelta»: sin pasos verificables, sin captura montada (el build se pierde esa misma noche), sin tutorial en camino — y la ruta ni se entera de que el viaje empezó (nadie despierta en-curso). El embudo pierde su piso gratis escrito.

10 · ¿Cómo se explica?

• A un niño de 5 años: «Antes de armar la pieza, escribimos la receta con sus pasos y dejamos listas las preguntas para contar después qué pasó de verdad.»
• A un colega: «Crea la nota de trabajo de una tarea: pasos ejecutables + validación + captura post-mortem — y de paso deja el borrador del tutorial público con huecos para la experiencia real.»
• A un experto: «Puerta de la clase nota-de-tarea: resuelve identidad contra la línea de la ruta, materializa el detalle ejecutable como hipótesis (plan ≠ crónica: la divergencia es la materia narrativa), monta la captura de build canónica, despierta el estado en cascada como única escritura externa, e invoca al redactor del tutorial en sub-rutina; narración diferida al mini-barrido (v2.13), derivados al día del cierre.»

11 · ¿A qué se parece? A la orden de trabajo de un taller serio: qué se va a hacer, cómo se verifica, y el espacio para el reporte de lo que de verdad pasó — que nunca es idéntico al plan, y esa diferencia es lo que el siguiente mecánico querrá leer.

12 · ¿Cómo sabe el viajero que lo está haciendo bien? Si la nota existía ANTES de ejecutar · los pasos no se reescribieron para fingir que se acertó a la primera (lo que salió distinto vive en la captura) · el «hecho» verificable se cumplió · la captura se respondió al terminar, con lo específico · y la ruta despertó a en-curso sola.

13 · ¿Cómo puede mejorar el resultado? Dando contexto de su entorno real al crear la nota (versiones, restricciones — menos decisiones marcadas) · respondiendo la captura el mismo día (el error literal se olvida rápido) · y con el 📦 en serio: commits que explican el porqué son portafolio, no trámite.

14 · ¿Qué puede confundir? Buscar aquí el estudio de los conceptos (se ENLAZAN en prerrequisitos; su nota es la fuente única) · esperar video propio (murió en v2.12: la enseñanza viaja en la clase de fase y el capitulo-curso) · narrar el build en las notas de estudio (ahí va solo el ECO; la historia vive aquí) · marcar el checkbox de la ruta a mano esperando que algo pase · confundirla con el mini-proyecto de la fase (ese entra por crea-nota-fase-miniproyecto, el SLOT).

15 · ¿De dónde viene el viajero? Del momento ① de la misma tarea: dijo «notas de la tarea X», se crearon las notas de sus conceptos vírgenes, estudió y respondió los post-estudios. Con la lista de vigilancia en mano, toca ejecutar — y esta puerta le monta el contenedor.

16 · ¿Qué sigue después de este skill? El viajero EJECUTA la tarea sobre el sujeto real → responde la captura de build aquí + el eco en cada nota de concepto (momento ③) → sigue con la siguiente tarea. Al agotarse las tareas de la fase: el mini-barrido (narra-experiencia narra este build y voltea el gate) → el SLOT (crea-nota-fase-miniproyecto). El día del cierre: corto, hooks (ganchos) y carrusel.

17 · El viajero usándolo (ejemplo ilustrativo, no doctrina). La fase «mandíbula» de rig-facial llega a T1.2 — rig-mandibula. El viajero ya estudió pesos-de-malla (momento ①) y dice «nota de la tarea rig-mandibula». El skill localiza la línea (su «hecho»: la mandíbula rota sin deformar la mejilla), es la primera nota de la ruta → despierta rig-facial a en-curso y sube por padre: hasta el MAPA. Redacta 6 pasos sobre su personaje real («añade el hueso jaw_master → se ve que salió bien porque el gizmo aparece en el pivote del mentón»), deja una decisión marcada (<tu versión de Blender>), monta la captura vacía y coloca el tutorial con huecos. Esa tarde el viajero ejecuta: el paso 4 no sale como el plan (la comisura se dobla fea) — no reescribe el paso: lo cuenta en la captura. Dos fases después, ese build narrado es la sección «errores comunes» más buscada de su tutorial.

Posición en la cadena (DD-03)

línea de tarea (ruta)
   → crea-nota-tarea: contenedor + pasos + captura de build vacía        (momento ②)
   → escribe-articulo-tutorial-tarea: artículo CON huecos           (publicable: no)
   ── el viajero EJECUTA la tarea ──
   → captura de build respondida (en ESTA nota, una sola vez)
   → narra-experiencia (craft de build): compila el bloque + incrusta
   → artículo tutorial completo                                (publicable: si — gate)
   → { cuerpo de corto · 3 hooks · carrusel }

Aguas abajo: cierra-fase funde los artículos tutorial de la fase en el artículo de capitulo-curso sobre el sujeto continuo real (carril privado 🔒). Este skill no lo sabe ni le importa: solo garantiza su eslabón.

Guardia anti-error (invariante 15)

Antes de escribir nada, verifica la clase del ítem y corrige el pedido si hace falta:

• ¿Es un concepto de una ruta de estudio? → crea-nota-estudio-concepto.
• ¿Es el mini-proyecto de una fase (el SLOT)? → crea-nota-fase-miniproyecto.
• ¿Es una sub-ruta o un ítem 🐉? → crea-ruta-de-tareas sobre ese ítem.
• ¿Conceptos ⛓ vírgenes SIN nota? → crea-nota-estudio-concepto primero (momento ①) y detente — o el viajero decide explícitamente ejecutar sin estudiar (pregunta, no impongas).
• ¿No existe la ruta que contiene la tarea? → no produzcas nada: nombra crea-ruta-de-tareas y detente («sin prerrequisito no hay pieza», v2.13). Una nota de tarea sin ruta nace sin contrato, sin CTAs y sin sitio en ninguna fase.

Corrige y propone; el viajero confirma.

Entrada (contrato)

Mínimo: el slug o el título de la tarea (y, si hay ambigüedad, su ruta).

Del working set (DD-01): la ruta de tareas y su frontmatter (mapa: · padre: · objetivo: · estado: · los CTAs con url_newsletter) · la línea de la tarea con su orientación, su «hecho» verificable y sus marcas · los [[conceptos]] que su ⛓ enlaza (para prerrequisitos: los enlazas, no los resumes) · el Norte vía norte: de la ruta, solo para voz y entidad-autor.

Opcional del viajero: contexto del entorno real (versiones, rutas, nombres del proyecto) · restricciones («esto lo hago en Blender 4.2, no en 4.5») · pasos que ya conoce.

No lees: otras rutas, el vault completo, ni las carpetas MISCELÁNEAS que CLAUDE.md declare fuera de alcance.

Proceso

1. Working set (DD-01)

Localiza la ruta que contiene la tarea en notasEnTramite/proyectos/<slug>/. Lee su frontmatter y su Trazado; resuelve el Norte vía norte:. Nunca escanees el vault.

2. Ubica la línea de tarea

Encuentra la tarea exacta en el Trazado: su fase, su posición (T<fase>.<posición>), su línea de orientación, su «hecho» verificable y sus marcas (⛓ 📦 📸 💎). Si el slug no existe en ninguna ruta del proyecto, detente y pregunta: no inventes la tarea ni la añadas al trazado.

3. Despierta el estado en cascada (v2.8 — excepción de escritura declarada)

Si la ruta está en estado: trazada, pásala a en-curso y sube por padre: haciendo lo mismo en cada ancestro hasta el MAPA-<Proyecto>. Es la única escritura que este skill hace fuera de su propia nota, y solo toca ese campo: nada más de la ruta se modifica, y el checkbox de la tarea NO se marca (es acción manual del viajero, «Estado en el vault»). Declara en tu línea de estado qué rutas despertaste.

4. Redacta los pasos ejecutables ← lo que la ruta tiene prohibido llevar

🧭 Dilo al entrar: «Te escribo los pasos de esta jornada, que es lo único que la ruta no lleva: ella dice qué hay que lograr, la nota dice cómo. Léelos como una hipótesis: si al ejecutar resulta que el paso 3 no era así, no los arregles en silencio — apúntalo, porque esa corrección es exactamente el material con el que después se escribe el tutorial que a otra persona le va a ahorrar la misma hora.»

Aquí vive el detalle. Pasos numerados, en el orden real de ejecución, cada uno con lo que hay que hacer y cómo se ve que salió bien. Concreto: comandos exactos, nombres de menú, parámetros. Si algo depende del entorno del viajero y no lo sabes, déjalo como decisión explícita (<ruta de tu proyecto>), jamás lo inventes.

Prerrequisitos: enlaza los [[conceptos]] del ⛓ y nada más. Sin bloque de estudio, sin resumirlos: el concepto se explica en su nota, y duplicarlo aquí crearía dos versiones de la verdad (DD-01).

Los pasos son la hipótesis, no la crónica. Se escriben antes de ejecutar y por eso pueden estar equivocados: lo que salió distinto se cuenta en la captura de build, no reescribiendo los pasos para que parezca que se acertó a la primera. Esa diferencia entre plan y realidad es el material de la narrativa.

5. Validación — el «hecho» verificable

🧭 Dilo al entrar: «Antes de que empieces, dejamos claro cuándo esta tarea está terminada, y tiene que ser algo que se pueda comprobar: una pantalla que muestra esto, un comando que responde aquello. No «cuando quede bien». La razón es vieja y conocida: sin un hecho verificable, una tarea se queda abierta para siempre en un 90 %.»

Una sección corta con la comprobación que cierra la tarea: qué se ejecuta o se mira para saber que funciona, y cuál es el resultado esperado. Es el momento «mira, funciona»; si la tarea lleva 📸, aquí va el recordatorio de capturar la evidencia (ANTES/DESPUÉS si aplica).

6. Crea el archivo (plantilla exacta)

notasEnTramite/proyectos/<slug>/<slug-tarea>.md según references/plantilla-nota-tarea.md: frontmatter estricto (publicable: no, publicado: no, sintesis vacía por ahora, categoria: COPIADA de la ruta — v2.15: es la casa del blog y sin ella la nota no tiene URL; teje-el-hilo y orquesta-publicacion bloquean. Si la ruta no la trae, no la inventes: déjala vacía y avisa en una línea de que la ruta necesita su categoría) y las secciones en el orden canónico. Nombre atómico: el slug de la tarea es el nombre del archivo.

7. Monta la captura de BUILD («Gate de experiencia (la aduana)», literal)

🧭 Dilo al entrar: «Al terminar la jornada vas a encontrar aquí cinco preguntas sobre el build: qué esperabas, qué salió distinto, qué te costó más, qué resolviste y cómo, qué harías diferente. En viñetas y sin redactar, recién terminado — no mañana. Lo que salió mal es la parte más valiosa y la primera que se olvida; de ahí sale el tutorial, y un tutorial sin los tropiezos reales es un manual más que no le sirve a nadie.»

Copia las 5 preguntas de build en su redacción canónica, sin parafrasear, y las dos de cierre de sesión al final de la sección. Van vacías, con la instrucción de responderlas tras ejecutar, en viñetas fechadas y con lo específico (el error literal, el comando exacto, la cifra real) — nunca prosa bonita.

Deja claro en la nota que la historia del build se cuenta UNA sola vez, aquí: en las notas de estudio de sus conceptos solo va el eco («qué me enseñó usarlo»), y el bloque de experiencia queda vacío hasta que narra-experiencia lo compile.

8. Invoca escribe-articulo-tutorial-tarea (sub-rutina, sin preguntas)

Pásale: tarea + slug · su objetivo y su «hecho» verificable · los pasos ya redactados · los [[conceptos]] prerrequisito · las marcas 📦/📸 de la tarea · el frontmatter de la ruta (fuente única de los CTAs) · voz y entidad-autor del Norte. Recibe el artículo con sus huecos y colócalo en ## ✍️ ARTÍCULO. No le hagas preguntas al viajero por cuenta de la sub-rutina y no toques los huecos.

9. Escribe sintesis: y verifica el gate

sintesis: = una línea que resuma qué construye esta tarea (DD-01: los cierres leen esto, no el cuerpo). Confirma que publicable: no sigue puesto y que todo hueco está intacto.

10. Monta ## 📋 PENDIENTES

Checkboxes en orden, cada uno con su comando exacto (DD-02 — se disparan sueltos, con contexto limpio, cada uno en su momento):

1. Ejecutar la tarea y responder la captura de build.
2. Usa narra-experiencia sobre <ruta de la nota> — craft de build; voltea el gate. Se dispara en el mini-barrido de build, al agotarse las tareas de la fase (v2.13: la historia de un build ya no crece — no espera al día del cierre).
3. Usa escribe-guion-corto-atraccion sobre <ruta de la nota> — cuerpo de 45–60 s.
4. Usa hook-tiktok / hook-instagram / hook-shorts sobre <ruta de la nota> — tras el cuerpo.
5. Usa carrusel sobre <ruta de la nota> (alta v2.12).
6. Si la tarea lleva 📦: paquete GitHub — commits limpios + README que explica el porqué (no el qué) + gist si aplica; pegar la URL del repositorio en el frontmatter.

Sin video propio: no dejes pendiente de guion de video. La enseñanza de esta tarea viaja fundida en la clase de fase (gratis) y en el capitulo-curso (pago).

Doble destino del corto (v2.12): cuando exista, el corto de esta tarea enlaza al video de su fase (URL pegada el día del cierre) y al artículo tutorial (URL determinista: /blog/<categoria>/<slug>).

11. Cierra con la línea de estado

nota: <ruta> · tarea: T<fase>.<posición> de [[<item>]] · despertadas: <rutas que pasaron a en-curso> · pasos: N · marcas: <⛓ 📦 📸 💎> · artículo: colocado (N huecos) · experiencia: pendiente → publicable: no · pendientes: <N>

Reglas

• Jamás fabriques experiencia ni toques un hueco [TU EXPERIENCIA: ...] (invariante 10). La captura se responde después de ejecutar, y hasta entonces va vacía.
• Jamás inventes pasos. Si no sabes cómo se hace algo en el entorno real del viajero, investígalo con fuente fechada o déjalo como decisión explícita marcada. Un paso inventado es peor que un hueco: el hueco se ve, el paso falso se descubre a mitad de la ejecución.
• Cero teoría. Los conceptos se enlazan, no se re-explican; su nota es la fuente única.
• Los pasos viven aquí, jamás en la ruta. La ruta lleva UNA línea de orientación por tarea.
• No toques la ruta salvo el despertar del paso 3, y ni siquiera entonces el checkbox.
• El doble CTA se lee del frontmatter de la ruta; no se inventa (DD-05). Si url_producto y url_lead_magnet están vacíos, la conversión resuelve a url_newsletter, que existe siempre.
• Un solo artículo, un solo cuerpo; el artículo lo redacta la sub-rutina, no tú.
• Sé conciso en el chat; el trabajo vive en la nota.

Referencias

• references/plantilla-nota-tarea.md — el esqueleto exacto del archivo.