BIGboss248/nextjs-wordpress

Workflow pour lancer un sous-agent indépendant chargé d'effectuer des revues de code impartiales et d'injecter des tests de cas limites antagonistes ([ComponentName].edge.test.tsx).

Qu'est-ce que nextjs-wordpress ?

Ce skill fournit un workflow spécialisé pour éliminer le biais de confirmation de l'auteur en déléguant la revue de code et les tests de cas limites à un sous-auditeur antagoniste indépendant. L'auditeur examine les composants Next.js, leurs squelettes, tests unitaires et stories, puis génère un fichier de tests d'edge cases ([ComponentName].edge.test.tsx). Ces tests couvrent les valeurs limites, les permutations de props, les états réseau/erreur, l'accessibilité, le mouvement réduit, les stress tests et le cycle de vie. Le skill interdit strictement de modifier ou d'affaiblir ces tests : si un test échoue, c'est le code du composant qui doit être corrigé, pas le test. Idéal pour les développeurs Next.js utilisant des agents comme Claude Code, Cursor ou Codex, ce workflow renforce la robustesse des composants en automatisant la détection de scénarios souvent négligés.

Compatible avec~Claude Code~Codex CLI~Cursor

npx skills add https://github.com/BIGboss248/nextjs-wordpress/tree/HEAD/.agents/skills/nextjs-adversarial-qa

Documentation

Tests antagonistes et injection de cas limites Next.js (`nextjs-adversarial-qa`)

Workflow spécialisé pour éliminer le biais de confirmation de l'auteur en déléguant la revue de code et les tests de cas limites à un sous-auditeur antagoniste indépendant.

[!TIP] Document de référence :

Pièges courants et anti-patrons : references/pitfalls.md

Règles architecturales et normes

1. Le principe de l'auditeur impartial

L'agent principal qui a écrit le composant NE DOIT PAS auto-certifier les cas limites.
Vous DEVEZ lancer un sous-agent indépendant à l'aide de invoke_subagent pour auditer le code et injecter des assertions antagonistes.

2. Portée des cas limites antagonistes (`[ComponentName].edge.test.tsx`)

Le sous-agent DOIT écrire [ComponentName].edge.test.tsx en ciblant des scénarios souvent négligés par les développeurs :

Valeurs limites : Chaînes vides, entrées null/undefined, chaînes très longues, glyphes Unicode et RTL perses ("سلام دنیا").
Permutations de props : Combinaisons non gérées de drapeaux optionnels.
États réseau et erreur : Rejet asynchrone, payloads malformés, flux lents.
Accessibilité et mouvement avancés : Navigation au clavier (Entrée, Espace, Tab, Échap), aria-expanded, aria-busy, aria-live, piège de focus, et prefers-reduced-motion.
Stress et cycle de vie : Rendu rapide, nettoyage de démontage, destruction de minuteurs.

3. Le principe des tests antagonistes immuables

Modifier ou assouplir les tests est STRICTEMENT INTERDIT : Le développeur n'est PAS autorisé à supprimer ou affaiblir les assertions dans [ComponentName].edge.test.tsx.
Corriger le code, pas les tests : Si un test antagoniste échoue, modifiez le composant ([ComponentName].tsx) ou la story ([ComponentName].stories.tsx) pour gérer correctement le cas limite.

Étapes du workflow

Étape 1 : Lancer le sous-auditeur antagoniste
- Appelez invoke_subagent avec :
  - TypeName : "self"
  - Role : "Auditeur antagoniste de code et QA"
  - Model : "inherit"
  - Prompt : Demandez à l'auditeur d'inspecter [ComponentName].tsx, [ComponentName]Skeleton.tsx, [ComponentName].test.tsx et [ComponentName].stories.tsx, puis de générer [ComponentName].edge.test.tsx dans le répertoire du composant.
Étape 2 : L'auditeur injecte [ComponentName].edge.test.tsx
- L'auditeur écrit les assertions de cas limites et termine la revue.
Étape 3 : Exécution des tests antagonistes et auto-réparation
- Lancez la suite de tests de cas limites :
```
pnpm test -- <target_component_dir>/[ComponentName].edge.test.tsx
```
- Si un test échoue, corrigez l'implémentation du composant jusqu'à ce que tous les tests d'edge case passent avec 0 erreur.