Communitygithub.com

deputychinh/frontend

À utiliser pour ajouter ou modifier tout écran, composant, composable (ou hook), store, formulaire, route ou appel de données visibles par l'utilisateur dans une application web Vue 3 ou React — même pour une petite modification ou lorsque la demande mentionne simplement « UI », « page », « formulaire », « frontend » ou « le bouton ne fait rien ».

Qu'est-ce que frontend ?

Cette compétence (skill) guide un agent AI pour réaliser du développement frontend dans une application web moderne basée sur Vue 3 ou React. Elle est conçue pour garantir que chaque écran fonctionne pour chaque utilisateur, dans chaque état (chargement, vide, erreur, succès), tout en restant facile à modifier. L'agent suit un workflow structuré en 11 étapes, allant du chargement des conventions du dépôt à la remise finale après vérification. La compétence impose des pratiques rigoureuses comme l'écriture de tests unitaires avant le code, l'utilisation d'un tableau d'état pour chaque vue, le respect des règles d'accessibilité (WCAG, ARIA), et l'utilisation de Playwright pour des tests de bout en bout avec vérification d'accessibilité via axe-core. Elle fournit également une checklist de base avec 16 règles essentielles et liste les anti-patrons à éviter, spécifiques à Vue (watchers inutiles, perte de réactivité) et React (effets remplaçables par un calcul, non-respect des règles des hooks), ainsi que des anti-patrons communs aux deux frameworks. Les références incluent des documents spécialisés pour les patrons Vue, React et l'accessibilité/test.

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/deputychinh/Skills/tree/HEAD/skills/frontend
Voir l'original→Voir toutes les compétences

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentation

frontend — des écrans qui fonctionnent pour chaque utilisateur, chaque état, et restent faciles à modifier

Suivez d'abord le CLAUDE.md du dépôt, docs/conventions.md et docs/design-system.md ; cette compétence comble les lacunes et ne les remplace jamais. Le travail visuel (tokens, mise en page, couleur, CSS) relève de css-design ; lancer l'application comme le fera l'utilisateur et le verdict final relèvent de verify-app.

Choisir la pile. Vue 3 et React sont tous deux de première classe et suivent les mêmes règles. Utilisez le framework que le dépôt utilise déjà ; pour une nouvelle application, utilisez le frontend par défaut du profil de livraison (voir le README du dépôt), sinon demandez une fois lors du tri. Vue : TypeScript + Vite (npm create vue@latest -- --ts --router --pinia --vitest --playwright --eslint --prettier) avec references/vue-patterns.md. React : TypeScript + Vite (ou le méta-framework du dépôt) avec references/react-patterns.md. Ne mélangez jamais les frameworks dans une même application. Besoin de SSR ou SSG pour le SEO ? Enregistrez Nuxt ou Next.js dans un ADR (architect) ; cette compétence couvre de toute façon les parties client.

Workflow

  1. Charger les conventions et l'inventaire du dépôt. Lisez CLAUDE.md, docs/conventions.md, docs/design-system.md ; listez les parties réutilisables (ls src/components src/features src/composables src/hooks src/stores). Détectez la couche de données, le routeur, les bibliothèques de formulaires et d'i18n (Vue : grep -E '"(@tanstack/vue-query|pinia|vue-router|vee-validate|vue-i18n)"' package.json ; React : grep -E '"(@tanstack/react-query|@tanstack/react-router|react-router|react-hook-form|i18next|react-intl)"' package.json). N'ajoutez jamais une deuxième couche de données, routeur, store, formulaire ou bibliothèque d'i18n. Preuve : les notes de l'histoire listent les composants et composables/hooks réutilisés et tout nouveau, avec la raison.
  2. Écrire le tableau d'état avant le code. Pour chaque vue : chaque donnée et où elle vit — serveur (query), URL (paramètres de route / recherche), client partagé (store Pinia, ou contexte React ou store du dépôt), local (ref / useState), dérivée (computed / une const dans le rendu), externe (un composable ou useSyncExternalStore encapsulant l'API du navigateur). Listez ensuite les quatre états (chargement, vide, erreur, succès) et les clés de copie pour chacun. Preuve : le tableau dans l'histoire.
  3. Écrire d'abord les tests qui échouent. Vitest + @testing-library/vue ou @testing-library/react, userEvent.setup(), requêtes par rôle et nom accessible, un comportement par test, réseau simulé à la limite du service (MSW ou le client factice du dépôt dans src/test-utils). Couvrez chaque état, le chemin clavier et un cas négatif. Preuve : l'exécution montre du rouge pour la bonne raison.
  4. Construire dans le dossier de fonctionnalité. src/features/<name>/services (appels API typés, pas de framework) → composables / hooks (useX encapsulant useQuery/useMutation et une fabrique de clés) → components (Name.vue avec `<script setup lang=

Skills associés

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community