zz-mv-gongzuotai · Skill único para la gestión de proyectos MV

Posicionamiento

Este es el skill de entrada único para todo el proyecto MV.
El workbench solo muestra información para la planificación; la generación la realiza el agente llamando a los scripts/ de este skill.
El flujo termina en los segmentos de video: sin edición preliminar, sin ensamblaje, sin montaje final; los segmentos de video + el handoff se entregan a la siguiente fase de edición.

El comando mvwb se refiere al comando global después de la instalación; si ~/.local/bin no está en PATH, usa ~/.agents/skills/zz-mv-gongzuotai/start/mvwb (copiado y con permiso de ejecución durante la instalación); si aún no está disponible, usa python3 ~/.agents/skills/zz-mv-gongzuotai/scripts/mvwb.py.

Workbench y Claves (Reglas estrictas)

El workbench es un archivo workbench.html estático dentro del proyecto: se abre directamente haciendo doble clic o con el navegador usando file://...; no se inicia ningún servicio en segundo plano.
Prohibido usar mvwb server, python -m http.server, puertos o versiones de servicio. El workbench es una página de solo visualización, sin ninguna interfaz de configuración.
Cuando el usuario dice "abre el workbench": ejecutar mvwb open [--workspace NAME], que solo abre el HTML local.
Inicialmente solo se entrega la clave Router: el estudiante coloca el archivo zz-keys.json enviado por el profesor en la raíz del proyecto (generalmente solo contiene {"router": "..."}); el agente ejecuta mvwb keys import --file <proyecto>/zz-keys.json --delete-source. Se importa una vez y es global; el archivo de entrega se elimina después de la importación.
Las claves no pasan por el workbench: el usuario importa zz-keys.json, hace doble clic en start/setup-keys.*, o en la terminal ejecuta mvwb keys set; el agente ejecuta mvwb keys import --file <ruta> --delete-source. El agente solo guía, no solicita la clave; en entornos no interactivos no se debe llamar a keys set.
Las claves de respaldo se gestionan mediante la alerta B001: si el Router falla 3 o más veces consecutivas en 10 minutos y no hay respaldo configurado, el agente genera un bloque de alerta B001; el estudiante reenvía el texto original de la alerta al profesor, quien decide si entregar o no un zz-keys.json de respaldo (con los campos runninghub/apimart). Una vez entregado, se importa y se activa, y se actualiza el saldo/workbench. El agente puede usar mvwb keys watch para evitar una segunda conversación.
Formato de alerta unificado: todos los fallos/bloqueos/avisos usan scripts/alerts.py (tabla de códigos en references/alerts.md), el estudiante solo necesita reenviar el bloque de texto original de la alerta. Prohibido decir directamente "pídele la clave de respaldo al profesor"; las claves de respaldo siempre se entregan a través de la alerta B001, decisión del profesor.
Las claves no se escriben en DATA, HTML, scripts, logs o capturas de pantalla; el archivo de importación descargado debe eliminarse después de la importación. Cuando el usuario ya haya enviado la clave en la conversación, recordarle que la invalide y la reenvíe.
Saldo/coste solo se ve del Router (en CNY): en la parte superior solo se muestra el saldo del Router; todos los costos se convierten a ¥ y se escriben en DATA (la tasa de cambio de RunningHub coins a CNY está en config/models.json con fx.rh_coin, mantenida por el profesor).
Después de cada generación/reemplazo de archivo: actualizar data.json → mvwb build → mvwb check --data .... Si check reporta archivos faltantes, el workbench no los mostrará y no se puede considerar completo.

Entrega final

Un directorio por MV, con música, activos y segmentos de video dentro:

workspaces/<project>/
├─ 原文/
│  ├─ lyric_original.md      Letra original del cliente
│  ├─ story_script.md        Guion de historia original del cliente (sin dividir en tomas)
│  └─ lyric.json             Mapa de números de línea L01…
├─ workbench.html            Workbench del proyecto (solo lectura + importación local de claves)
├─ data.json                 Fuente de datos del workbench (actualizada por el agente)
└─ MV001/
   ├─ mv_manifest.json       Estado de la fase/versión/coste
   ├─ 00_framework.md        Plan de música/activos/segmentos
   ├─ 01_music/
   │  ├─ song_v1.mp3
   │  └─ timeline_v1.json    Inicio y fin en segundos de cada línea (para segmentación/entrega)
   ├─ 02_assets/
   │  ├─ assets_v1.json
   │  ├─ role_xxx.png
   │  ├─ scene_xxx.png
   │  └─ prop_xxx.png
   ├─ 03_segments/
   │  ├─ segments_v1.json    G1/G2… versión actual + historial
   │  ├─ G1_v1.mp4
   │  ├─ G1_v2.mp4           Historial de regeneraciones por revisión
   │  └─ G2_v1.mp4 …
   └─ handoff_v1.json        Lista para el editor

handoff_v1.json solo contiene los campos necesarios para la edición:

{
  "mv_id": "MV001",
  "status": "ready",
  "segments": [
    {
      "segment_id": "G1",
      "line_ids": ["L01", "L02"],
      "music_start": 0.0,
      "music_end": 6.0,
      "duration": 6.0,
      "video_file": "03_segments/G1_v1.mp4",
      "model": "muse-video-ext",
      "resolution": "720x1280",
      "notes": "Versión actual aprobada en revisión"
    }
  ]
}

Contrato de ejecución (obligatorio en cada paso)

Para detalles de entrada/salida/autoverificación, consulta references/step-contract.md. Cada paso consta de cinco elementos fijos:

Paso	Preguntar primero (solo si falta)	Producto	Autoverificación	Puerta
0 Inicialización	Nombre del proyecto, cantidad, duración, estilo, relación de aspecto, presupuesto	workspace + `data.json` + `workbench.html`	`mvwb check` = 0 faltantes	Confirmación de parámetros
1 Texto original	Archivos de letra/guion	`原文/*` + `lyric.json`	Número de líneas/id continuo/sin dividir tomas	Confirmación del texto original
2 Workbench vacío	Parámetros del lote	DATA + HTML estático	build + check + se puede abrir con doble clic	Confirmación del workbench
3 Marco	Comentarios de revisión	manifest + framework + segments	Duración/saltos de línea/segmentos ≤10s	Confirmación del marco + cotización
4 Generación	Elementos a generar	Música/activos/segmentos de video/handoff	Archivo existente/duración/QA/línea de tiempo	Cada elemento locked

La salida de la conversación es uniforme: «conclusión + ruta del producto + resultado de la autoverificación + pendiente de confirmación», sin pegar el JSON completo.
La autoverificación debe ejecutarse realmente y citar los resultados; si falla, se detiene en el paso actual y no continúa silenciosamente al siguiente.

Cuatro pasos

Paso 1 · Texto original

Primero buscar en 原文/, 甲方资料/, 输入/ los archivos de letra/guion; nombres de archivo que contengan 歌词, lyric, 脚本, script.
Si se encuentran, solo se leen y almacenan, sin reescribir, dividir líneas ni "optimizar".
Si no se encuentran: preguntar primero al usuario si tiene material del cliente; si no, guiar según producto/historia/personajes/estilo/duración/referencias para generar un borrador.
Almacenar:

原文/lyric_original.md   Nombre de la canción/estrofa/estribillo, texto original
原文/story_script.md     Guion de historia original, sin dividir en tomas
原文/lyric.json          Mapa de números de línea L01…

Puerta: confirmación del texto original. Una vez que el usuario dice "no hay problema/me quedo con esta versión", se bloquea; cambiar el texto original = reiniciar el workbench.

Paso 2 · Workbench vacío

mvwb init my_project          # Proyecto vacío: 原文/ pendiente, mvs=[], workbench.html generado
mvwb init demo_project --demo # Si se necesita un ejemplo: copia el demo completo
# Después de llenar workspaces/my_project/原文/, que el agente genere el workbench vacío

El agente reconstruye usando templates/workbench.html + DATA.json:

python3 scripts/build_workbench.py \
  --template templates/workbench.html \
  --data workspaces/my_project/data.json \
  --out workspaces/my_project/workbench.html

Abrir el workbench estático:

mvwb open --workspace my_project

Después de generar, detenerse y preguntar (preguntar solo lo que falte, dar valores por defecto para cada elemento):

¿Cómo se llama el proyecto? Por defecto, nombre del cliente/fecha.
¿Cuántos MV se generan por lote? Por defecto, 1 muestra (se recomienda empezar con 1–5).
¿Cuánto dura cada uno? Por defecto, 30s (15/30/45/60s).
¿Qué estilo? Por defecto, según el paquete de referencia (3D Pixar / serie corta realista / estilo japonés sanador / video de referencia del cliente).
¿Relación de aspecto? Por defecto, 9:16 vertical (1080×1920).
¿Referencias de personajes/escenarios/productos? Si hay imágenes, darlas; si no, descripción textual.
¿Presupuesto máximo? Si no se da, primero cotizar, no enviar.

La salida solo debe ser: ruta del producto + resultado de la autoverificación + confirmación de estos 7 elementos. Puerta: confirmación de parámetros del lote. Este paso no gasta dinero.

Contrato de duración (objetivo del usuario vs. duración real de la música)

Duración	Quién la define	Uso
`target_duration`	El usuario en el paso 2 (ej. 45s)	Segundos solicitados para la música, duración total objetivo del MV, presupuesto/número de segmentos, plan del marco
`actual_duration` / `timeline_v1.json`	Leída después de generar la música	Duración real de storyboard/segmentos de video, `seconds` de Muse, número de fotogramas H3, handoff

La duración total se basa en lo que el usuario estableció: al generar la música, se pasa target_duration a 116:value de ACE; la duración total, el número de segmentos y el presupuesto del marco se planifican en base a este valor.
La duración de cada segmento se basa en la duración real de la música: una vez generada la música, se lee actual_duration y la timeline línea por línea, y se actualiza la duration de los storyboards/segmentos de video; los segmentos de video se generan según la duración real de las líneas, no se cortan según la duración planificada.
Manejo de desviaciones: si la diferencia entre la duración real y la objetivo es >1s o >2%, se pausa y se le pregunta al usuario si desea «aceptar la duración real / regenerar la música / recortar en postproducción»; no usar la duración planificada para generar videos en secreto.
Si solo se selecciona video sin música: primero hacer un plan provisional con target_duration; después de agregar la música, marcar todos los segmentos de video como stale y regenerarlos según la línea de tiempo real.
Así se respeta la duración total establecida por el usuario y se garantiza que las imágenes estén alineadas con la música línea por línea.

Paso 3 · Marco de texto del MV

Crear MV001…MV00N, cada uno:

Relación de aspecto por defecto 9:16 vertical (el workbench usa 1080×1920, Muse genera 720×1280); solo se cambia si el usuario lo especifica explícitamente.
Primero escribir el genome: cast_id/outfit_id/face_seed, story_id, music, visual, edit; las reglas están en references/variation.md. Cualquier par de MV en el mismo lote debe diferir en al menos 3 dimensiones; prohibido que tengan el mismo personaje + el mismo atuendo, la misma contradicción de historia, o el mismo genre+BPM+vocal, o el mismo paquete de escenario.
Generar una tabla de diferenciación (cast/story/music/visual/edit de cada MV); si hay combinaciones repetidas, detenerse e intentar con la siguiente opción del pool, no comenzar a trabajar.
mv_manifest.json: todos los stages en not_started; genome, cost/spent=0.
00_framework.md: plan musical, lista de activos, storyboard estándar, plan de segmentos de video; aquí la duration es un valor planificado, con target_duration como objetivo total.
La lista de activos es para que el usuario la revise: vistas de tres cuartos del personaje/escenarios vacíos/accesorios, para garantizar la consistencia visual de los videos posteriores; no es opcional. Explicar al usuario que "sin las imágenes de activos, los personajes/escenarios de cada video variarán".
03_segments/segments_v1.json: primero escribir el plan, videos: [].
Actualizar DATA.mvs: música/activos vacíos, storyboard/segmentos con plan; conservar una instantánea de keys.

Mostrar al usuario un resumen del marco:

¿Hay algo que cambiar en el marco? ¿Qué MV, qué toma, qué línea quieres cambiar? Solo cambiaré lo que indiques.

Puerta: revisión del marco aprobada + confirmación del alcance de generación/cotización.

Paso 4 · Generación y revisión

4.0 Pre-verificación

mvwb keys status
mvwb keys import --file workspaces/my_project/zz-keys.json --delete-source
mvwb keys watch --timeout 600 --data workspaces/my_project/data.json
mvwb keys balance --data workspaces/my_project/data.json
mvwb quote --model muse-video-ext --seconds 2

Si faltan claves / saldo insuficiente / error en la consulta: detenerse. Cotización = cantidad × precio unitario; solo se ejecuta si el usuario confirma.

4.1 Orden: Música → Línea de tiempo → Activos → Segmentos de video

Paso	Comando	Producto
Música	`mvwb rh --app 2075301815628943362 ...`	`01_music/song_v1.mp3`
Línea de tiempo	`mvwb timeline ...`	`01_music/timeline_v1.json`
Activos	`mvwb rh --app 2116462203997081601 ...`	`02_assets/*` + `assets_v1.json`
Video H3	`mvwb rh --wf 2110943749894402050 ...`	`03_segments/G*_v1.mp4`
Video Muse	`mvwb muse --prompt ... --seconds N --size 720x1280 --out ...`	`03_segments/G*_v1.mp4`
Música/Activos (Router)	`tokentech_task.py music	image ...`(protocolo en`references/providers/router.md`)
Entrega	Escribir `handoff_v1.json`	Para el editor

La música se bloquea primero; después de leer la duration/timeline real, se actualiza la duración de los segmentos; los activos se basan en el paquete de referencia; los segmentos de video se generan uno por uno según la duración real de cada línea.
Los activos se generan según la ficha del personaje: las vistas de tres cuartos del personaje usan la plantilla de references/prompts/casting-style.md + paquete de estilo; la regla MOSS es: cuadrícula izquierda para el rostro, cuadrícula central para el cuerpo completo pero la cabeza no debe entrar completamente en el encuadre, cuadrícula derecha para la espalda. Para cada personaje, primero generar 4 candidatos, seleccionar 1 y luego bloquearlo.
Consistencia del personaje dentro del mismo MV: todos los activos/segmentos de video hacen referencia a la ficha del personaje con el mismo cast_id y outfit_id; los cambios de vestuario solo ocurren cuando la historia lo requiere y se registran.
Sin repetición entre MV: los cast_id, historias, música y paquetes de escenario del mismo lote se diferencian según el genome; antes de bloquear los activos, tomar dos MV al azar para verificar que no sean iguales, evitando "el mismo personaje con ropa diferente que parece un MV nuevo".
Cada segmento puede generar múltiples videos: el primero es la versión actual; el historial se agrega como G1_v2.mp4.
Las nuevas versiones se escriben como *_v{n+1}.json, sin sobrescribir las antiguas.
Actualizar stages/status/spent, reconstruir DATA.
Después de reconstruir, es obligatorio autoverificar: mvwb build --data ... --out ... && mvwb check --data ...; el número de archivos faltantes debe ser 0, de lo contrario, primero corregir las rutas o regenerar.
La página es estática con file://, las rutas relativas se basan en el directorio donde se encuentra workbench.html; no cambiarlas manualmente a rutas absolutas.

4.2 Ciclo de revisión

¿La generación está completa? ¿Qué hay que cambiar? ¿Qué MV, qué segmento de video, qué imagen/canción?

Solo regenerar los elementos señalados; nueva versión + historial.
Una vez que la música está locked, no se puede cambiar; cambiar la música = crear un nuevo MV.
Dentro del mismo lote, primero hacer deduplicación aproximada de la música: genre + BPM band + vocal no pueden ser todos iguales; si los primeros 10 segundos suenan como la misma canción, cambiar music_id.
Activos con qa: pass / warn / fail: fail debe regenerarse; warn requiere confirmación del usuario antes de usarse.
Cambios en activos → los segmentos de video que dependen de ellos se marcan como stale.
Cambios en el plan de storyboard/segmentos de video → los segmentos de video correspondientes se marcan como stale.
El usuario dice "versión final/ok" → el stage correspondiente se marca como locked.

4.3 Entrega

Después de que todos los segmentos de video estén locked:

Escribir handoff_v1.json (o handoff_v1.csv).
Verificar cada segmento: video_file existe, duration ≤10s, music_start/end coherentes con la línea de tiempo.
Proyecto terminado; el editor toma los segmentos de video y el handoff para la siguiente fase.

Siguiente MV: dentro del mismo workbench, continuar con MV002, reutilizando las reglas de música/activos ya bloqueadas; primero generar el marco y luego la generación; para cambiar de letra/cliente, usar mvwb init <nombre_proyecto> para crear un nuevo workspace, sin sobrescribir el proyecto anterior.

Reglas de versión/revisión

Estado	Significado	UI
`not_started`	No generado	Círculo gris
`draft`	Hay producto pendiente de revisión	Círculo ámbar
`locked`	Versión final aprobada	Círculo verde
`stale`	El upstream ha cambiado, necesita regeneración	Círculo naranja
`failed`	Fallo	Círculo rojo

Si el upstream no está locked, el downstream no comienza.
Solo cambiar lo señalado; el resto se conserva textualmente.
El historial no se sobrescribe; spent acumula los costos históricos.
El workbench solo muestra el color del círculo, no el texto del estado.

Enrutamiento de modelos y prompts

Fase	Por defecto	Ver referencia
Música ACE-Step	`2075301815628943362`	`references/prompts/ace.md`
Activos MOSS	`2116462203997081601`	`references/prompts/moss.md`
Video H3 multiparámetro	`2110943749894402050`	`references/prompts/h3.md`
Video Muse (Router)	`muse-video-ext`	`references/prompts/muse.md`
S2V Sincronización labial	`1979183169033375745`	`references/prompts/h3.md`
API RunningHub	—	`references/providers/runninghub.md`
API Router/Saldo	—	`references/providers/router.md`
Contrato DATA del workbench	—	`references/workbench-contract.md`
Contrato de ejecución de cuatro pasos	—	`references/step-contract.md`
Variación/diferenciación/deduplicación	—	`references/variation.md`
Distribución/importación de claves	—	`references/key-distribution.md`
Tabla de códigos de alerta/alarma	—	`references/alerts.md`
Ficha de personaje/estilo/guapos/estilo sanador	—	`references/prompts/casting-style.md`
Campos de entrega	—	`references/handoff.md`

El modelo de video se confirma por segmento; diferentes segmentos pueden usar diferentes modelos, pero el paquete de estilo/paleta de colores del mismo MV debe ser uniforme.
Múltiples imágenes de referencia: vistas de tres cuartos del personaje (no cuatro vistas)/tableros de escenario/accesorios/fotos reales del producto; una imagen por función; primero ejecutar 1 segmento de muestra.

Claves

Única fuente de verdad: ~/.config/mv-workbench/keys.json (0600).
Configuración: mvwb keys set runninghub, mvwb keys set router (entrada oculta en terminal).
Saldo: mvwb keys balance --data workspaces/<project>/data.json → mvwb build.
Las claves originales no entran en HTML/DATA/logs; DATA.keys solo contiene máscaras e instantáneas de saldo.
Los comandos de generación se inyectan uniformemente a través de mv_keys.py exec; no depender de claves residuales en el shell.

Comandos comunes

mvwb doctor
mvwb open
mvwb open --workspace my_project
mvwb init my_project
mvwb keys status
mvwb keys import --file workspaces/my_project/zz-keys.json --delete-source
mvwb keys watch --timeout 600 --data workspaces/my_project/data.json
mvwb keys balance --data workspaces/my_project/data.json
mvwb quote --model muse-video-ext --seconds 2
mvwb build --data workspaces/my_project/data.json --out workspaces/my_project/workbench.html
mvwb check --data workspaces/my_project/data.json
mvwb rh --app <id> --name <tag> --overrides <json> --out <dir>
mvwb muse --prompt "..." --seconds 2 --size 720x1280 --out out.mp4
python3 scripts/providers/tokentech_task.py image --prompt "..." --seed 123 --out out.png
python3 scripts/providers/tokentech_task.py music --lyrics "..." --style "..." --seconds 60 --out out.mp3
mvwb timeline <lyric.json> <audio.mp3> --out <dir>

Qué no hacer

No editar, no ensamblar, no hacer subtítulos/mezcla de audio/montaje final.
No revisar automáticamente; después de que el usuario solicite cambios, solo regenerar los elementos señalados.
No enviar las letras/guiones/material del cliente a repositorios públicos.

Archivos

SKILL.md          Punto de entrada del agente (este archivo)
start/            Punto de entrada humano: instalación, comando mvwb, configuración de claves con un clic
scripts/          mvwb, keys, alerts, build, timeline, providers
references/       Contrato del workbench, contrato de pasos, tabla de códigos de alerta, prompts, proveedores
templates/        workbench.html
contracts/        Contratos de timeline/storyboard/segments/mv
demo/             Demo original (se puede abrir directamente)
config/           Precios de modelos / tasa de cambio fx / ejemplo de claves
workspaces/       Proyectos de estudiantes (un directorio por proyecto)

Versiones

v0.4.4 (2026-11-14): Protocolo de tareas Router probado y funcional (moss genera imágenes / ace genera música): POST /v1/responses + metadata.nodeInfoList enlace directo a nodos RunningHub; nuevo scripts/providers/tokentech_task.py; duración/BPM/letras/estilo/prompt negativo/seed totalmente parametrizables; facturación por tiempo de ejecución de RH.
v0.4.3 (2026-11-14): Interfaz de workbench simplificada: eliminada la configuración de claves en la página; saldo solo muestra valor numérico sin máscara; eliminados los acumuladores en la cabecera de MV; alineación de estados vacíos de música/activos; eliminado todo el texto "solo lectura" de la página; orden de la barra superior: tiempo de generación → saldo.
v0.4.2 (2026-11-14): Reorganización de directorios: archivos de entrada (instalación/mvwb/setup-keys) en start/, archivos de desarrollo en dev/ y docs/; ejemplo de claves renombrado a config/zz-keys.example.json; raíz solo con SKILL/README/LICENSE/NOTICE.
v0.4.2 (2026-11-14): Reorganización de directorios: archivos de entrada en start/, archivos de desarrollo en dev/, docs/; raíz solo con 4 archivos; ejemplo de claves renombrado a config/zz-keys.example.json.
v0.4.1 (2026-11-14): Formato de alerta unificado (scripts/alerts.py + tabla de códigos en references/alerts.md); clave de respaldo cambiada a alerta B001 reenviada al profesor; integración total de keys/providers/check/build; manual actualizado con «reenvía el texto original de la alerta al profesor». (2026-11-14): Cadena principal Router + clave de respaldo entregada bajo demanda; solo se muestra el saldo del Router en la parte superior; costos siempre convertidos a ¥ (fx.rh_coin); capa de keys soporta segmento independiente apimart; salida de quote convertida a CNY.
v0.3.9 (2026-11-14): Archivo de clave entregado por el profesor unificado como zz-keys.json; watcher reconoce tanto mv-keys-import*.json como zz-keys.json.
v0.3.8 (2026-11-14): JSON de entrega de clave simplificado a dos campos {"runninghub":"...","router":"..."}; issued_to/expires_at/mv_keys_import pasan a ser opcionales, solo necesarios para registro o recogida automática por watcher.
v0.3.7 (2026-11-14): Nuevo estándar de entrega de clave por el profesor: zz-keys.json en la raíz del proyecto, keys import --delete-source; formato de ejemplo y reglas de entrega en references/key-distribution.md.
v0.3.6 (2026-11-14): Nuevo mvwb keys watch; el agente primero escucha el directorio de descargas, cuando el usuario completa la clave en el workbench y la descarga, se importa/elimina automáticamente, opcionalmente actualiza el saldo y reconstruye el workbench.
v0.3.5 (2026-11-14): "Configurar clave" en la esquina superior derecha del workbench: llenar clave localmente → descargar mv-keys-import.json → agente keys import --delete-source; sin servicio, sin red.
v0.3.4 (2026-11-14): setup-keys con un clic (Mac/Win); keys set en entornos no interactivos rechaza en lugar de mostrar traceback; miniaturas de video en workbench muestran el primer fotograma; mensaje de keys init cambiado a --data.
v0.3.3 (2026-11-13): Nuevas reglas de variación/diferenciación y paquete de prompts de estilo de personaje (atuendos de Xiaohongshu/estilo japonés dulce/estilo coreano de oppa/películas sanadoras/guapos); Paso 3 requiere genome y tabla de diferenciación.
v0.3.2 (2026-11-13): Alineación con el manual de usuario: clave ingresada por el usuario en su máquina; agregar nombre del proyecto/confirmación de tres pasos, bloqueo de música y desviación de duración, QA de activos, cotización de cambios grandes, directorio data.json.
v0.3.1 (2026-11-13): Instalación/actualización conserva workspaces; init por defecto es proyecto vacío (--demo copia demo); build/check con rutas relativas que caen en la raíz del skill; documentación simplificada dentro del paquete.
v0.3.0 (2026-11-13): Eliminado el servicio en segundo plano, workbench vuelve a ser puramente estático; claves/saldo pasan a CLI; nuevo contrato de ejecución de cuatro pasos y mvwb check; corregida la transmisión de parámetros.

zz-mv-gongzuotai

¿Qué es zz-mv-gongzuotai?

Preguntar en tu IA favorita

Documentación