--- name: bmf-doc-canonizer description: > Canoniza un documento individual del vault Reinventaverse: define el TIPO/ENTIDAD/slug correctos según BMF, renombra el archivo a la convención canónica, agrega el frontmatter YAML completo, alinea el H1 con el asset_id, y registra el activo en el Registry maestro. Usar SIEMPRE que Victor o un colaborador diga: "ajusta el título conforme a las reglas de taxonomía", "renómbralo a BMF", "agrégale el header canónico", "este doc no tiene frontmatter", "canoniza este archivo", "ponle el header como debe ser", "alinéalo al modelo", "este draft necesita header oficial", "convierte este draft en activo canónico", o cualquier variante donde un documento individual del vault necesite migrar de formato ad-hoc a formato BMF canónico (rename + frontmatter + H1). Distinta de bmf-file-renamer (que audita carpetas completas) — esta skill opera sobre UN documento a la vez. Distinta de vault-orphan-rescue (que mueve archivos fuera de lugar) — esta skill canoniza el contenido y nombre, asumiendo que la ubicación ya es correcta. --- # BMF Doc Canonizer Canoniza un documento individual del vault: lo lleva de formato ad-hoc (sin frontmatter, nombre no canónico, H1 inconsistente) al formato BMF canónico que el ecosistema espera. **Cuándo se usa:** cuando ya existe un draft con contenido válido pero el envoltorio (nombre del archivo + frontmatter + título H1) no cumple BMF. **Cuándo NO se usa:** - Si necesitas auditar una carpeta completa → `bmf-file-renamer` - Si el archivo está en la ubicación incorrecta del vault → `vault-orphan-rescue` - Si el archivo no existe todavía (creación nueva desde cero) → producir directo en formato canónico, esta skill no aplica --- ## Workflow paso a paso ### Paso 0 · Confirmar precondiciones Antes de canonizar, verificar que: 1. El archivo **existe** en el vault (Read confirma). 2. El archivo está en la **ubicación correcta** (IntelliBank + sub-bank apropiado). Si no, primero invocar `vault-orphan-rescue`. 3. El contenido del documento es **estable** (no work-in-progress que pueda cambiar mucho). Canonizar drafts inestables genera ruido. 4. Hay **claridad sobre el propósito** del documento — esto define el TIPO canónico. Si alguna precondición falla, detenerse y reportar al usuario antes de modificar nada. ### Paso 1 · Leer el documento completo `Read` del archivo objetivo. Identificar: - ¿Hay frontmatter actual? Si sí, qué contiene. - ¿Hay H1? ¿Qué dice? - ¿Hay un "Asset Header" en formato bullet (legacy)? Si sí, qué dice. - ¿Cuál es el propósito real del documento (1 línea)? - ¿Cuál es la audiencia primaria? - ¿De qué otros documentos deriva o referencia? ### Paso 2 · Determinar TIPO canónico Con base en el contenido, escoger el TIPO de la tabla canónica BMF: | TIPO | Cuándo usarlo | |------|---------------| | CP- | Control Plane · Registries, mapas de activos, índices maestros | | SOP- | Standard Operating Procedure · Procedimientos paso a paso | | TP- | Transfer Pack · Room canonizado/frozen para transferir contexto | | WOI- | Work In Progress · Borrador activo de un TP- futuro | | XP- | Export Pack · Room autocontenido para portar a instancia nueva | | SP- | Session Prompt · Activador de room en cada sesión | | PLB- | Playbook · Guía de referencia por tema | | PBO- | Playbook Operativo · Guía con criterios de decisión explícitos | | MiPB- | Mini PlayBook · Procedimiento operativo focal (L1 Stack) | | MFR- | MetaFactory Recipe · Receta de factoría (L2 Stack) | | MPB- | MetaPlayBook · Receta canónica del CEO/founder (L3 Stack) | | MePB- | Meta-MetaPlayBook · Frame organizacional (L4 Stack) | | MPI- | MasterPlaybook Inteligente · Producto editorial activable (L5 Stack) | | BC- | Brain Code · Perfil de persona/metodología/tradición (L6 Stack) | | BCV- | Brain Code Vertical · Variante BC- vertical | | MAP- | Mapa visual · SVG/PNG con arquitectura o flujo | | MIN- | Minuta · Registro de reunión o sesión | | OUT- | Output · Resultado de sesión de trabajo | | CAS- | Case · Caso documentado del LabPraxis | | CONS- | Vault CONSultation Pack · Output del Gate G0 SOP-BrainOSFirst | | PROT- | Protocolo · Reglas operativas del cohort | | DC- | Documento Corporativo · Reportes, comparativos, análisis | | MKT- | Marketing · Copy, estrategia, posicionamiento | | ARQ- | Arquitectura · Diagrama o documento arquitectónico | | IPC- | IP Conocimiento · Documento de propiedad intelectual | | PLAN- | Plan táctico · Implementación, roadmap, oleadas | | PA- | Paper · Documento de conocimiento profundo | Si ninguno encaja claramente, **detenerse y consultar al Owner** antes de inventar un TIPO nuevo (regla del bmf-file-renamer · no crear TIPOs sin aprobación). ### Paso 3 · Determinar ENTIDAD canónica Con base en la ubicación del archivo en el vault: | ENTIDAD | IntelliBank | |---------|-------------| | XX | IB-XX-Maestro · canónico transversal | | EL | IB-EL-EmpowerLabs | | MPX | IB-MPX-MasterPlaybooks | | BVH | IB-BVH-Publications · ByVictor | | TriRH | IB-TriRH-TribusRRHH | | REB | IB-REB-Rebelocity | | SX | IB-SX-SherpaX | | AR | IB-AR-DemoVault / IB-AR-AlainRios | | PG | IB-PG-PapayaGroup | | EH | IB-EH-EmilioHeredia | | HDC | IB-HDC-HumanDesignCode (si existe como banco propio) | Excepción: si el archivo vive en un sub-bank (PB-* o EQ-*) dentro de un IntelliBank, la ENTIDAD sigue siendo la del IntelliBank raíz · el sub-bank aparece como tercer segmento opcional. ### Paso 4 · Determinar segmento de contexto + slug Patrón canónico: ``` TIPO-ENTIDAD[-CONTEXTO]-SlugDescriptivo-vNN.ext ``` - **CONTEXTO** (opcional): proyecto / banco / dominio. Ejemplos: `WORX`, `HIORG`, `EQ`, `R100X`, `HDC`, `CASO0`, `SX`, `MONETIZACION`. - **SlugDescriptivo**: 1-4 palabras en PascalCase concatenadas (sin espacios). Describe el activo de forma específica. - **vNN**: `v01` para draft inicial. Ejemplos canónicos: - `MiPB-EL-EQ-ArranqueSherpaX-Colaborador-v01.md` - `SOP-EL-HIORG-SanitizacionDemoVault-v01.md` - `MePB-EL-HIORG-SecurityLayers-v01.md` - `CAS-EL-WORX-LabPraxis-BancoCasos-v01.md` - `TP-EL-WORX-Posta-HandoverRoom-v01.md` ### Paso 5 · Construir el frontmatter canónico Plantilla obligatoria: ```yaml --- asset_id: {nombre del archivo sin extensión} version: v01 tipo: {TIPO} — {nombre completo} ({L? Cognitive Asset Stack si aplica}) status: {Draft|Active|Frozen|Deprecated} owner: {Persona responsable del activo} sherpa_owner: {SherpaX responsable · ej. Jay (SherpaX maestro) · AnaX · AlexiX · etc.} intellibank: IB-{ENTIDAD}-{Nombre} subbank: {Sub-bank path · ej. PB-EL-Project-Bank/PB-WORX-Worx · o EQ-EL-Equipo} fecha_creacion: YYYY-MM-DD fecha_ultima_actualizacion: YYYY-MM-DD proposito: | {1-3 líneas describiendo el propósito del documento · qué resuelve · para quién} audiencia_primaria: {Quién lo lee/usa principalmente} audiencia_secundaria: {Audiencia adicional · si aplica} deriva_de: - {Asset ID + breve descripción de qué aporta} - {...} referenciado_por: - {Asset ID + breve descripción · si aplica} - {...} tags: [{TIPO}, {tag1}, {tag2}, ...] {campos extra opcionales según el TIPO · ej. duracion_estimada · formato · changelog inline · etc.} --- ``` Reglas: - `asset_id` debe coincidir EXACTAMENTE con el filename sin extensión. Esto es **invariante** BMF. - `fecha_creacion` se preserva si ya existe; si no, usar la fecha actual. - `fecha_ultima_actualizacion` se actualiza a la fecha de la canonización. - `status` por defecto es `Draft` salvo que el documento esté evidentemente operativo (entonces `Active`). - `owner` se infiere del contexto · si no es obvio, preguntar al usuario. - `sherpa_owner` por defecto es `Jay (SherpaX maestro)` para activos de Victor; ajustar según colaborador. ### Paso 6 · Alinear el H1 Después del frontmatter, el documento debe tener un H1 que refleje el propósito · seguido opcionalmente de un H2 con el sub-título. Formato: ```markdown # {TIPO} · {Título descriptivo} ## {Sub-título opcional · audiencia o contexto} ``` Ejemplo: ```markdown # MiPB · Arranque SherpaX para Colaborador EL ## Guía operativa replicable · stack documental + SOPs + skills + flujo ``` Si existía un "Asset Header" en formato bullet legacy (`- **Asset ID:** ...`), **eliminarlo** · el frontmatter YAML lo reemplaza. ### Paso 7 · Agregar changelog (si aplica) Si el documento es la canonización de un draft previo, agregar al final: ```markdown ## Changelog - **v01 · YYYY-MM-DD** · Versión inicial canónica. Migrado desde "{nombre anterior}" (formato ad-hoc). {Cualquier cambio estructural · ej. sección X removida, contenido Y generalizado}. ``` ### Paso 8 · Ejecutar el rename 1. **Write** el archivo nuevo en la ubicación canónica con el nombre canónico y contenido limpio (frontmatter + H1 + cuerpo). 2. **Verificar** que el archivo nuevo existe con `ls`. 3. **Eliminar** el archivo anterior con `rm`. Si rm falla con "Operation not permitted", invocar `mcp__cowork__allow_cowork_file_delete` y reintentar. 4. **Confirmar** que solo queda el archivo canónico. ### Paso 9 · Actualizar Registry Después del rename exitoso: 1. **Leer** `IB-XX-Maestro/CP-XX-IntelliBanks-Registry-v01.md`. 2. **Buscar** si el activo anterior estaba registrado (por nombre viejo o asset_id viejo). 3. **Si existía**: actualizar la fila con el nuevo asset_id. 4. **Si no existía**: agregar una nueva fila en la sección del IntelliBank correspondiente. 5. **Incrementar** el contador total de activos del Registry. Alternativamente, invocar la skill `bmf-registry-updater` para que ejecute este paso de forma estructurada. ### Paso 10 · Reportar al usuario Output canónico al cierre: ``` ## Canonización completada · {fecha} ### Antes - Archivo: {nombre anterior}.md - Ubicación: {path} - Frontmatter: {ninguno | parcial | completo} - Asset Header: {bullet legacy | ninguno} ### Después - Archivo: {nombre canónico}.md - Ubicación: {path} - Frontmatter: YAML completo (asset_id, version, tipo, status, owner, sherpa_owner, intellibank, subbank, propósito, audiencia, deriva_de, referenciado_por, tags) - H1: {nuevo H1} ### Cambios estructurales - {lista de secciones agregadas/removidas/movidas si aplica} ### Registry - {nueva fila agregada | fila existente actualizada} en CP-XX-IntelliBanks-Registry-v01 ### NEXTs sugeridos - {Si aplica · ej. canonizar referencias circulares, agregar a XP/SP de room raíz, etc.} ``` --- ## Anti-patrones · qué NO hacer 1. **No inventar TIPOs nuevos** sin aprobación del Owner. Si ninguno encaja, detenerse y preguntar. 2. **No modificar el contenido** sustantivo del documento durante la canonización. Esta skill es de envoltorio (nombre + frontmatter + H1), no de edición de cuerpo. Si el contenido necesita revisión, hacerlo como paso separado y declarado. 3. **No canonizar sin confirmar la ubicación**. Si el archivo está en `00-Inbox/`, `Projects/`, o cualquier carpeta no canónica, primero invocar `vault-orphan-rescue`. 4. **No omitir el Registry update**. Un activo canonizado que no está en el Registry es un activo invisible para el ecosistema. 5. **No usar `Active` por defecto**. Drafts canonizados siguen siendo Drafts hasta que el Owner los promueve. 6. **No duplicar archivos**. Si el `rm` del archivo anterior falla, no continuar dejando dos versiones en el vault. Resolver el delete antes de cerrar. --- ## Ejemplo de invocación **Input del usuario:** > "Canoniza este doc: `Guia Arranque SherpaX Equipo EL v01.md` en EQ-EL-Equipo." **Flujo de la skill:** 1. Read del archivo → identifica que es una guía operativa de onboarding para colaborador con SherpaX. 2. TIPO = `MiPB` (Mini PlayBook · procedimiento operativo focal). 3. ENTIDAD = `EL` (vive en IB-EL-EmpowerLabs). 4. CONTEXTO = `EQ` (vive en EQ-EL-Equipo · subbank de equipo). 5. Slug = `ArranqueSherpaX-Colaborador` (generalizado para replicabilidad). 6. Nombre canónico = `MiPB-EL-EQ-ArranqueSherpaX-Colaborador-v01.md`. 7. Frontmatter construido con `proposito`, `audiencia_primaria`, `deriva_de`, `referenciado_por`, `tags: [MiPB, EQ, SherpaX, Arranque, Onboarding]`, `duracion_estimada: 30-45 min`. 8. H1 = `# MiPB · Arranque SherpaX para Colaborador EL`. 9. H2 sub-título = `## Guía operativa replicable · stack documental + SOPs + skills + flujo`. 10. Write nuevo archivo · rm archivo anterior · update Registry · reporte al usuario. --- ## Integración con otras skills - **Pre-requisito:** `vault-orphan-rescue` si el archivo está en ubicación incorrecta. - **Post-requisito:** `bmf-registry-updater` para sincronizar Registry (o ejecutar inline el Paso 9). - **Complementaria:** `llm-wiki-validator` si el activo va a ingestarse al Wiki después. - **Complementaria:** `labpraxis-case-documenter` si la canonización reveló un aprendizaje operativo. --- ## Versión - **v01 · 2026-05-20** · Versión inicial. Derivada del proceso ejecutado sobre `Guia Arranque SherpaX Equipo EL v01.md` → `MiPB-EL-EQ-ArranqueSherpaX-Colaborador-v01.md`. Captura el flujo canónico para que cualquier draft del vault pueda elevarse a activo BMF de forma replicable.