Que fait taptap-maker-builder (Constructeur de projet TapTap Maker) ?
Ce que fait ce skill (deux missions)
- Mettre rapidement un agent à niveau : expliquer en une page ce qu'est TapTap Maker, comment choisir entre les deux modes de création, les cinq éléments du premier besoin, les crédits et thèmes, comment lire le Benchmark ; en cas de problème précis, lire uniquement la référence correspondante.
- Du cahier des charges à la publication : utiliser les phases 0 à 6 avec des portes de confirmation pour transformer progressivement un cahier des charges en un projet jouable. Chaque phase a un livrable, un modèle et une liste de vérification ; l'utilisateur doit confirmer avant de passer à la suivante.
Ce skill ne fait que guider le processus, il ne démarre pas de vrai projet pour l'utilisateur. Toutes les modifications du projet se font dans le propre projet Maker de l'utilisateur, et seulement après confirmation.
Quand l'utiliser
- L'utilisateur pose des questions sur TapTap Maker / Maker / UrhoX / Institut Maker / Classement / Crédits / Thème UI / MCP local.
- L'utilisateur télécharge ou colle un cahier des charges, un document de besoins, et demande « construis-le », « rends-le jouable », « fais-le selon ce brief ».
- L'utilisateur veut écrire des besoins de dialogue Maker, estimer la consommation de crédits, vérifier les éléments de publication, dépanner un aperçu ou un appareil réel.
Non applicable : Unity / Unreal et autres moteurs ; pure sous-traitance graphique ; programmation générale sans lien avec Maker.
Trois règles d'or (stoppe-toi si elles ne sont pas respectées)
- Priorité à la documentation en ligne : le produit évolue vite, commence par lire https://maker.taptap.cn/llms.txt, puis lis le document correspondant. Les connaissances de ce skill ont une date de mise à jour ; en cas de conflit avec la documentation en ligne, c'est la documentation en ligne qui prévaut. N'invente jamais de fonctionnalités, paramètres, noms de modèles, prix ou limites que la documentation ne mentionne pas.
- La porte de confirmation est obligatoire : à la fin de chaque phase 0–5, remets d'abord un « rapport de phase », puis attends la confirmation explicite de l'utilisateur (« confirmé », « continue », « d'accord ») avant de passer à la suivante. Si l'utilisateur n'a pas confirmé, reste sur place et pose une question.
- Ne dépense pas d'argent, ne modifie pas de fichiers sans autorisation : sans demande explicite de l'utilisateur dans la conversation, n'utilise pas d'outils de génération consommant des crédits ; ne change pas automatiquement de modèle ou de canal ; ne déplace, supprime ou remplace pas les fichiers de l'utilisateur ; pour des systèmes hors périmètre du cahier des charges, demande d'abord l'autorisation.
Aperçu produit en 60 secondes
| Dimension | Point clé |
|---|---|
| Produit | TapTap Maker : outil de création de jeux IA destiné aux passionnés, utilisant le langage naturel pour la conception, la génération de code, la création d'assets, l'itération d'aperçu et la préparation à la publication |
| Moteur | Moteur UrhoX + scripts Lua ; thèmes UI intégrés Astroon / BrawlForge / PixelForge |
| Slogan | Créer en dialoguant, publier en terminant |
| Deux modes de création | Espace de travail navigateur (projet, dialogue, aperçu, publication sur une même page) ; Mode développement local (Maker MCP connecté à un répertoire local, compatible Codex / Cursor / Claude Code) |
| Entrée officielle | https://maker.taptap.cn/llms.txt (index principal de toute la documentation, le plus à jour) |
Les cinq éléments du premier besoin (doivent être renseignés avant d'écrire le besoin) : Objectif de gameplay / Forme / Contrôles / Boucle centrale / Périmètre initial.
Crédits : cinq types (général, de base, d'activité, de projet, payant) ; ordre de consommation par défaut Activité → Projet → Base, la disponibilité des crédits Général et Payant dépend du modèle actuel, du périmètre du projet et de la validation serveur. Les opérations sur le panneau de publication ne consomment pas de crédits de création.
Benchmark : exécution sans interface réelle d'UrhoX + assertions déterministes. La métrique principale du classement est le taux de réussite L2. Chaque score est accompagné d'un intervalle de confiance à 95 %, chaque rang a une plage possible ; si les plages se chevauchent, cela signifie « avec l'échantillon actuel, on ne peut pas encore départager les rangs ».
Navigation des références (lire une seule, selon le besoin)
| Question ou scénario | Référence à lire | Contenu |
|---|---|---|
| Qu'est-ce que le produit, comment choisir entre les deux modes, comment installer MCP, à quoi ressemble la structure de répertoire, comment ajouter un collaborateur | ./references/01-product-overview.md | Positionnement et limites, comparaison des modes, commandes d'installation, structure de répertoire, Runtime local, règles de collaboration |
| Comment sont déduits les crédits, qu'est-ce qui consomme des crédits, que faire si le résultat est inconnu, comment économiser | ./references/02-credits-and-cost.md | Cinq types de crédits, ordre de consommation, maîtrise des coûts, registre des incertitudes |
| Quel thème choisir, comment spécifier un thème, spécifications et limites des assets, comment rédiger un prompt de génération d'image IA | ./references/03-ui-themes-and-assets.md | Catégories adaptées et règles visuelles pour les trois thèmes, cinq types de limites pour les assets, DWP, conventions de répertoire des assets |
| Comment lire le classement, qu'est-ce que L2, comment interpréter l'intervalle de confiance et la plage de rangs | ./references/04-benchmark-guide.md | Notation en trois niveaux, signification et erreurs d'interprétation de chaque dimension, méthode statistique, limites |
| Comment décomposer un cahier des charges, comment poser des questions si l'un des cinq éléments manque, comment rédiger le premier besoin | ./references/05-brief-parsing-and-first-prompt.md | Tableau d'extraction, nombre maximal de questions et formulation, points clés de la fiche de confirmation, bon/mauvais exemple pour le premier besoin |
| Comment formuler une itération, comment rédiger un prompt en quatre parties, cinq points pour l'aperçu / six points avant publication / six points pour les données | ./references/06-iteration-and-acceptance.md | Rédaction en quatre parties, ordre officiel de progression, liste de vérification, modes d'échec courants |
| Quels éléments préparer pour la publication, comment fonctionne la version test QR code, comment ouvrir la page de partage | ./references/07-publish-checklist.md | Liste et spécifications des éléments, processus de publication, synchronisation de la version test, actions post-publication |
| Comment gérer les identifiants, quelles actions sont irréversibles, écriture atomique, droits d'auteur des assets, sécurité de la collaboration | ./references/08-safety-and-credentials.md | Temporalité, coûts, identifiants, actions irréversibles, écriture atomique, périmètre et droits d'auteur |
Règle : lire une seule référence, celle qui correspond à la question posée ; répondre après l'avoir lue, ne pas ajouter de détails de mémoire.
Vue d'ensemble des phases (0 à 6)
| Phase | Objectif | Livrable | Porte de confirmation | Outil / Modèle |
|---|---|---|---|---|
| 0 Connexion | Déterminer le mode de création ; en mode local, confirmer MCP, liaison du projet et répertoire existant | Confirmation de connexion + résultat de vérification du répertoire | L'utilisateur confirme le mode et l'environnement | ./scripts/check_project_layout.py |
| 1 Analyse | Extraire structurément les cinq éléments, poser une seule fois les questions manquantes (≤ 4 questions) | Fiche de confirmation de compréhension du cahier des charges | L'utilisateur confirme les cinq éléments un par un avant d'écrire le besoin | ./assets/brief-confirmation-template.md, ./scripts/check_brief.py |
| 2 Premier besoin | Reformuler le premier besoin conforme aux spécifications officielles, ne faire que la boucle centrale jouable minimale | Texte du premier besoin + direction du thème et de l'image | L'utilisateur confirme le besoin et la direction du thème | ./assets/first-prompt-template.md |
| 3 Itération | Version jouable minimale → corrections de blocage → rythme, valeurs, sensations → assets, sons, tutoriel, éléments de publication | Besoin en quatre parties + résultat de validation | Validation du résultat de chaque itération avant de passer à la suivante | ./assets/feedback-four-part-template.md, ./references/06-iteration-and-acceptance.md |
| 4 Aperçu et appareil réel | Vérification en cinq points + QR code de test sur appareil réel | Enregistrement de la vérification, liste des problèmes | Tous les cinq points validés avant la publication | ./references/06-iteration-and-acceptance.md, ./references/07-publish-checklist.md |
| 5 Publication | Vérifier un par un les éléments, version cohérente, puis publier | Liste de vérification des éléments de publication | L'utilisateur confirme que les éléments et la version sont cohérents | ./scripts/check_publish_materials.py, ./assets/stage-report-template.md |
| 6 Transversal | Protection des coûts et de la sécurité, applicable à chaque phase | Avertissements de risque et enregistrement des confirmations | Confirmation à chaque action à haut risque | ./references/02-credits-and-cost.md, ./references/08-safety-and-credentials.md |
Règle de progression : à la fin de chaque phase, donner d'abord un « rapport de phase » → attendre la confirmation explicite de l'utilisateur → passer à la phase suivante.
Phase 0 : Connexion
Poser les trois questions en une fois, sans aller et venir :
- Utilisez-vous l'espace de travail navigateur ou le MCP local (répertoire local + Codex / Cursor / Claude Code) ?
- S'agit-il d'un projet existant ou d'un nouveau projet ? Nom du projet, direction du jeu ?
- Avez-vous des assets ou des répertoires de code existants à réutiliser ?
| Situation | Suggestion |
|---|---|
| Première fois, veut voir l'image le plus vite possible | Espace de travail navigateur |
| A déjà du code ou des assets locaux, veut utiliser le flux de travail Codex / Cursor / Claude Code | MCP local |
| Veut utiliser Git, collaborer à plusieurs, faire des vérifications en local | MCP local |
| Veut juste tester rapidement sur mobile | Espace de travail navigateur + QR code de partage |
Commandes en mode local (à exécuter dans le répertoire cible ; init va récupérer le projet dans le répertoire courant, vérifier d'abord que le répertoire est vide ou que l'utilisateur accepte la fusion) :
npx -y @taptap/maker install --ide codex,cursor,claude # écrit seulement la configuration MCP pour ces trois
npx -y @taptap/maker init # connexion + choix/création de projet + liaison de répertoire + récupération
- Structure typique après initialisation : assets/ (contenant image, sprites, audio, video) et scripts/ ; la structure réelle varie selon le projet.
- Avant de commencer, exécute
python ./scripts/check_project_layout.py <racine du projet>et lis la structure existante ainsi que les explications pour éviter d'écraser des ressources en cours d'utilisation. - Mettre à jour les composants : « Mets à jour le Maker MCP et l'AI DevKit du projet actuel, puis dis-moi la version réellement utilisée » ; utiliser pd/stable en production, rnd/latest pour les tests.
- Les identifiants ne sont stockés que dans un environnement local de confiance, pas dans les fichiers du projet, pas dans Git.
Discussion pour la porte de confirmation 0 : « Je propose de me connecter via le mode X, le répertoire du projet est Y, la structure existante est Z, je n'écraserai pas A. Confirmez pour passer à l'analyse du cahier des charges. »
Phase 1 : Analyse du cahier des charges
Processus :
- Lire entièrement le cahier des charges, extraire directement le tableau des cinq éléments, sans le réciter en entier.
- Pour chaque élément, indiquer : Présent (source dans le texte) / Déduit (à confirmer) / Manquant.
- Poser les questions sur les éléments manquants et les ambiguïtés critiques en une seule fois, ≤ 4 questions, chacune avec 2–3 réponses candidates pour réduire l'effort de réponse.
- Produire une « fiche de confirmation de compréhension du cahier des charges », contenant obligatoirement « Ce que j'ai compris / Ce que je ne suis pas sûr(e) / Ce que je suggère de couper pour la première version ».
- Attendre la confirmation de l'utilisateur avant de passer à la phase 2.
Règles strictes :
- Les paramètres clés (genre, personnage principal, condition de victoire/défaite, contrôles, plateforme cible et direction de l'image) ne doivent pas être inventés ; s'ils manquent, demande-les, ou indique clairement « à déterminer » et donne une suggestion par défaut.
- Les systèmes ultérieurs dans le cahier des charges (évolution, boutique, multijoueur, classement, plusieurs chapitres) doivent être placés dans les « versions futures », pas dans la première version.
- La fiche de confirmation doit clairement indiquer « Ce qui ne sera pas fait dans la première version ».
Tu peux d'abord utiliser un script pour vérifier si les cinq éléments sont complets (la structure JSON est décrite en en-tête du script) :
python ./scripts/check_brief.py brief.json
Phase 2 : Génération du premier besoin
Ordre de rédaction du premier besoin : Description en une phrase → Cinq éléments → Contrôles et conditions de victoire/défaite → Liste des écrans → Hors périmètre.
- Un besoin ne doit résoudre qu'un seul résultat ; commence par la boucle centrale jouable minimale.
- Indiquer clairement « ce qui ne sera pas fait dans cette itération » permet de mieux délimiter le périmètre que de lister plein de fonctionnalités.
- Confirmer en même temps : le thème UI (Astroon / BrawlForge / PixelForge), l'orientation de l'image (paysage / portrait), la perspective (2D / 3D), le ton artistique.
- Modèle : ./assets/first-prompt-template.md ; bon/mauvais exemple dans ./references/05-brief-parsing-and-first-prompt.md.
Discussion pour la confirmation du thème et de la direction : « Je suggère le thème A (raison : adapté à la catégorie), portrait 2D ; si tu préfères le B, je modifie selon B. Confirme pour que je publie le premier besoin. »
Phase 3 : Itération
Ordre officiel de progression (ne pas sauter) :
- Version jouable minimale (pouvoir démarrer, jouer, terminer, recommencer)
- Corriger les problèmes de blocage (plantages, boutons inaccessibles, état non réinitialisé)
- Ajuster le rythme, les valeurs, les sensations
- Ajouter des assets, des sons, des tutoriels, des éléments de publication
Chaque itération utilise un prompt en quatre parties : Objectif / État actuel / Contraintes / Validation (modèle ./assets/feedback-four-part-template.md).
- Ne cibler qu'un seul résultat à la fois ; ne pas mélanger « ajouter des sons + modifier des valeurs + changer le thème » dans le même prompt.
- Les « contraintes » doivent mentionner ce qui doit être conservé (contrôles existants, thème déjà confirmé, modules à ne pas refactoriser).
- La « validation » doit être rédigée comme un phénomène observable, pas comme « rendre le jeu plus amusant ».
- Demander à l'IA de construire elle-même, vérifier les erreurs et expliquer le résultat de la validation ; pour les modifications complexes, demande-lui d'abord un court plan.
- Garder le même objectif dans la même conversation ; pour changer de direction, démarrer une nouvelle conversation.
En cas de rapport de bug, donner les cinq informations complètes : appareil / page, étapes, comportement réel, comportement attendu, reproductible ou non (avec capture d'écran ou vidéo si possible).
Phase 4 : Aperçu et appareil réel
Vérification en cinq points (liste officielle, noter la conclusion pour chaque point) :
- Peut-on démarrer normalement ?
- Les contrôles correspondent-ils aux attentes (zones tactiles, boutons cliquables) ?
- Le succès / l'échec / la reprise sont-ils complets ?
- L'image est-elle nette sur l'appareil cible (taille de police, contraste, zone de sécurité) ?
- Y a-t-il des problèmes bloquant le déroulement du jeu ?
Appareil et partage :
- L'aperçu de bureau permet de basculer entre PC / téléphone / tablette et résolutions (y compris le masque Dynamic Island de l'iPhone 17, qui bloque les clics dans cette zone).
- Appareil réel : dans la barre d'outils d'aperçu, « Partager » → lien / QR code ; avant de créer une page de partage, sélectionner l'éditeur de publication ayant terminé la certification développeur dans le panneau de publication.
- QR code de test sur appareil réel : « Scanner sur téléphone pour tester » → « Mettre à jour la version test » → scanner ; après avoir modifié le code / l'orientation / la configuration / les assets, il faut remettre à jour, sinon le scan renverra vers l'ancienne version.
- Le passage du paysage au portrait (ou vice versa) doit obligatoirement faire modifier par l'IA à la fois la disposition de l'interface et la configuration d'orientation du projet ; après la modification, reconstruire et vérifier en aperçu / sur appareil réel les boutons, le texte et les zones tactiles.
Si la vérification échoue, retourner en phase 3 pour écrire un besoin en quatre parties, ne pas sauter à la publication.
Phase 5 : Préparation à la publication
Liste des éléments (vérifier un par un) :
- Icône du jeu
- Au moins 3 captures d'écran du jeu
- Image promotionnelle, couverture horizontale, couverture verticale
- Pour un jeu en portrait, image promotionnelle carrée supplémentaire
- Nom du jeu
- Description du jeu ≥ 10 caractères
- « Message du développeur » ≥ 10 caractères
- Vidéo de test sur appareil réel requise pour la première publication officielle
Processus : génération des éléments (consomme des crédits, nécessite l'accord explicite de l'utilisateur) → vérification dans le panneau de publication → mise à jour de la version test et re-vérification par scan → publication officielle.
- En cas de plusieurs éditeurs de publication, sélectionner d'abord l'éditeur ; le bouton de publication n'est disponible qu'après la génération des éléments.
- Les opérations sur le panneau de publication ne consomment pas de crédits de création.
- Vérification de santé pré-publication dans ./references/06-iteration-and-acceptance.md (6 points avant publication, 6 points de vérification des données).
- Commande de vérification :
python ./scripts/check_publish_materials.py materials.json --root <racine du projet>.
Phase 6 (transversale) : Protection des coûts et de la sécurité
À exécuter à chaque phase :
- Crédits : sans demande explicite de l'utilisateur dans la conversation, n'utilise pas d'outils de génération consommant des crédits ; avant une forte consommation, explique « ce qui sera dépensé, combien environ, peut-on faire moins cher » ; ne change pas automatiquement de modèle ou de canal.
- Résultat inconnu, ne pas renvoyer : après soumission sans résultat clair → marquer comme « uncertain », d'abord vérifier l'état ; si un renvoi est vraiment nécessaire, faire confirmer par l'utilisateur et l'informer qu'il peut déjà y avoir eu un débit.
- Identifiants : ne pas les afficher, ne pas les écrire, ne pas les inclure dans les fichiers du projet ou dans Git ; ne les autoriser qu'au client de confiance.
- Actions irréversibles : suppression ou remplacement d'assets, changement de modèle, basculement de canal, vidage de configuration, publication officielle — d'abord s'arrêter, expliquer les conséquences et les moyens d'annulation, puis obtenir un « oui » explicite avant d'agir.
- Périmètre : ne construire que dans le cadre du cahier des charges ; pour l'ajout de nouveaux systèmes ou mécanismes, demander d'abord l'autorisation ; ne pas déplacer, supprimer ou remplacer les fichiers de l'utilisateur sans autorisation.
- Écriture atomique (lorsque le script ou l'outil écrit un fichier) : fichier temporaire + renommage ; ne pas écraser une valeur existante par une valeur nulle ; en cas de fichier corrompu, enregistrer une copie sur place.
Détails dans ./references/08-safety-and-credentials.md et ./references/02-credits-and-cost.md.
Rapports de phase
Avant chaque passage à la phase suivante, utiliser ./assets/stage-report-template.md pour produire quatre blocs : ce qui a été fait dans cette phase / livrables / résultat de la validation / prochaine étape et points nécessitant ta confirmation. La fin du rapport doit obligatoirement être une demande de confirmation formulée comme une question.
Maintenance et actualité
- Date de mise à jour des connaissances de ce skill : 2026-11-03. Le produit évolue vite, pour toute question concernant les fonctionnalités, paramètres, modèles, prix, limites, se référer à la documentation en ligne.
- Gestion des conflits : documentation en ligne > ce skill. En cas d'incohérence, suivre la documentation en ligne et expliquer la différence dans la réponse.
- Rafraîchissement : lire d'abord https://maker.taptap.cn/llms.txt pour trouver la page correspondante ; si le texte original est nécessaire, extraire le
.mdcorrespondant en texte brut. - Interdiction d'inventer : pour toute fonctionnalité, paramètre, nom de modèle, prix, limite non présents dans la documentation, répondre « La documentation ne le mentionne pas, je vais vérifier ou merci de te référer à la page ».
Exemples de prompts
- « Je veux faire un jeu d'évitement 2D en portrait, d'abord aide-moi à voir comment m'y prendre. » → Phase 0 / 1.
- « Voici mon cahier des charges (fichier joint), aide-moi à le construire. » → Phase 0 puis confirmation à chaque phase.
- « Comment les crédits Maker sont-ils déduits ? Combien coûte la génération d'une image ? » → Lire seulement references/02, répondre directement, sans entrer dans le workflow.
- « La différence entre 60 % et 63 % de taux de réussite L2 dans le classement est-elle grande ? » → Lire seulement references/04, parler de l'intervalle de confiance et de la plage de rangs.
- « Avec le thème Astroon, fais l'écran de démarrage, ne touche pas au gameplay. » → Phase 3, écrire un besoin en quatre parties.