Skills Revue de code

Auditer et améliorer l'accessibilité web selon les directives WCAG 2.2. Utiliser lorsqu'on demande "améliorer l'accessibilité", "audit a11y", "conformité WCAG", "support lecteur d'écran", "navigation clavier" ou "rendre accessible".

Compétence en lecture seule Rigor Analyze / Rigor Audit pour les dépôts de recherche en deep learning. À utiliser lorsque l'utilisateur souhaite lire et comprendre un dépôt, inspecter la structure du modèle et les points d'entrée d'entraînement ou d'inférence, examiner les configurations et les points d'insertion, ou signaler des schémas d'implémentation suspects sans modifier le code ni exécuter de tâches lourdes. Ne pas utiliser pour l'exécution active de commandes, le refactoring large, l'adaptation spéculative de code ou la correction automatique de bugs.

Génère du code Angular et fournit des conseils architecturaux. Déclenchez lors de la création de projets, composants ou services, ou pour les bonnes pratiques en matière de réactivité (signals, linkedSignal, resource), formulaires, injection de dépendances, routage, SSR, accessibilité (ARIA), animations, styles (styles de composants, Tailwind CSS), tests ou outils CLI.

Appliquer les bonnes pratiques modernes de développement web pour la sécurité, la compatibilité et la qualité du code. Utiliser lorsqu'on demande "appliquer les bonnes pratiques", "audit de sécurité", "moderniser le code", "revue de qualité du code" ou "vérifier les vulnérabilités".

Decision guide for delegating to caveman-style subagents. Tells the main thread WHEN to spawn `cavecrew-investigator` (locate code), `cavecrew-builder` (1-2 file edit), or `cavecrew-reviewer` (diff review) instead of doing the work inline or using vanilla `Explore`. Subagent output is caveman-compressed so the tool-result injected back into main context is ~60% smaller — main context lasts longer across long sessions. Trigger: "delegate to subagent", "use cavecrew", "spawn...

Générateur de messages de commit ultra-compressés. Réduit le bruit dans les messages de commit tout en préservant l'intention et le raisonnement. Format Conventional Commits. Sujet ≤50 caractères, corps uniquement lorsque le "pourquoi" n'est pas évident. Utiliser lorsque l'utilisateur dit "écrire un commit", "message de commit", "générer un commit", "/commit", ou invoque /caveman-commit. Déclenchement automatique lors du staging des modifications.

Commentaires de revue de code ultra-compressés. Réduit le bruit des retours de PR tout en préservant le signal actionnable. Chaque commentaire tient sur une ligne : emplacement, problème, correction. Utilisé lorsque l'utilisateur dit "review this PR", "code review", "review the diff", "/review", ou invoque /caveman-review. Déclenchement automatique lors de la revue de pull requests.

Examine les diffs de code, les PR, les files d’attente d’issues, la préparation des releases, les commits, les pushes, la publication et les audits de projet. À utiliser lorsque les utilisateurs demandent une revue/看看代码/合并前/看看issue/PR/release/push ou pour implémenter un plan approuvé, avec des barrières de sécurité pour les worktrees sales et non suivis. Pas pour explorer des idées, déboguer des causes racines ou faire une revue de prose.

Comparez l'implémentation d'une pull request avec le contexte de spécification dans spec_context.md et alimentez toute divergence matérielle dans review.json. À utiliser lors de la revue de PR lorsque celle-ci est approuvée ou que le contexte de spécification du dépôt est disponible.

Examinez les modifications depuis un point fixe (commit, branche, tag ou merge-base) selon deux axes — Standards (le code respecte-t-il les normes de codage documentées de ce dépôt ?) et Spécifications (le code correspond-il à ce que demandait le problème/PRD d'origine ?). Exécute les deux examens dans des sous-agents parallèles et les rapporte côte à côte. À utiliser lorsque l'utilisateur souhaite examiner une branche, une PR, des modifications en cours, ou demande de « vérifier depuis X ».

Effectue une revue de code multi-axe. À utiliser avant de fusionner toute modification. À utiliser lors de la révision de code écrit par vous-même, un autre agent ou un humain. À utiliser lorsque vous devez évaluer la qualité du code sur plusieurs dimensions avant qu'il n'entre dans la branche principale.

Simplifie le code pour plus de clarté. À utiliser lors du refactoring de code pour plus de clarté sans changer le comportement. À utiliser lorsque le code fonctionne mais est plus difficile à lire, maintenir ou étendre qu'il ne devrait l'être. À utiliser lors de la révision de code qui a accumulé une complexité inutile.

Vocabulaire partagé pour concevoir des modules profonds. À utiliser lorsque l'utilisateur souhaite concevoir ou améliorer l'interface d'un module, trouver des opportunités d'approfondissement, décider où placer une jointure, rendre le code plus testable ou navigable par IA, ou lorsqu'une autre compétence a besoin du vocabulaire des modules profonds.

Normes de dénomination des branches, des worktrees et des messages de commit Conventional Commits v1.0.0 pour les projets GitHub et GitLab. Utiliser lors de la création de branches, du nommage des worktrees, de la rédaction de commits, de la génération de messages de commit, de la révision des conventions de branches ou de la mise en place d'automatisation de changelog. Appliquer lorsque votre projet nécessite un historique git cohérent, des versions basées sur SemVer, une génération de changelog analysable ou la fermeture automatique d'issues. Déclencher lorsque l'utilisateur demande comment nommer un worktree, créer un git worktree, ou...

Cré

Guide le débogage systématique des causes profondes. À utiliser lorsque des tests échouent, des builds se cassent, le comportement ne correspond pas aux attentes, ou que vous rencontrez une erreur inattendue. À utiliser lorsque vous avez besoin d'une approche systématique pour trouver et corriger la cause profonde plutôt que de deviner.

Gère la dépréciation et la migration. À utiliser lors de la suppression d'anciens systèmes, API ou fonctionnalités. À utiliser lors de la migration d'utilisateurs d'une implémentation à une autre. À utiliser pour décider s'il faut maintenir ou abandonner du code existant.

Boucle de diagnostic disciplinée pour les bugs complexes et les régressions de performance. Reproduire → minimiser → émettre une hypothèse → instrumenter → corriger → tester la régression. À utiliser lorsque l'utilisateur dit « diagnostique ceci » / « débogue ceci », signale un bug, dit que quelque chose est cassé/renvoie une erreur/échoue, ou décrit une régression de performance.

Boucle de diagnostic pour les bugs complexes et les régressions de performance. À utiliser lorsque l'utilisateur dit « diagnostique »/« débogue ceci », ou signale quelque chose de cassé/qui génère une erreur/qui échoue/lent.

Utilisez lorsque vous avez un plan d'implémentation écrit à exécuter dans une session séparée avec des points de contrôle de révision.

We need to translate the given text from English to French, preserving the name "explore-code" if it appears. The text is a description of an agent skill. The instruction says: "Translate only the text inside <text>. Do not include the name unless it appears in the source text." The name "explore-code" does not appear in the source text. So we just translate the text. Also preserve product names, protocol names, URLs, numbers, technical terms. The text has terms like "LoRA", "adapter layers", "backbone", "head", "rollback-aware records", "explore_outputs/", "current_research". These should be kept as is or translated if appropriate? The instruction says "preserve product names, protocol names, URLs, numbers, and technical terms." "LoRA" is a technical term (Low-Rank Adaptation), likely keep as is. "adapter layers" might be translated? But it's a technical term, so keep as "adapter layers" or maybe "couches d'adaptation"?

Guide le développement de serveurs backend Fastify Node.js et d'API REST en utilisant TypeScript ou JavaScript. À utiliser lors de la construction, configuration ou débogage d'une application Fastify — y compris la définition de routes, l'implémentation de plugins, la mise en place de la validation JSON Schema, la gestion des erreurs, l'optimisation des performances, la gestion de l'authentification, la configuration de CORS et des en-têtes de sécurité, l'intégration de bases de données, le travail avec WebSockets, et le déploiement en production. Couvre l'ensemble du cycle de vie des requêtes Fastify (hooks,...

Utiliser lorsque l'implémentation est terminée, tous les tests passent et que vous devez décider comment intégrer le travail - guide l'achèvement du travail de développement en présentant des options structurées pour la fusion, la PR ou le nettoyage.

Corriger les erreurs de compilation, les problèmes de linting et les échecs de tests dans la base de code Rust warp. Couvre les vérifications de présoumission, les erreurs spécifiques à WASM et l'exécution de tests spécifiques. À utiliser lorsque l'utilisateur rencontre des erreurs de build, des échecs de clippy ou fmt, des échecs de tests, ou a besoin d'exécuter ou d'interpréter la présoumission avant une PR.

Remplace le comportement par défaut de troncature du LLM. Impose une génération complète de code, interdit les motifs de substitution et gère proprement les divisions liées à la limite de tokens. À appliquer à toute tâche nécessitant une sortie exhaustive et non abrégée.

Structure les pratiques de workflow git. À utiliser lors de toute modification de code. À utiliser lors des commits, du branching, de la résolution de conflits, ou lorsque vous devez organiser le travail sur plusieurs flux parallèles. À utiliser lors de la préparation d'une release, du choix d'un incrément de version sémantique, du tagging, ou de la rédaction d'un changelog.

Analyse comparative, profilage et mesure de performance en Golang. À utiliser lors de l'écriture, de l'exécution ou de la comparaison de benchmarks Go, du profilage des chemins critiques avec pprof, de l'interprétation des profils CPU/mémoire/trace, de l'analyse des résultats avec benchstat, de la mise en place de la détection de régression de performance dans l'intégration continue, ou de l'investigation des performances en production avec les métriques d'exécution Prometheus. À utiliser également lorsque le développeur a besoin d'une analyse approfondie sur un indicateur de performance spécifique - cette compétence fournit la méthodologie de mesure, tandis que...

Golang code style conventions — line length and breaking, variable declarations, control flow clarity, when comments help vs hurt. Use when writing or reviewing Go code, asking about style or clarity, or establishing project coding standards. Not for naming conventions (→ See `samber/cc-skills-golang@golang-naming` skill), linter configuration (→ See `samber/cc-skills-golang@golang-lint` skill), or doc comments (→ See `samber/cc-skills-golang@golang-documentation` skill).

Modèles de concurrence en Golang. À utiliser lors de l'écriture ou de la révision de code Go concurrent impliquant des goroutines, canaux, select, verrous, primitives sync, errgroup, singleflight, pools de workers, ou pipelines fan-out/fan-in. Se déclenche également en cas de détection de fuites de goroutines, conditions de course, problèmes de propriété de canaux, ou besoin de choisir entre canaux et mutex.

Guide complet pour l'injection de dépendances (DI) en Golang. Couvre pourquoi la DI est importante (testabilité, couplage lâche, séparation des préoccupations, gestion du cycle de vie), l'injection manuelle par constructeur, et la comparaison des bibliothèques DI (google/wire, uber-go/dig, uber-go/fx, samber/do). Utilisez cette compétence lors de la conception d'architecture de services, de la mise en place d'injection de dépendances, du refactoring de code fortement couplé, de la gestion de singletons ou de fabriques de services, ou lorsque l'utilisateur pose des questions sur l'inversion de contrôle, les services...

Modèles de conception idiomatiques en Golang — options fonctionnelles, constructeurs, flux et cascade d'erreurs, gestion des ressources et cycle de vie, arrêt gracieux, résilience, architecture, injection de dépendances, traitement des données, streaming, et plus. À appliquer lors du choix explicite entre des modèles architecturaux, de l'implémentation d'options fonctionnelles, de la conception d'API de constructeurs, de la mise en place d'un arrêt gracieux, de l'application de modèles de résilience, ou pour demander quel modèle Go idiomatique correspond à un problème spécifique.

Guide de documentation complet pour les projets Golang, couvrant les commentaires godoc, README, CONTRIBUTING, CHANGELOG, Go Playground, les tests d'exemple, la documentation API et llms.txt. À utiliser lors de la rédaction ou de la révision de commentaires de documentation, de l'ajout d'exemples de code, de la mise en place de sites de documentation ou de discussions sur les bonnes pratiques documentaires. Déclencheurs pour les bibliothèques et les applications/CLI.

We need to translate the given text from English to French. The text is about Golang error handling. We must preserve product names, protocol names, URLs, numbers, technical terms. The name "golang-error-handling" is not in the text, so we don't include it. The text includes "samber/oops", "samber/cc-skills-golang@golang-samber-oops", "slog", "HTTP", "Go", "Golang", "errors.Is/As", "errors.Join", "%w", etc. These should remain as is. Also "3rd-party" should be kept as "tiers" or "third-party"? Probably keep as "tiers" but it's a technical term? The instruction says preserve technical terms, so "third-party" can be translated as "tiers" but it's common. However, "3rd-party" might be kept as "tiers" or "third-party". I'll use "tiers" as it's standard. Also "log aggregation" -> "agrégation

We need to translate the given text from English to French, preserving the name "golang-google-wire" as instructed. The text is a description of a directory item type "agent skill". We must not include the name unless it appears in the source text. The source text does not include the name "golang-google-wire" inside the <text> tags, so we don't include it. We translate only the text inside <text>. We preserve product names, protocol names, URLs, numbers, technical terms. So "google/wire", "wire.NewSet", etc. should remain as is. Also "//go:build wireinject" is a build tag, keep as is. "wire_gen.go" keep. "github.com/google/wire" keep. "wire.Build" keep. The last sentence "For runtime DI with reflection, see..." is incomplete, but we translate as is. We need to output only the translated text, no extra commentary. Let's translate: "Compile-time dependency injection in Golang using google/wire —

Fournit des directives d'utilisation de gRPC, l'organisation des protobufs et des patrons prêts pour la production pour les microservices Golang. À utiliser lors de l'implémentation, la révision ou le débogage de serveurs/clients gRPC, de l'écriture de fichiers proto, de la mise en place d'intercepteurs, de la gestion des erreurs gRPC avec codes de statut, de la configuration TLS/mTLS, des tests avec bufconn, ou du travail avec des RPC en streaming.

Orchestrateur de compétences Golang — toujours actif sur toute tâche de codage, révision, débogage ou configuration en Golang. Il lit le contexte de la tâche et charge les compétences les plus pertinentes depuis samber/cc-skills-golang, souvent plusieurs à la fois : écrire un service gRPC charge golang-grpc + golang-testing + golang-error-handling ; déboguer un panic charge golang-troubleshooting + golang-safety ; auditer la sécurité charge golang-security + golang-lint + golang-safety. Aussi : désambiguïse les clusters concurrents lorsque deux compétences semblent se chevaucher...

Bonnes pratiques de linting et configuration de golangci-lint pour les projets Golang — exécution des linters, configuration de .golangci.yml, suppression des avertissements avec les directives nolint, interprétation des résultats de linting et sélection des linters. À utiliser lors de la configuration de golangci-lint, en cas de questions sur les avertissements de linting ou les suppressions nolint, lors de la mise en place d'outils de qualité de code, ou pour choisir des linters. À utiliser également lorsque l'utilisateur mentionne golangci-lint, go vet, staticcheck ou revive.

golang-linter — une compétence installable pour les agents IA.

Moderniser le code Golang pour utiliser les fonctionnalités récentes du langage, les améliorations de la bibliothèque standard et les motifs idiomatiques. Déclencher de manière proactive lors de l'écriture ou de la révision de code Go et de la détection de motifs anciens, ou lors de la rencontre d'un avertissement de dépréciation. Utiliser également lorsque l'utilisateur demande explicitement une modernisation, une mise à niveau de version Go ou un rafraîchissement CI/outillage.

Conventions de nommage Go (Golang) — couvre les packages, constructeurs, structures, interfaces, constantes, énumérations, erreurs, booléens, récepteurs, accesseurs/mutateurs, options fonctionnelles, acronymes, fonctions de test et noms de sous-tests. Utilisez cette compétence lors de l'écriture de nouveau code Go, de révision ou de refactorisation, du choix entre des alternatives de nommage (New vs NewTypeName, isConnected vs connected, ErrNotFound vs NotFoundError, StatusReady vs StatusUnknown à iota 0), du débat sur les noms de packages Go (anti-patrons utils/helpers), ou...

Modèles et méthodologie d'optimisation des performances Golang - si goulot d'étranglement X, alors appliquer Y. Couvre la réduction des allocations, l'efficacité CPU, la disposition mémoire, le réglage du GC, le pooling, la mise en cache et l'optimisation des chemins chauds. À utiliser lorsque le profilage ou les benchmarks ont identifié un goulot d'étranglement et que vous avez besoin du bon modèle d'optimisation pour le corriger. À utiliser également lors d'une revue de code de performance pour suggérer des améliorations ou des benchmarks qui pourraient aider à identifier des gains de performance rapides. Pas pour la méthodologie de mesure (→...

Recommande des bibliothèques et frameworks Golang prêts pour la production. Appliquez lorsque l'utilisateur demande explicitement des suggestions de bibliothèques, souhaite comparer des alternatives, doit choisir une bibliothèque pour une tâche spécifique, ou lorsqu'une nouvelle dépendance est ajoutée au projet.

Codage défensif en Golang pour prévenir les paniques, la corruption silencieuse des données et les bugs subtils d'exécution. À utiliser en cas de paniques nil, d'aliasing d'append, d'accès concurrent à une map, de pièges de comparaison de flottants ou de questions de conception de valeur zéro. À utiliser également lors de la révision de code pour la sécurité nil, les débordements de conversion numérique, les problèmes de cycle de vie des ressources (defer dans les boucles) ou la copie défensive de slices et de maps.

Injection de dépendances en Golang avec samber/do — conteneurs de services, gestion du cycle de vie, portées, vérifications de santé, arrêt gracieux et organisation des modules. À appliquer lors de l'utilisation ou de l'adoption de samber/do, lorsque la base de code importe github.com/samber/do ou github.com/samber/do/v2, ou lors du refactoring d'injection manuelle de constructeurs vers un conteneur DI.

Monadic types for Golang using samber/mo — Option, Result, Either, Future, IO, Task, and State types for type-safe nullable values, error handling, and functional composition with pipeline sub-packages. Apply when using or adopting samber/mo, when the codebase imports `github.com/samber/mo`, or when considering functional programming patterns as a safety design for Golang.

Bonnes pratiques de sécurité et prévention des vulnérabilités pour Golang. Couvre l'injection (SQL, commande, XSS), la cryptographie, la sécurité du système de fichiers, la sécurité réseau, les cookies, la gestion des secrets, la sécurité mémoire et la journalisation. À appliquer lors de l'écriture, de la révision ou de l'audit de code Go pour la sécurité, ou lors du travail sur tout code risqué impliquant la cryptographie, les E/S, la gestion des secrets, le traitement des entrées utilisateur ou l'authentification. Inclut la configuration des outils de sécurité.

We need to translate the given text from English to French. The text describes a Golang configuration library using spf13/viper. We must preserve the name "golang-spf13-viper" but it's not in the text, so we don't include it. Also preserve technical terms like spf13/viper, BindPFlag, SetEnvPrefix, etc. The text ends with "For CLI command..." which is incomplete, but we translate as is. Translation: "Bibliothèque de configuration Golang utilisant spf13/viper — priorité en couches (flag > env > fichier > KV > défaut), BindPFlag/BindPFlags, SetEnvPrefix + SetEnvKeyReplacer + AutomaticEnv, ReadInConfig + ConfigFileNotFoundError, Unmarshal + balises de structure mapstructure, Sub pour sous-arbres, WatchConfig + OnConfigChange pour rechargement à chaud, viper.New() pour isolation de test, et intégration KV distante. Appliquer lors de l

Guide complet de stretchr/testify pour les tests en Golang. Couvre en profondeur les packages assert, require, mock et suite. À utiliser lors de l'écriture de tests avec testify, de la création de mocks, de la mise en place de suites de tests ou du choix entre assert et require. Couvre les assertions testify, les attentes de mock, les correspondances d'arguments, la vérification d'appels, le cycle de vie des suites et les motifs avancés comme Eventually, JSONEq et les correspondances personnalisées. Appliquer lorsque la base de code importe github.com/stretchr/testify.

Modèles de conception de structs et d'interfaces en Golang — composition, imbrication, assertions de type, commutateurs de type, ségrégation d'interfaces, injection de dépendances via interfaces, balises de champs de struct, et récepteurs par pointeur vs par valeur. Utilisez cette compétence lors de la conception de types Go, de la définition ou de l'implémentation d'interfaces, de l'imbrication de structs ou d'interfaces, de l'écriture d'assertions de type ou de commutateurs de type, de l'ajout de balises de champs de struct pour la sérialisation JSON/YAML/DB, ou du choix entre récepteurs par pointeur et par valeur. Utilisez-la également lorsque l'utilisateur...

We need to translate the given text from English to French. The text is a description of a skill for Golang testing. We must preserve the name "golang-testing" but it's not in the text, so we don't include it. Also preserve technical terms like "table-driven tests", "testify suites", "mocks", "parallel tests", "fuzzing", "fixtures", "goroutine leak detection", "goleak", "snapshot testing", "code coverage", "integration tests", "idiomatic test naming", "Go test CI", "flaky/slow tests", "testify-specific APIs", "samber/cc-skills-golang@golang-stretchr-testify", "measurement methodology". Also preserve URLs or references like that. The translation should be natural French but keep all technical terms in English as they are standard. Also note the instruction: "Do not include the name unless it appears in the source text." The name "golang-testing" does not appear in the source text, so we don't include it

Cette compétence doit être utilisée lorsque l'utilisateur souhaite "écrire du code d'agent", "construire un agent avec ADK", "ajouter un outil", "créer un callback", "définir un agent", "utiliser la gestion d'état", ou a besoin de motifs API Python ADK (Agent Development Kit) et d'exemples de code. Fait partie de la suite de compétences Google ADK. Fournit une référence rapide pour les types d'agents, les définitions d'outils, les motifs d'orchestration, les callbacks et la gestion d'état. Ne PAS utiliser pour créer de nouveaux projets (utiliser google-agents-cli-scaffold) ou pour le déploiement...

Réalise un audit de santé d'ingénierie assisté par agent, conscient du budget, pour détecter les dérives d'instructions/de configuration, les hooks/MCP, les surfaces de vérification et la maintenabilité IA. À utiliser lorsque les utilisateurs demandent 检查claude/检查codex/检查pi/配置检查/健康度 ou signalent que des agents ignorent les instructions, manquent de validation, ou que le code devient difficile à maintenir. Pas pour déboguer du code ou examiner des PRs.

Trouve la cause racine avant d'appliquer des correctifs pour les erreurs, les plantages, les régressions, les échecs de tests, les comportements défectueux et les défauts signalés par capture d'écran. À utiliser lorsque les utilisateurs demandent 排查/报错/崩溃/不工作/回归/判断为什么报错, ou disent que quelque chose fonctionnait avant et échoue maintenant. Pas pour la revue de code ou les nouvelles fonctionnalités.

Installer et câbler les blocs et composants du registre dans des compositions HyperFrames. À utiliser lors de l’exécution de hyperframes add, de l’installation d’un bloc ou d’un composant, du câblage d’un élément installé dans index.html, ou du travail avec hyperframes.json. Couvre la commande add, les emplacements d’installation, le câblage de sous-composition de blocs, la fusion d’extraits de composants, la découverte du registre, et la création d’un nouveau bloc ou composant à contribuer en amont (idée → échafaudage → validation → PR).

Implémenter un travail basé sur un PRD ou un ensemble de tickets.

Implémenter une fonctionnalité approuvée à partir de PRODUCT.md et TECH.md, en maintenant l'alignement des spécifications et du code dans la même PR à mesure que l'implémentation évolue. Utiliser après l'approbation des spécifications produit et technique, lorsque l'étape suivante consiste à construire la fonctionnalité.

Examinez n'importe quelle base de code en tant que conseiller senior et produisez des plans d'implémentation priorisés et autonomes pour que D'AUTRES modèles/agents exécutent. Lecture strictement seule du code source — n'implémente, ne corrige ni ne refactorise jamais rien lui-même. Utilisez-le lorsqu'on vous demande d'auditer une base de code, de trouver des opportunités d'amélioration (bugs, sécurité, performances, couverture de tests, dette technique, migrations, DX), de suggérer des fonctionnalités ou des orientations futures pour le projet (feuille de route, direction produit), ou de générer des plans de transmission pour qu'un autre agent...

Trouver des opportunités d'approfondissement dans une base de code, en s'appuyant sur le langage du domaine dans CONTEXT.md et les décisions dans docs/adr/. Utiliser lorsque l'utilisateur souhaite améliorer l'architecture, trouver des opportunités de refactorisation, consolider des modules fortement couplés, ou rendre une base de code plus testable et navigable par l'IA.

Migre les projets et composants React de Radix UI vers Base UI. À utiliser lorsqu'on demande de migrer depuis radix, passer à base-ui, convertir des primitives radix, ou changer la bibliothèque de base d'un projet shadcn. Gère les composants individuels (« migrer accordéon ») et les projets entiers.

Migrate test files from `as` type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace `as` in tests, or needs partial test data.

Compétence Rigor Run pour la reproduction de dépôt deep learning prioritaire au README. À utiliser lorsque la

Explorer et comprendre les espaces de travail Nx. À UTILISER pour répondre à des questions sur l’espace de travail, les projets ou les tâches. À UTILISER ÉGALEMENT lorsqu’une commande nx échoue ou que vous devez vérifier les cibles/la configuration disponibles avant d’exécuter une tâche. EXEMPLES : « Quels projets se trouvent dans cet espace de travail ? », « Comment le projet X est-il configuré ? », « Qu’est-ce qui dépend de la bibliothèque Y ? », « Quelles cibles puis-je exécuter ? », « Configuration introuvable pour la tâche », « déboguer un échec de tâche nx ».

Impose la solution la plus paresseuse qui fonctionne réellement, la plus simple, la plus courte, la plus minimale. Canalise un développeur senior qui a tout vu : remets en question la nécessité même de la tâche (YAGNI), privilégie la bibliothèque standard avant le code personnalisé, les fonctionnalités natives de la plateforme avant les dépendances, une ligne avant cinquante. Prend en charge les niveaux d'intensité : lite, full (par défaut), ultra. À utiliser lorsque l'utilisateur dit "ponytail", "sois paresseux", "mode paresseux", "solution la plus simple", "solution minimale", "yagni", "fais moins", ou...

Audit complet du dépôt pour détection de sur-ingénierie. Comme ponytail-review, mais analyse l’intégralité du codebase au lieu d’un diff : une liste classée de ce qu’il faut supprimer, simplifier ou remplacer par des équivalents natifs/stdlib. À utiliser lorsque l’utilisateur dit « auditer ce codebase », « auditer pour sur-ingénierie », « que puis-je supprimer de ce dépôt », « trouver le superflu », « ponytail-audit » ou « /ponytail-audit ». Rapport unique, n’applique pas de correctifs.

Harvest every `ponytail:` comment in the codebase into a debt ledger, so the deliberate shortcuts and deferrals ponytail leaves behind get tracked instead of rotting into "later means never". Use when the user says "ponytail debt", "/ponytail-debt", "what did ponytail defer", "list the shortcuts", "ponytail ledger", or "what did we mark to do later". One-shot report, changes nothing.

Revue de code centrée exclusivement sur la sur-ingénierie. Trouve ce qui doit être supprimé : réinvention de la bibliothèque standard, dépendances inutiles, abstractions spéculatives, flexibilité morte. Une ligne par résultat : emplacement, quoi couper, ce qui le remplace. À utiliser lorsque l'utilisateur dit « revue pour sur-ingénierie », « que pouvons-nous supprimer », « est-ce sur-ingénié », « revue de simplification », ou invoque /ponytail-review. Complète la revue axée sur la correction, celle-ci ne traque que la complexité.

flux de travail pr-to-video - une pull request GitHub (URL comme github.com/ / /pull/ , ou / # , ou "cette PR" dans un dépôt extrait) -> faits de PR ingérés (titre, corps, diff, commits, fichiers, statistiques +/-) -> narrator_scripts.json + audio (voix + BGM) + section_plan.md -> vidéo explicative de diff de code / avant-après / impact. L'entrée est un CHANGEMENT DE CODE. L'URL est un lien de PR, PAS un site marketing à scraper ; pas un résumé textuel et pas un site produit. Pour une entrée non-PR (site produit, site général, texte de sujet),...

Générer une procédure pas à pas interactive statique en D3 d’une pull request. Utiliser lorsque l’utilisateur souhaite une carte PR zoomable, une orientation graphique/canvas PR, ou une visualisation alternative des composants du système PR, du flux de données, des dépendances de code et des actions utilisateur.

Session de QA interactive où l'utilisateur signale des bugs ou problèmes de manière conversationnelle, et l'agent crée des issues GitHub. Explore la base de code en arrière-plan pour le contexte et le langage du domaine. À utiliser lorsque l'utilisateur souhaite signaler des bugs, faire de la QA, créer des issues de manière conversationnelle, ou mentionne "session QA".

À utiliser lors de la réception de retours de révision de code, avant de mettre en œuvre les suggestions, surtout si les retours semblent peu clairs ou techniquement discutables - nécessite rigueur technique et vérification, non un accord de façade ou une mise en œuvre aveugle.

Améliore les sites web et applications existants vers une qualité premium. Audite le design actuel, identifie les motifs génériques d'IA et applique des standards de design haut de gamme sans casser la fonctionnalité. Fonctionne avec n'importe quel framework CSS ou CSS vanilla.

Créer un plan de refactorisation détaillé avec de petits commits via un entretien utilisateur, puis le déposer en tant que ticket GitHub. À utiliser lorsque l'utilisateur souhaite planifier une refactorisation, créer un RFC de refactorisation, ou décomposer une refactorisation en étapes incrémentales sûres.

Utiliser lors de l’exécution de tâches, de l’implémentation de fonctionnalités majeures ou avant une fusion pour vérifier que le travail répond aux exigences.

Resolve Git merge conflicts by extracting only unresolved paths, conflict hunks, and compact diffs instead of loading whole files into context. Use when a merge, rebase, cherry-pick, or stash pop stops on conflicts, when `git status` shows unmerged paths, or when files contain conflict markers.

Utilisez lorsque vous devez résoudre un conflit de fusion/rebasage git en cours.

Examiner les modifications depuis un point fixe (commit, branche, tag ou merge-base) selon deux axes — Normes (le code respecte-t-il les standards de codage documentés de ce dépôt ?) et Spécifications (le code correspond-il à ce que demandait le ticket/PRD d'origine ?). Exécute les deux examens en parallèle via des sous-agents et les rapporte côte à côte. À utiliser lorsque l'utilisateur souhaite examiner une branche, une PR, des modifications en cours, ou demande de « review depuis X ».

Examiner le diff d'une pull request et rédiger un retour structuré dans review.json pour que le workflow le publie. À utiliser lors de la révision d'une PR extraite localement à partir d'artefacts comme pr_diff.txt et pr_description.txt, en produisant une sortie de révision lisible par machine plutôt qu'en publiant directement sur GitHub.

Compétence de débogage rigoureux / audit rigoureux pour les travaux de recherche en deep learning. À utiliser lorsque l'utilisateur colle un traceback, une erreur de terminal, une OOM CUDA, un échec de chargement de checkpoint, une incompatibilité de forme, un symptôme de perte NaN ou un échec d'entraînement et souhaite un diagnostic conservateur avant toute correction, avec des correctifs de débogage clairement séparés des contributions de recherche. Ne pas utiliser pour un refactoring large, une adaptation spéculative, un patching exploratoire automatique ou une familiarisation générale avec le dépôt.

Configurer les hooks Husky pre-commit avec lint-staged (Prettier), la vérification de types et les tests dans le dépôt actuel. Utiliser lorsque l'utilisateur souhaite ajouter des hooks pre-commit, configurer Husky, paramétrer lint-staged, ou ajouter du formatage, de la vérification de types ou des tests au moment du commit.

Expert en conformité pour snyk-agent-scan — le scanner de fichiers de compétences d'agent — PAS pour les autres outils CLI Snyk (snyk test, snyk code SAST, snyk iac, snyk container). Corrige les alertes par restructuration du contenu, jamais en supprimant ou masquant des informations. Couvre chaque fichier d'un répertoire de compétence : SKILL.md, references/, assets/ et tout markdown secondaire. À appliquer lors de la création d'une nouvelle compétence, de la modification d'une existante, du tri d'un échec d'exécution de snyk-agent-scan en local ou en CI, ou pour débloquer une PR bloquée par l'agent...

Fonde chaque décision d'implémentation sur la documentation officielle. Utilisez-le lorsque vous souhaitez un code faisant autorité, citant ses sources et exempt de motifs obsolètes. Utilisez-le lors de la création avec tout framework ou bibliothèque où l'exactitude est importante.

Utiliser lors de la rencontre d'un bogue, d'un échec de test ou d'un comportement inattendu, avant de proposer des correctifs

Utiliser lors de l'implémentation d'une fonctionnalité ou d'une correction de bug, avant d'écrire le code d'implémentation

Maîtrisez le système de types avancé de TypeScript, incluant les génériques, les types conditionnels, les types mappés, les littéraux de gabarit et les types utilitaires pour créer des applications typées de manière sécurisée. Utilisez-le lors de l'implémentation de logique de type complexe, de la création d'utilitaires de type réutilisables ou pour garantir la sécurité des types à la compilation dans les projets TypeScript.

Valider que l'implémentation d'une branche ou d'une pull request correspond aux spécifications produit, techniques, de sécurité et connexes introduites. À utiliser lors de la révision ou de la finalisation d'une modification pilotée par des spécifications et de la résolution des écarts entre les spécifications archivées et l'implémentation.

À utiliser lorsqu'on est sur le point de déclarer un travail comme terminé, corrigé ou réussi, avant de commiter ou de créer des PRs - nécessite d'exécuter des commandes de vérification et de confirmer la sortie avant de faire des affirmations de succès ; des preuves avant les assertions toujours.