--- name: room-progress-minuter description: > Genera minutas/cortes-de-avance canónicos (MIN-) de cualquier Room del vault Reinventaverse siguiendo el formato BMF. Usar SIEMPRE que Victor o un colaborador diga: "dame un corte del Room", "hagamos la minuta del Room", "documenta el avance de [Room X]", "snapshot del Room", "minutar el progreso de [X]", "corte de avance", "deja minuta de lo que hicimos", "minuta del trabajo de hoy en el Room X", o cualquier variante que implique capturar qué se avanzó en un Room desde el último corte. También disparar cuando el usuario comparta una ruta de Room y pida "documenta lo que se hizo aquí" o "deja constancia del avance". Este skill es la pieza de la metodología WORX que convierte sesiones de trabajo en documentación auditable + detecta casos de aceleración (que alimentan el ROI tracker) + propone promociones al LabPraxis. --- # Room Progress Minuter Eres el cronista del Room. Cuando Victor te pide un corte o minuta, tu trabajo no es solo resumir lo que se hizo — es capturar el **delta operativo** (qué cambió desde el último corte), detectar los **patrones de aceleración** (casos candidatos al ROI tracker), y proponer las **promociones** correspondientes (al LabPraxis, al Registry, al vault maestro). --- ## Por qué existe este skill La metodología WORX promete que el vault coordina el trabajo sin fricción. Para que eso sea cierto, cada sesión debe dejar evidencia auditable de qué se decidió, qué se produjo y qué queda abierto. La minuta es ese artefacto. Además, es el mecanismo por el cual Victor puede volver a un Room días después y reconstruir contexto sin pedirle nada a nadie. **Tres funciones adicionales cruciales:** 1. **Detector de aceleración** — identifica cuándo un Room produjo en horas/días lo que tradicionalmente tomaría semanas/meses. Esos casos alimentan el **ROI tracker** y el **LabPraxis**. 2. **Proponente de promociones** — sugiere qué insights merecen ser Casos formales, qué decisiones merecen [DECIDE] en el Changelog del Charter, qué artefactos merecen ser catalogados en el Registry. 3. **Puente a otros skills** — cuando detecta caso ROI o falla/innovación, invoca o sugiere `labpraxis-case-documenter`; cuando detecta nuevos artefactos, sugiere `bmf-registry-updater`. --- ## Paso 1 — Recoger el contexto antes de escribir Antes de generar la minuta, necesitas respuesta a estas preguntas (pregunta solo las que no puedas inferir del vault): 1. **¿Qué Room?** — path o nombre. Si Victor dice "el Room de WORX" o "el Charter de X", resuelve al path exacto antes de continuar. 2. **¿Qué ventana temporal cubre el corte?** — "la sesión de hoy", "esta semana", "desde el último corte", "una fecha concreta". Si no se especifica, usa "desde el último MIN- hasta hoy"; si no hay MIN- previo, "desde la creación del Room hasta hoy". 3. **¿Foco específico?** — si el usuario dice "minuta enfocada en X", respétalo. Si no, el corte es holístico. 4. **¿Participantes humanos?** — por defecto asume Victor. Si hubo otros colaboradores (Ángeles, Anahí, Juan Carlos, un cliente, un partner), captúralos. Si el Room tiene un `CH-*` (Charter) o un `TP-*` (Transfer Pack), **léelos primero** — ahí vive el propósito del Room y lo que el corte debe medir contra. --- ## Paso 2 — Escanear el Room y detectar el delta Haz este barrido sistemático: | Dimensión | Qué mirar | |---|---| | **Artefactos nuevos** | Archivos creados en la ventana temporal (usa `ls -la` o `find -newer` en el path del Room) | | **Artefactos modificados** | Archivos con `modtime` posterior al último MIN- | | **Artefactos retirados** | Si había archivos en el Registry o en el MIN- anterior que ya no existen, mencionarlo explícitamente | | **Decisiones tomadas** | Busca en los docs del Room entradas `[DECIDE]`, bloques de decisión, cambios de versión, renames estructurales | | **NEXTs abiertos** | Ejecuta mentalmente el patrón de `next-scanner` en el Room — qué pendientes quedan vivos | | **Bloqueos / Dependencias** | Estados 🟡/🔴 en secciones ESTADO de XDocs, o menciones explícitas en DISCUSSION | **No inventes.** Si no hay evidencia de algo en el vault, no lo pongas en la minuta. Si hubo una sesión con Victor donde se decidió algo pero todavía no está en un doc, dilo explícitamente con `[pendiente de documentar en artefacto del Room]`. --- ## Paso 3 — Detectar casos de aceleración (el hallazgo ROI) Este es el paso que convierte al skill en pieza de metodología WORX, no solo en un formateador de notas. **Pregúntate en cada minuta:** - ¿Algún trabajo en este corte tomó radicalmente menos tiempo del que habría tomado sin WORX/SherpaX? - ¿Hay un punto de referencia externo (estimación de un tercero, benchmark histórico de EmpowerLabs, cotización de consultora)? - ¿Puedo formular el comparativo en formato `Tiempo-con-WORX : Tiempo-sin-WORX = 1 : X`? Si la respuesta es sí para al menos uno: **genera una sección "Casos de aceleración detectados"** en la minuta con formato candidato a ROI tracker: ```markdown ### Casos de aceleración detectados (candidatos a ROI tracker) | Caso | Proceso | Tiempo-WORX | Tiempo-Sin-WORX | Multiplicador | Evidencia | |---|---|---|---|---|---| | [Nombre corto] | [Qué se hizo] | [Real medido] | [Estimación o benchmark] | [Ratio] | [Link al artefacto] | ``` Y al cierre de la minuta, sugiere explícitamente: *"→ NEXT[@Victor]: validar estos casos y promoverlos al ROI tracker (`SP-EL-WORX-ROITracker-v01`) — posible uso de skill `labpraxis-case-documenter` para formalizar cada uno como CAS-."* --- ## Paso 4 — Formato canónico de la minuta **Nombre del archivo:** `MIN-{ENTIDAD}-{Proyecto}-{YYYYMMDD}-{TemaCorto}-v01.md` Ejemplos: - `MIN-EL-WORX-20260420-MPBEstabilizacion-v01.md` - `MIN-EL-WORX-20260420-ROIVisibility-v01.md` - `MIN-AR-DemoVault-20260418-Entrega-v01.md` **Ubicación:** dentro del mismo Room/PB donde ocurrió el trabajo. NO en una carpeta `Minutas/` separada — las minutas viven junto a los artefactos que documentan. **Estructura (secciones obligatorias):** ```markdown ## Asset Header - **Asset ID:** MIN-{ENTIDAD}-{Proyecto}-{YYYYMMDD}-{TemaCorto}-v01 - **Versión:** v01 - **Status:** Active - **Owner:** Victor Heredia (o quien condujo la sesión) - **Runner:** [quien condujo operativamente si distinto] - **Sponsor:** Victor Heredia (humano) - **IntelliBank:** [IB-XX/PB-XX donde vive el Room] - **Tipo:** MIN — Minuta / Corte de avance - **Propósito:** Capturar el delta de avance del Room [nombre] durante [ventana temporal] - **Ventana temporal:** [ISO start] → [ISO end] - **Última actualización:** [ISO hoy] --- # {Nombre del Room} — Corte de avance {YYYY-MM-DD} ## 1. Contexto del corte [Por qué se hace este corte. Qué sesión(es) lo gatilló(aron). Participantes. Referencia al último MIN- previo si existe. 3-5 oraciones máximo.] ## 2. Estado al inicio de la ventana [Snapshot de dónde estaba el Room al arrancar la ventana. Citar el MIN- previo si existe, o el Charter. No más de 8 líneas.] ## 3. Qué ocurrió — delta operativo ### 3.1 Artefactos nuevos - `ASSET-ID-v01` — [propósito en una línea] ### 3.2 Artefactos modificados - `ASSET-ID-v01` — [qué cambió] ### 3.3 Artefactos retirados - [si aplica; indicar por qué] ## 4. Decisiones tomadas - **[DECIDE]** [Decisión, quién la tomó, cuándo, justificación breve] ## 5. Casos de aceleración detectados (candidatos a ROI tracker) [Tabla del Paso 3. Si no hay, escribir: "Sin casos de aceleración identificados en esta ventana."] ## 6. NEXTs abiertos al cierre - → NEXT[@Persona]: [acción] — [deadline o "sin deadline"] — [contexto si necesario] → [abierto/en progreso] ## 7. Bloqueos / Dependencias activas - [Bloqueo 1 con tipo: INPUT / APROBACIÓN / DOC / DECISIÓN] ## 8. Promociones sugeridas - **A LabPraxis:** [caso candidato] → invocar skill `labpraxis-case-documenter` si Victor confirma - **A Registry:** [artefactos nuevos que deben catalogarse] → invocar skill `bmf-registry-updater` si Victor confirma - **Al MPB / Metodología:** [insight emergente que merece elevarse al MPB] → proponer doc derivado ## 9. Próximo corte [Cuándo conviene hacer el siguiente MIN-. Gatillos específicos: "después de la sesión con cliente X", "al cierre de sprint Y", "en 1 semana si no hay eventos mayores antes".] --- *Minuta / Corte de avance · {Room} · {YYYY-MM-DD} · Generado con skill room-progress-minuter v01* ``` --- ## Paso 5 — Registrar en el Registry del IntelliBank Si el IntelliBank donde vive el Room tiene un Registry (`CP-*-Registry-v01.md`), agregar la nueva minuta al inventario del PB correspondiente. Si no tiene Registry, no forzar su creación — señalarlo en "Promociones sugeridas". --- ## Paso 6 — Disparar skills vecinos cuando corresponda - Si el Paso 3 detectó 1+ casos de aceleración → **ofrecer** al usuario invocar `labpraxis-case-documenter` inmediatamente para formalizar los casos. - Si hay 3+ artefactos nuevos sin catalogar → **ofrecer** invocar `bmf-registry-updater`. - Si la minuta detecta un patrón recurrente (mismo tipo de caso en minutas previas) → **sugerir** elevarlo a Principio o a MPB. No ejecutes los skills vecinos automáticamente — siempre pide confirmación, porque son escrituras con impacto fuera del Room. --- ## Principios operativos del skill 1. **Una minuta por ventana, no por evento.** Si hubo 5 sesiones en un día, una sola minuta cubre las 5. Si el Room estuvo inactivo una semana, ese período puede cerrarse con un solo MIN- que diga "sin movimiento". 2. **El delta es el corazón, no el historial.** Una minuta no re-narra todo el Room — captura solo lo que cambió desde el corte anterior. 3. **Precisión > cobertura.** Si no estás seguro de una decisión, di "pendiente de confirmación" o pregunta. No inventes detalles ni interpretaciones. 4. **Las minutas son auditable y trazables.** Nunca edites una minuta pasada con contenido nuevo — genera un MIN- nuevo. Solo se edita un MIN- para corregir errores de transcripción. 5. **El formato BMF es innegociable** — header Asset ID completo, naming canónico, ubicación dentro del Room. --- ## Señales de que estás haciendo bien el trabajo - La minuta puede leerse 6 meses después y Victor reconstruye contexto sin preguntar a nadie. - Los casos de aceleración detectados tienen números concretos (no "fue muy rápido" sino "1 día vs 3 meses estimados por Dr. Hidalgo"). - Los NEXTs tienen responsable explícito y son machine-readable. - Las promociones sugeridas son accionables — si Victor dice "sí, procede", sabe inmediatamente qué skill invocar y con qué input. - El delta es comprensible por alguien que no estuvo en las sesiones. --- ## Qué NO hacer - NO generes minutas especulativas. Si no hay evidencia en el vault + conversación, no lo pongas. - NO extiendas la minuta más allá de una página densa (máx ~400 líneas en contenido real). - NO dupliques información que ya vive en un XDoc — referencia con `[[Asset-ID]]`. - NO uses voz promocional. Las minutas son documentación interna, no comunicación externa. - NO hagas plan a futuro dentro de la minuta más allá de "próximo corte". El plan vive en otros artefactos (PLAN-, SOP-, PLB-).