taptap-maker-builder (Construcción de proyectos en TapTap Maker)
Este Skill hace dos cosas
- Poner al Agente al día rápidamente: Explica en una pantalla qué es TapTap Maker, cómo elegir entre las dos formas de crear, los cinco elementos clave del primer prompt, los créditos y temas, y cómo leer el Benchmark. Cuando surge un problema concreto, se lee solo la referencia correspondiente.
- Del diseño a la publicación: Usa las fases 0–6 con puertas de confirmación para convertir un documento de diseño en un proyecto jugable paso a paso. Cada fase tiene entregables, plantillas y listas de verificación. Solo se pasa a la siguiente fase cuando el usuario confirma.
Este Skill solo se encarga de cómo avanzar, no inicia proyectos reales por el usuario. Todos los cambios en el proyecto ocurren dentro del proyecto Maker del usuario y siempre después de su confirmación.
Cuándo usarlo
- El usuario pregunta sobre TapTap Maker / Maker / UrhoX / Instituto de Creación Maker / Ranking / Créditos / Temas UI / Cómo conectar MCP local.
- El usuario sube o pega un documento de diseño de juego, una lista de requisitos, y pide «monta esto», «hazlo jugable», «sigue este diseño».
- El usuario necesita escribir prompts para Maker, calcular el consumo de créditos, verificar los materiales de publicación, o solucionar problemas de previsualización o de dispositivo real.
No aplica: Unity / Unreal u otros motores; proyectos artísticos puros; programación general que no sea para Maker.
Tres reglas de oro (si se incumplen, parar)
- Prioridad a la documentación online: El producto evoluciona rápido. Primero leer https://maker.taptap.cn/llms.txt, luego leer los documentos correspondientes según sea necesario. El conocimiento de este Skill tiene una fecha de recopilación; si hay conflicto con la documentación online, prevalece esta última. No inventar funcionalidades, parámetros, nombres de modelo, precios o límites que no aparezcan en los documentos.
- Las puertas de confirmación no se saltan: Al final de cada fase (0–5), entregar un «informe de fase» y esperar la confirmación explícita del usuario («confirmado», «continuar», «vale») antes de avanzar. Si el usuario no confirma, quedarse en la misma fase y preguntar.
- No gastar dinero ni modificar archivos sin permiso: No llamar a herramientas que consuman créditos sin una solicitud explícita del usuario en la conversación. No cambiar automáticamente de modelo o canal. No mover, eliminar ni sobrescribir archivos del usuario. Si se añade un sistema fuera del alcance del diseño, pedir permiso primero.
Resumen del producto en 60 segundos
| Dimensión | Puntos clave |
|---|---|
| Producto | TapTap Maker: herramienta de creación de juegos con IA para aficionados. Permite diseñar, programar, generar assets, iterar en previsualización y preparar la publicación usando lenguaje natural. |
| Motor subyacente | Motor UrhoX + Lua; incluye tres temas UI integrados: Astroon, BrawlForge y PixelForge. |
| Eslogan | Crea conversando, publica al terminar. |
| Dos formas de crear | Área de trabajo del navegador (proyecto, chat, previsualización y publicación en una misma página); modo de desarrollo local (Maker MCP conectado a un directorio local, compatible con Codex / Cursor / Claude Code). |
| Entrada oficial | https://maker.taptap.cn/llms.txt (índice completo de toda la documentación, la más actualizada). |
Cinco elementos esenciales para el primer prompt (hay que poder responderlos antes de escribir el prompt): Objetivo de jugabilidad / Estilo visual / Controles / Ciclo principal / Alcance inicial.
Créditos: Cinco tipos: generales, básicos, de actividad, de proyecto y de pago. El orden de consumo por defecto es actividad → proyecto → básicos. El uso de los créditos generales y de pago depende del modelo actual, el alcance del proyecto y la verificación del servidor. Las operaciones en el panel de publicación no consumen créditos de creación.
Benchmark: Ejecución real sin cabeza de UrhoX + aserciones deterministas. La métrica principal del ranking es la tasa de aprobación L2. Cada puntuación tiene un intervalo de confianza del 95%; cada puesto tiene un rango posible. Si los rangos se solapan, quiere decir que «con la muestra actual aún no se puede determinar quién va primero».
Navegación de referencias (leer solo una según necesidad)
| Problema o situación | Cuál leer | Qué contiene |
|---|---|---|
| Qué es el producto, cómo elegir entre los dos modos, cómo instalar MCP, cómo es la estructura de directorios, cómo añadir colaboradores | ./references/01-product-overview.md | Posicionamiento y límites de capacidad, comparación de modos, comandos de instalación, estructura de directorios, Runtime local, reglas de colaboración |
| Cómo se descuentan los créditos, qué gasta créditos, qué hacer si el resultado es incierto, cómo ahorrar | ./references/02-credits-and-cost.md | Los cinco tipos de créditos, orden de consumo, control de costes, gestión de resultados inciertos |
| Qué tema elegir, cómo especificar el tema, especificaciones y límites de assets, cómo escribir prompts de generación de imágenes | ./references/03-ui-themes-and-assets.md | Categorías de juego y reglas visuales de los tres temas, límites de los cinco tipos de assets, DWP, convenciones de directorios de assets |
| Cómo leer el ranking, qué es L2, cómo interpretar intervalos de confianza y rangos de posición | ./references/04-benchmark-guide.md | Sistema de puntuación de tres niveles, significado de cada dimensión y errores comunes, método estadístico, limitaciones |
| Cómo desglosar un diseño, qué hacer si faltan los cinco elementos esenciales, cómo escribir el primer prompt | ./references/05-brief-parsing-and-first-prompt.md | Tabla de extracción, límite de preguntas aclaratorias y cómo preguntar, puntos clave del formulario de confirmación, ejemplos de buenos y malos primeros prompts |
| Cómo plantear iteraciones, cómo escribir el formato de cuatro partes, lista de verificación de previsualización (5 ítems), prepublicación (6 ítems) y datos (6 ítems) | ./references/06-iteration-and-acceptance.md | Formato de cuatro partes, orden de avance oficial, listas de verificación, modos de fallo comunes |
| Qué materiales se necesitan para publicar, cómo usar el código QR de prueba, cómo abrir la página para compartir | ./references/07-publish-checklist.md | Lista y especificaciones de materiales, proceso de publicación, sincronización de versiones de prueba, acciones posteriores a la publicación |
| Dónde guardar las credenciales, qué acciones son irreversibles, escritura atómica, derechos de autor de assets, seguridad en la colaboración | ./references/08-safety-and-credentials.md | Caducidad, costes, credenciales, acciones irreversibles, escritura atómica, alcance y derechos de autor |
Regla: leer solo la referencia relevante para el problema actual; después de leer, responder sin inventar detalles.
Resumen de fases (0–6)
| Fase | Objetivo | Entregable | Puerta de confirmación | Herramientas / Plantillas |
|---|---|---|---|---|
| 0 Conexión | Decidir el modo de creación; en modo local, verificar MCP, vinculación del proyecto y directorio existente | Confirmación de conexión + resultado de verificación del directorio | El usuario confirma el modo y el entorno | ./scripts/check_project_layout.py |
| 1 Análisis | Extraer estructuradamente los cinco elementos esenciales; preguntar las ausencias de una sola vez (≤4 preguntas) | Formulario de confirmación de comprensión del diseño | El usuario confirma uno a uno los cinco elementos antes de escribir el prompt | ./assets/brief-confirmation-template.md, ./scripts/check_brief.py |
| 2 Primer prompt | Redactar el primer prompt conforme a las normas oficiales, centrándose solo en el ciclo principal mínimo jugable | Texto del primer prompt + dirección del tema y estilo visual | El usuario confirma el prompt y la dirección del tema | ./assets/first-prompt-template.md |
| 3 Iteración | Mínimo jugable → corrección de bloqueos → ritmo, valores y jugabilidad → assets, sonido, guía y materiales | Prompt en formato de cuatro partes para cada ronda + resultado de validación | Cada ronda se valida antes de pasar a la siguiente | ./assets/feedback-four-part-template.md, ./references/06-iteration-and-acceptance.md |
| 4 Previsualización y dispositivo real | Cinco puntos de verificación + código QR de prueba en dispositivo real | Registro de verificación, lista de problemas | Solo si los cinco puntos pasan se pasa a publicación | ./references/06-iteration-and-acceptance.md, ./references/07-publish-checklist.md |
| 5 Publicación | Verificar los materiales uno a uno; publicar cuando la versión coincida | Lista de verificación de materiales de publicación | El usuario confirma que los materiales y la versión coinciden | ./scripts/check_publish_materials.py, ./assets/stage-report-template.md |
| 6 Transversal | Protección de costes y seguridad, activa en cada fase | Avisos de riesgo y registros de confirmación | Acciones de alto riesgo requieren confirmación cada vez | ./references/02-credits-and-cost.md, ./references/08-safety-and-credentials.md |
Disciplina de avance: Al final de cada fase, entregar primero el «informe de fase» → esperar confirmación explícita del usuario → solo entonces pasar a la siguiente fase.
Fase 0: Conexión
Preguntar todo de una vez, sin ir preguntando de a poco:
- ¿Área de trabajo del navegador o MCP local (directorio local + Codex / Cursor / Claude Code)?
- ¿Es un proyecto existente o uno nuevo? ¿Nombre del proyecto, género del juego?
- ¿Hay assets o directorios de código existentes que se quieran reutilizar?
| Situación | Recomendación |
|---|---|
| Primera vez, quiere ver resultados rápido | Área de trabajo del navegador |
| Ya tiene código o assets locales, quiere usar Codex / Cursor / Claude Code | MCP local |
| Quiere usar Git, colaborar con varios, hacer comprobaciones locales | MCP local |
| Solo quiere probar rápido en el móvil | Área de trabajo del navegador + código QR para compartir |
Comandos para modo local (ejecutar en el directorio de destino; init descargará el proyecto en el directorio actual, primero confirmar que el directorio está vacío o que el usuario acepta la fusión):
npx -y @taptap/maker install --ide codex,cursor,claude # Solo escribe la configuración MCP de los tres IDE
npx -y @taptap/maker init # Iniciar sesión + seleccionar/crear proyecto + vincular directorio + descargar
- Estructura típica tras la inicialización: directorios
assets/(conimage,sprites,audio,video) yscripts/; la estructura real varía según el proyecto. - Antes de modificar nada, ejecutar
python ./scripts/check_project_layout.py <raíz del proyecto>y leer el directorio existente y sus notas para no sobrescribir recursos en uso. - Actualizar componentes: «Actualiza Maker MCP y AI DevKit del proyecto actual, y dime las versiones que estoy usando»; en producción usar
pd/stable, para pruebas usarrnd/latest. - Las credenciales solo se almacenan en entornos locales de confianza, no se escriben en archivos del proyecto ni en Git.
Mensaje de puerta de confirmación 0: «Me preparo para conectar con modo X. El directorio del proyecto es Y. La estructura existente es Z. No sobrescribiré A. Confirma para pasar al análisis del diseño.»
Fase 1: Análisis del diseño
Procedimiento:
- Leer el diseño completo y extraer directamente la tabla de los cinco elementos, sin repetir párrafos enteros.
- Marcar cada elemento como: Presente (con evidencia del texto) / Inferido (requiere confirmación) / Ausente.
- Preguntar por las ausencias y ambigüedades clave de una sola vez, ≤4 preguntas, dando 2–3 respuestas candidatas para reducir el coste de respuesta.
- Producir un «Formulario de confirmación de comprensión del diseño» que incluya obligatoriamente: «Lo que entiendo / Lo que no estoy seguro / Lo que recomiendo no incluir en la primera ronda».
- Solo después de la confirmación del usuario se pasa a la fase 2.
Reglas estrictas:
- Los elementos clave (temática, protagonista, condición de victoria/derrota, controles, plataforma destino y estilo visual) no se pueden inventar. Si faltan, preguntar, o marcarlos claramente como «pendiente» con una sugerencia por defecto.
- Los sistemas avanzados del diseño (desarrollo, tienda, multijugador, ranking, múltiples capítulos) se colocan en «versiones futuras», no en la primera ronda.
- En el formulario de confirmación debe indicarse claramente «Qué no se hará en la primera ronda».
Se puede usar el script para verificar si los cinco elementos están completos (la estructura JSON está en los comentarios del script):
python ./scripts/check_brief.py brief.json
Fase 2: Generación del primer prompt
Orden para escribir el primer prompt: Frase de posicionamiento → Cinco elementos → Controles y reglas de victoria/derrota → Lista de interfaces → Fuera del alcance.
- Un solo prompt debe resolver un solo resultado; primero hacer el ciclo principal mínimo jugable.
- Indicar claramente «qué no se hace en esta ronda» ayuda más a acotar el alcance que enumerar muchas funcionalidades.
- Confirmar al mismo tiempo: tema UI (Astroon / BrawlForge / PixelForge), orientación (horizontal / vertical), perspectiva (2D / 3D), estilo artístico.
- Plantilla: ./assets/first-prompt-template.md; ejemplos buenos/malos en ./references/05-brief-parsing-and-first-prompt.md.
Mensaje para confirmar tema y dirección: «Te sugiero el tema A (motivo: encaja con el género), en vertical 2D. Si prefieres B, lo cambio. Confirma para que envíe el primer prompt.»
Fase 3: Iteración y construcción
Orden oficial de avance (no saltar):
- Versión mínima jugable (poder empezar, interactuar, terminar y reiniciar)
- Corregir problemas de bloqueo del flujo (congelaciones, botones inaccesibles, estados que no se reinician)
- Ajustar ritmo, valores y jugabilidad
- Añadir assets, sonido, guía y materiales de publicación
Cada prompt de iteración debe usar el formato de cuatro partes: Objetivo / Estado actual / Restricciones / Verificación (plantilla ./assets/feedback-four-part-template.md).
- Centrarse en un solo resultado por vez; no mezclar «añadir sonido + cambiar valores + cambiar tema» en el mismo prompt.
- En «Restricciones» escribir lo que debe conservarse (controles actuales, tema confirmado, módulos que no deben refactorizarse).
- En «Verificación» escribir fenómenos observables, no «que sea más divertido».
- Pedir a la IA que construya por sí misma, verifique errores y explique los resultados de la validación; para cambios complejos, pedir primero un breve plan.
- Mantener el mismo objetivo en la misma conversación; para cambiar de dirección, iniciar una nueva conversación.
Al reportar un error, dar los cinco datos completos: dispositivo / página, pasos para reproducir, comportamiento real, comportamiento esperado, ¿se puede reproducir? (se puede adjuntar captura de pantalla o grabación).
Fase 4: Previsualización y dispositivo real
Cinco puntos de verificación (lista oficial, anotar la conclusión de cada uno):
- ¿Puede iniciarse correctamente?
- ¿Los controles funcionan según lo esperado (incluyendo áreas táctiles, botones cliqueables)?
- ¿Victoria / Derrota / Reinicio funcionan correctamente?
- ¿La imagen se ve clara en el dispositivo destino (tamaño de letra, contraste, zona segura)?
- ¿Hay problemas que bloqueen el flujo?
Dispositivo y uso compartido:
- La previsualización de escritorio permite cambiar a PC / Móvil / Tablet y resolución (incluye el notch del iPhone 17, que bloquea la zona de clic).
- Dispositivo real: en la barra de previsualización, «Compartir» → enlace / código QR; antes de crear la página para compartir, hay que seleccionar en el panel de publicación el editor que ya haya completado la verificación de desarrollador.
- Código QR de prueba en dispositivo real: «Probar en el móvil escaneando» → «Actualizar versión de prueba» → escanear; si se cambia código, orientación, configuración o assets, hay que volver a actualizar la versión de prueba, de lo contrario se escaneará la versión antigua.
- Al cambiar entre horizontal y vertical, la IA debe modificar simultáneamente el diseño de la interfaz y la configuración de orientación del proyecto; después de cambiar, reconstruir y verificar en previsualización / dispositivo real que los botones, textos y controles táctiles funcionan.
Si no se supera la verificación, volver a la fase 3 y escribir un prompt en formato de cuatro partes. No saltar a publicación.
Fase 5: Preparación de la publicación
Lista de materiales (verificar uno a uno):
- Icono del juego
- Al menos 3 capturas de pantalla del juego
- Imagen promocional, portada horizontal, portada vertical
- Para juegos verticales, además una imagen cuadrada promocional
- Nombre del juego
- Descripción del juego ≥10 caracteres
- «Palabras del desarrollador» ≥10 caracteres
- Vídeo de prueba en dispositivo real necesario para la primera publicación oficial
Procedimiento: generación de materiales (consume créditos, requiere consentimiento explícito del usuario) → verificación en el panel de publicación → actualizar versión de prueba y escanear para re-verificar → publicación oficial.
- Si hay varios editores de publicación, seleccionar primero el editor; el botón de publicación solo está disponible después de completar la generación de materiales.
- Las operaciones en el panel de publicación no consumen créditos de creación.
- La verificación de salud previa a la publicación se encuentra en ./references/06-iteration-and-acceptance.md (6 ítems previos a la publicación, 6 ítems de verificación de datos).
- Comando de verificación:
python ./scripts/check_publish_materials.py materials.json --root <raíz del proyecto>.
Fase 6 (Transversal): Protección de costes y seguridad
Ejecutar en cada fase:
- Créditos: No llamar a herramientas que consuman créditos sin una solicitud explícita del usuario en la conversación. Antes de un consumo elevado, explicar «qué se va a gastar, cuánto aproximadamente, si se puede hacer más barato». No cambiar automáticamente de modelo o canal.
- Resultado incierto no reintentar: Si tras enviar una petición no se obtiene un resultado claro → marcar como incierto, primero comprobar el estado. Si es necesario reintentar, pedir confirmación al usuario y explicar que es posible que ya se haya cobrado.
- Credenciales: No mostrar, no escribir automáticamente, no incluir en archivos del proyecto ni en Git. Solo autorizar a clientes de confianza.
- Acciones irreversibles: Eliminar o sobrescribir assets, reemplazar modelos, cambiar de canal, borrar configuración, publicación oficial — detenerse primero, explicar las consecuencias y cómo deshacer, y obtener un «sí» explícito antes de proceder.
- Alcance: Solo construir dentro del alcance del diseño. Si se añaden nuevos sistemas o mecánicas, pedir permiso primero. No mover, eliminar ni modificar archivos del usuario sin permiso.
- Escritura atómica (cuando scripts o herramientas escriban archivos): archivo temporal + renombrar; no sobrescribir valores existentes con valores nulos; si un archivo está dañado, guardar una copia aparte para análisis.
Detalles en ./references/08-safety-and-credentials.md y ./references/02-credits-and-cost.md.
Informe de fase
Antes de pasar a la siguiente fase, usar ./assets/stage-report-template.md para generar cuatro bloques: qué se ha hecho en esta fase / entregable / resultado de la validación / siguiente paso y puntos que requieren confirmación. Al final del informe debe haber una frase de petición de confirmación que se pueda responder.
Mantenimiento y actualidad
- Fecha de recopilación del conocimiento de este Skill: 2026-11-03. El producto evoluciona rápido; para todo lo que involucre funcionalidades, parámetros, modelos, precios o límites, atender siempre a la documentación online.
- Resolución de conflictos: Documentación online > este Skill. Si se encuentra una discrepancia, ejecutar según la documentación online e indicar la diferencia en la respuesta.
- Actualización: Primero leer https://maker.taptap.cn/llms.txt para encontrar la página correspondiente; cuando se necesite el texto original, obtener el contenido en texto plano de la dirección .md correspondiente.
- Prohibido inventar: Si una funcionalidad, parámetro, nombre de modelo, precio o límite no aparece en la documentación, responder siempre «La documentación no lo especifica; lo consultaré o consulta la página oficial».
Ejemplos de prompts
- «Quiero hacer un juego de esquiva en vertical 2D. Primero ayúdame a ver por dónde empezar.» → Fase 0 / 1.
- «Este es mi diseño (adjunto). Ayúdame a montarlo.» → Desde fase 0, fase por fase con confirmación.
- «¿Cómo se descuentan los créditos en Maker? ¿Cuánto cuesta generar una imagen?» → Leer solo references/02, responder directamente, sin entrar en el flujo de trabajo.
- «En el ranking, las tasas de aprobación L2 del 60% y el 63%, ¿son muy diferentes?» → Leer solo references/04, hablar de intervalos de confianza y rangos de posición.
- «Usa el tema Astroon para hacer la pantalla de inicio. No toques la jugabilidad.» → Fase 3, escribir prompt en formato de cuatro partes.