Pure-Water-Automations/agent-skills

Refonte concurrentielle

Si un fichier LOCAL.md se trouve à côté de ce fichier SKILL.md, lisez-le en premier — il contient les spécificités de cet espace de travail (chemins, outils, exemples) et remplace les valeurs par défaut génériques ci-dessous.

Recherche → décision → conception. Des sous-agents parallèles capturent NOTRE fonctionnalité et 2-3 produits concurrents. Les résultats deviennent une analyse des écarts avec des décisions groupées pour l'utilisateur, et la direction choisie devient un canevas de conception : captures d'écran de l'UI actuelle à côté des maquettes de refonte avec chaque différence marquée. Le résultat est une décision + une conception (+ éventuellement un plan d'implémentation) — aucun code produit n'est écrit par cette compétence.

L'« exécution de référence » mentionnée ci-dessous est la première exécution réelle de cette compétence (une refonte de bibliothèque d'enregistrements) ; LOCAL.md, lorsqu'il est présent, y fait référence. Il s'agit simplement d'un exemple concret — il prouve la forme et calibre la profondeur ; ne le consultez pas pour le contenu d'une nouvelle fonctionnalité.

Phase 1 — Recherche parallèle (sous-agents à modèle économique, 3 maximum à la fois)

Lancez jusqu'à 3 sous-agents en un seul message — outil Agent, general-purpose, model: "sonnet" (un modèle moins cher est suffisant pour la recherche basique ; jamais plus de 3 simultanément — les limites de débit tuent les rafales de lancement) :

1. Notre — capturez la fonctionnalité sur NOTRE application.
2. • 3. Concurrents — les produits que l'utilisateur a NOMMÉS remplissent d'abord ces emplacements, un agent chacun. Les emplacements restants (l'utilisateur en a nommé zéro ou un) : un agent « enquête » qui sélectionne les 2-3 concurrents dont la documentation publique pour la zone fonctionnelle concernée est la plus riche. Utilisateur en a nommé 3+ : attribuez à un agent le concurrent principal, à un agent le reste en lot.

Pendant leur exécution, ancrez-vous dans notre base de code sur le thread principal : le schéma de la fonctionnalité, la couche de lecture/action, et les pages. Les recommandations doivent correspondre à des champs réels (« le tag project existe, l'UI ne l'expose jamais ») — une recherche concurrentielle sans ancrage dans le code produit une liste de souhaits que personne ne peut construire.

Instructions pour les sous-agents — les parties qui échouent lorsqu'elles sont omises :

• Playwright MCP uniquement, jamais le panneau Navigateur — les captures d'écran du panneau Navigateur ne peuvent pas être sauvegardées sur le disque et sont invisibles pour l'orchestrateur. Dites explicitement à l'agent : mcp__playwright__playwright_screenshot avec savePng: true + downloadsDir défini sur un sous-répertoire de travail par agent (ours/, loom/, competitors/), faites mkdir -p d'abord, et rapportez les chemins absolus vérifiés avec ls.
• Les agents simultanés partagent un seul navigateur Playwright et VONT se contaminer mutuellement (un agent capture la page d'un autre agent — cela s'est produit lors de l'exécution de référence). Briefez chaque agent : vérifiez visuellement que chaque capture d'écran correspond à l'URL sur laquelle il vient de naviguer avant de la conserver ; en cas de capture obsolète/étrangère, fermez le navigateur Playwright, rouvrez-le, reprenez la capture.
• Chromium Playwright peut être manquant ("Exécutable n'existe pas …") : npx playwright install chromium depuis le répertoire cache de npx du MCP, puis continuez (problème permanent, survit aux changements de version).
• Connexion à notre application : donnez à l'agent la recette exacte — par exemple un formulaire de connexion réservé aux développeurs (email + mot de passe sur /login) avec un email qui EXISTE EN TANT QU'UTILISATEUR ACTIF dans la base de données de développement, plus le mot de passe de connexion de développement depuis l'environnement du serveur de développement. Vérifiez les deux vous-même (lisez la valeur d'environnement sur le serveur de développement, interrogez la BD de développement pour les utilisateurs actifs) avant de lancer l'agent. L'exécution de référence a consumé un agent complet sur CredentialsSignin à cause d'un email qui n'était pas dans la BD de développement. Trouvez le chemin d'authentification de développement de l'application dans son AGENTS.md / README. Ne dirigez jamais les agents vers la production.
• Les bibliothèques concurrentes se trouvent derrière une connexion — demandez aux agents d'utiliser les articles du centre d'aide, les pages marketing/fonctionnalités et la documentation (support.loom.com etc.), sans tenter d'inscriptions. Demandez un inventaire structuré des fonctionnalités (organisation, découverte/recherche, partage, flux de travail, IA, administration) + les fonctionnalités principales/appréciées par rapport à celles réservées aux entreprises + une liste des « idées distinctives qui méritent d'être volées ».

Phase 2 — Synthèse + décisions groupées

Compilez UN SEUL message pour l'utilisateur :

1. État actuel — ce que notre fonctionnalité possède et ce qui lui manque, vérifié à la fois par les captures d'écran et par le code (citez les fichiers).
2. Ce que font les concurrents — quelques lignes par produit, uniquement les éléments transférables.
3. Recommandations par phases — le meilleur rapport effort/bénéfice d'abord : (a) exposer ce que le code prend déjà en charge, (b) fonctionnalités d'organisation à faible migration, (c) fonctionnalités de flux de travail. Incluez les idées originales de l'utilisateur issues de l'invite. Marquez ce qui est délibérément ignoré (adapté aux entreprises, YAGNI).
4. Décisions à choix multiples groupées : les 2 à 4 bifurcations qui modifient le livrable, options lettrées + une recommandation pour chacune. Ne posez pas les questions une par une.

Arrêtez-vous et attendez les décisions. Ne commencez pas à concevoir un périmètre non décidé.

Phase 3 — Canevas de conception de la direction choisie

SOUS-COMPÉTENCE REQUISE : la compétence design (Canevas de conception Claude → Artefact). Elle gère les mécanismes du canevas ; cette phase ajoute les conventions de comparaison :

• Captures d'écran de l'UI actuelle en tant que planches de travail distinctes (« Actuel — X ») à côté des planches de travail de la refonte (« Refonte — X »). Réduisez la résolution des captures d'écran à environ 70-100 Ko JPEG (sips -Z 900 -s format jpeg -s formatOptions 60 …) avant de les intégrer.
• Les planches de travail de la refonte correspondent au système de design réel de l'application — lisez d'abord les fichiers de tokens et les composants, copiez les valeurs exactes (polices, tokens de couleur, rayon des cartes, forme des boutons).
• Marquez chaque différence : contour en pointillé dans la couleur d'accentuation de l'application + petite étiquette « NOUVEAU » sur chaque élément qui n'existe pas aujourd'hui (variante d'étiquette « MODIFIÉ » pour ceux qui ont été modifiés). Les zones inchangées ne reçoivent aucune décoration — l'absence rend les marqueurs lisibles.
• Les notes autocollantes du canevas résument les différences par planche de travail + une note d'ensemble. Les données d'exemple dans les maquettes sont acceptables ; mentionnez-le lors de la remise.
• Les maquettes statiques sont le livrable par défaut ; ne construisez un prototype cliquable que si l'utilisateur l'a demandé.

Phase 4 (uniquement si l'utilisateur le demande) — Plan d'implémentation

SOUS-COMPÉTENCE REQUISE : superpouvoirs:écriture-de-plans. Ancrez chaque tâche dans la lecture du code de la Phase 1 ; reprenez textuellement le périmètre phasé et les décisions ; terminez par les options d'exécution (déploiement parallèle / sous-agent / en ligne), ne commencez pas à construire sans y être invité.

Problèmes connus (tous ont affecté l'exécution de référence)

Symptôme	Correctif
L'agent rapporte des captures d'écran mais l'orchestrateur ne peut pas les voir	Le panneau Navigateur a été utilisé — rappelez : Playwright MCP savePng + downloadsDir
La capture d'écran montre un site différent de celui sur lequel l'agent a navigué	Contamination de session Playwright partagée — fermez le navigateur, rouvrez-le, reprenez la capture, vérifiez visuellement
CredentialsSignin lors de la connexion de développement	L'email n'est pas un utilisateur actif dans la BD de développement — interrogez la BD de développement, utilisez-en un qui l'est
« Exécutable n'existe pas … chromium »	npx playwright install chromium (par répertoire cache, réexécutez après les mises à jour de Playwright)
Le déploiement parallèle retourne un résultat vide / limité par le débit	>3 agents simultanés — vagues de ≤3, réessayez les branches mortes, signalez partiellement les résultats
Les recommandations ne correspondent pas au code	L'ancrage dans le code du thread principal de la Phase 1 a été sauté — faites-le avant de synthétiser