uizze/uizze

Empêchez les agents de code IA de générer des interfaces génériques.

Arrêtez de faire de la soupe d'interface

Construisez des interfaces spécifiques à votre produit avec plus de 800 000 écrans réels web et iOS via UIZZE.

Vue d'ensemble

Utilisez le brief produit, l'interface existante, les composants et le système de design local pour créer des interfaces intentionnelles. Uizze fournit des conseils de conception ciblés et, lorsque c'est utile, un petit nombre de références visuelles pertinentes.

Prérequis

• Un écran ou un composant à construire, refondre ou revoir — un chemin de fichier ou une courte description.
• Les composants, tokens de design et langage visuel existants du produit, de sorte que la construction les étende plutôt que d'inventer un nouveau système.
• Accès optionnel au MCP payant Uizze pour des références ciblées et des matériaux hébergés.

Authentification

• Le skill gratuit et le catalogue public fonctionnent sans compte, token, connexion MCP, dépendance, script ou exécutable.
• Le MCP UIZZE complet optionnel peut utiliser le flux de connexion et d'authentification normal de l'hôte. Ne prétendez jamais qu'il est connecté sans un résultat réel de l'hôte.

Travaillez à partir du produit

Lisez le brief, l'interface existante, les composants, les tokens, les assets et tout fichier PRODUCT.md ou DESIGN.md avant de concevoir. La demande de l'utilisateur et les contraintes du projet priment sur ce skill. Préservez un système visuel établi pour les extensions et le polissage ; remplacez-le uniquement pour une refonte approuvée. Un nouveau projet n'exige pas ces fichiers.

Identifiez le public, la tâche principale, les états importants et le résultat attendu. Ne posez des questions que sur les choix manquants qui modifieraient matériellement le travail. Une demande précise suffit pour avancer ; ne transformez pas une petite correction en atelier de découverte.

Sélectionnez le workflow

Chargez le playbook pour l'action demandée, ainsi que les conseils de plateforme et de savoir-faire nécessaires à son exécution :

• Nouvelle interface ou refonte majeure : new-work
• Travail sur un produit ou un tableau de bord : operate
• Raffinement et polissage : polish
• Simplification : distill
• Audit explicite : audit, en lecture seule sauf si des corrections ont été demandées
• iOS natif : iOS, en parallèle du playbook de l'action
• /overdrive explicite, « Uizze Overdrive » ou une demande de travail d'interaction exceptionnel : Overdrive

Pour l'implémentation, utilisez craft une fois la direction établie. Ne chargez que les fichiers pertinents ; plusieurs playbooks complémentaires sont autorisés. Overdrive est un opt-in, pas le défaut pour le travail d'interface ordinaire. Il nécessite une direction choisie avant l'implémentation.

« Utilisez Uizze Overdrive sur cet écran » fonctionne via ce routeur ; une commande native en slash dépend de l'hôte. Ce sont des playbooks Markdown autonomes, pas un installeur, un service d'arrière-plan ou un moteur exécutable.

Preuve Uizze optionnelle

Lisez la politique de référence avant d'utiliser find_ui_references ou find_ui_materials. Inspectez les preuves visuelles pertinentes lorsqu'elles peuvent éclairer la mise en page, l'état, l'interaction ou les assets. Utilisez les outils disponibles de l'hôte, pas des appels ou connexions inventés. La récupération payante est optionnelle ; un accès manquant ne bloque pas le travail de design local.

Distinguez une référence exacte, un exemple connexe, aucune correspondance et une erreur de service. Mentionnez brièvement une limitation qui a affecté le résultat. Ne prétendez jamais qu'une image a été inspectée ou qu'un état a été trouvé sans preuve.

Fin

Construisez le périmètre demandé et exercez ses états importants. Rendez et inspectez le résultat réel à des tailles représentatives de bureau/mobile ou des classes d'appareils natives, y compris la taille défaillante signalée par l'utilisateur. Comparez-le avec la direction choisie ou la référence fournie, pas seulement avec l'absence d'erreurs d'exécution.

Corrigez les problèmes matériels par lot, puis rendez et inspectez à nouveau. Arrêtez une fois que le résultat demandé est vérifié ; n'inventez pas continuellement du travail. Si une passe limitée ne peut pas résoudre un problème, signalez-le au lieu de prétendre avoir réussi. Lorsque le rendu n'est pas disponible, distinguez les vérifications de code de la vérification visuelle.

Gardez le compte rendu concis : ce qui a changé, ce qui a été réellement testé et toute limitation restante. Un skill n'autorise pas la publication, les achats, les nouvelles dépendances, les modifications de compte ou les actions destructrices.