qwen-superpowers 1.0.0

package/skills/systematic-debugging/SKILL.md

@@ -0,0 +1,74 @@
+# Systematic Debugging
+
+> Approche méthodique en 4 phases pour identifier et résoudre les bugs sans deviner.
+
+## Triggers
+- Un test échoue
+- Un bug est rapporté par l'utilisateur
+- Un comportement inattendu est observé
+- L'agent est tenté de "deviner" la cause d'un problème
+
+## Instructions
+
+### Phase 1 : Comprendre le Symptôme
+1. Reproduire le bug de manière consistante
+2. Noter le comportement attendu vs comportement observé
+3. Identifier les conditions exactes du bug (input, environnement, timing)
+4. **NE PAS** encore chercher la cause — juste décrire le symptôme
+
+### Phase 2 : Isoler la Cause Racine
+1. Réduire le scope au minimum (plus petit exemple qui reproduit)
+2. Utiliser une approche dichotomique (couper le problème en deux)
+3. Vérifier les hypothèses une par une (pas de suppositions)
+4. Ajouter des logs/assertions pour confirmer chaque étape
+
+### Phase 3 : Corriger
+1. Identifier le changement minimal qui corrige le bug
+2. Écrire un test qui reproduit le bug (il doit échouer)
+3. Appliquer la correction
+4. Vérifier que le test passe maintenant (GREEN)
+
+### Phase 4 : Prévenir la Régession
+1. Ajouter le test au suite permanente
+2. Vérifier que les tests existants passent toujours
+3. Documenter le bug et sa cause si nécessaire
+4. Chercher des patterns similaires dans le codebase
+
+## Règles
+
+1. **Jamais de correction sans test** — le bug doit être reproduit par un test
+2. **Une hypothèse à la fois** — ne pas changer plusieurs choses simultanément
+3. **Minimal reproducible** — toujours réduire au plus petit exemple
+4. **Comprendre avant d'agir** — identifier la cause racine, pas le symptôme
+5. **Vérifier après correction** — relancer toute la suite de tests
+
+## Sortie Attendue
+
+Après un debugging complet :
+- [ ] Symptôme documenté (attendu vs observé)
+- [ ] Cause racine identifiée et expliquée
+- [ ] Test de régression écrit (échouait avant, passe après)
+- [ ] Correction appliquée (changement minimal)
+- [ ] Tous les tests passent
+- [ ] Recherche de patterns similaires effectuée
+
+## Exemple d'Utilisation
+
+```
+// Phase 1: Symptôme
+// "La fonction calculateTotal retourne NaN quand le panier a 1 item à prix 0"
+
+// Phase 2: Isolation
+// Plus petit repro: calculateTotal([{price: 0, qty: 1}]) → NaN
+// Cause: la fonction fait items.reduce((sum, i) => sum + i.price * i.qty)
+//        mais ne gère pas le cas où price = 0 avec qty = 1
+
+// Phase 3: Correction + Test
+it('should handle items with price 0', () => {
+  expect(calculateTotal([{price: 0, qty: 1}])).toBe(0);
+});
+// → Échoue → Appliquer correction → Passe ✅
+
+// Phase 4: Prévention
+// Vérifier qu'aucune autre fonction n'a le même pattern
+```

package/skills/test-driven-development/SKILL.md

@@ -0,0 +1,88 @@
+# Test-Driven Development (TDD)
+
+> Écrire les tests AVANT le code de production. Cycle strict : RED → GREEN → REFACTOR.
+
+## Triggers
+- Toute demande de développement de fonctionnalité ou de correction
+- Quand l'agent s'apprête à écrire du code de production
+- Quand `.qwen-powers.json` a `settings.tddEnforced: true`
+
+## Instructions
+
+### 1. Cycle RED-GREEN-REFACTOR (OBLIGATOIRE)
+
+#### 🔴 RED — Écrire un test qui échoue
+1. Identifier le comportement attendu
+2. Écrire un test unitaire qui valide ce comportement
+3. Le test DOIT échouer initialement (vérifier que le test n'est pas trivial)
+4. Exécuter le test pour confirmer l'échec
+
+#### 🟢 GREEN — Faire passer le test
+1. Écrire le **minimum de code** pour faire passer le test
+2. Ne pas ajouter de logique non testée
+3. Exécuter tous les tests pour confirmer que tout passe
+4. Si un test échoue, corriger avant de continuer
+
+#### 🔵 REFACTOR — Améliorer sans casser
+1. Simplifier le code tout en gardant les tests verts
+2. Réduire la duplication, améliorer la lisibilité
+3. Exécuter les tests après chaque micro-changement
+4. Commiter uniquement si tous les tests passent
+
+### 2. Règle Anti-Pattern
+- **SUPPRIMER** tout code de production écrit avant son test
+- Ne JAMAIS écrire "juste un petit bout de code pour voir"
+- Ne JAMAAS commettre de code avec des tests qui échouent
+
+## Règles
+
+1. **Le test vient TOUJOURS en premier** — sans exception
+2. **Un seul test à la fois** — ne pas écrire plusieurs tests avant le code
+3. **Minimum de code** — écrire juste assez de code pour passer le test
+4. **Tests verts = obligatoire** — aucun commit si un test échoue
+5. **Refactorer avec filet** — jamais de refactoring sans tests verts
+
+## Anti-Patterns à Éviter
+
+| Anti-Pattern | Description | Correction |
+|--------------|-------------|------------|
+| Code avant test | Écrire la fonction avant le test | Supprimer et recommencer par le test |
+| Tests multiples | Écrire 3 tests avant tout code | Un test → code → suivant |
+| Gold plating | Ajouter des fonctionnalités non testées | Supprimer ou écrire un test d'abord |
+| Commit rouge | Committer avec des tests qui échouent | Interdit — corriger d'abord |
+| Test après coup | Écrire le test après le code "pour couvrir" | Recommmencer par le test |
+
+## Sortie Attendue
+
+Après chaque cycle TDD complet :
+- [ ] Test écrit et documenté
+- [ ] Test passe (GREEN)
+- [ ] Code refactorisé si nécessaire
+- [ ] Tous les tests du projet passent
+- [ ] Commit avec message descriptif
+
+## Exemple d'Utilisation
+
+```
+// 1. RED — Test qui échoue
+describe('calculateTotal', () => {
+  it('should return 0 for empty cart', () => {
+    expect(calculateTotal([])).toBe(0);
+  });
+});
+// → Exécuter → Échec (fonction n'existe pas) ✅
+
+// 2. GREEN — Minimum de code
+function calculateTotal(items) {
+  return items.length === 0 ? 0 : null;
+}
+// → Exécuter → Succès ✅
+
+// 3. REFACTOR — Améliorer
+function calculateTotal(items) {
+  if (!items || items.length === 0) return 0;
+  // ... suite du logic
+}
+// → Exécuter → Succès ✅
+// → Commit ✅
+```

package/skills/verification-before-completion/SKILL.md

@@ -0,0 +1,109 @@
+# Verification Before Completion
+
+> Ne jamais marquer une tâche comme terminée sans vérification systématique.
+
+## Triggers
+- L'agent s'apprête à dire "c'est fini" ou "task complete"
+- Toutes les tâches d'un plan ont été exécutées
+- Avant un commit ou un merge
+- L'utilisateur demande "est-ce que c'est terminé ?"
+
+## Instructions
+
+### 1. Vérification des Tests
+```bash
+# Exécuter toute la suite de tests
+npm test
+
+# Ou le framework spécifique au projet
+# pytest, make test, etc.
+```
+- [ ] **TOUS** les tests passent (pas seulement les nouveaux)
+- [ ] Pas de tests ignorés/skipped sans raison valable
+- [ ] Coverage n'a pas diminué (si outils de coverage)
+
+### 2. Vérification du Linting
+```bash
+npm run lint
+# ou l'équivalent du projet
+```
+- [ ] Pas d'erreurs de lint
+- [ ] Pas de warnings critiques
+- [ ] Formatage correct (prettier, black, etc.)
+
+### 3. Vérification du Build
+```bash
+npm run build
+# ou compilation du projet
+```
+- [ ] Le build passe sans erreurs
+- [ ] Pas de warnings de dépréciation critiques
+- [ ] Les types sont corrects (TypeScript, etc.)
+
+### 4. Vérification du Plan
+- [ ] Toutes les tâches du plan sont cochées
+- [ ] Le code produit correspond au plan
+- [ ] Pas de fonctionnalité oubliée ou partiellement implémentée
+
+### 5. Vérification Git
+```bash
+git status
+git diff --stat
+```
+- [ ] Tous les fichiers modifiés sont identifiés
+- [ ] Pas de fichiers temporaires ou de debug
+- [ ] Le message de commit est descriptif
+
+## Règles
+
+1. **TOUJOURS tout vérifier** — pas de raccourci
+2. **Tests = preuve唯一** — "ça devrait marcher" n'est pas acceptable
+3. **Linting obligatoire** — le code doit être propre
+3. **Build = non-négociable** — pas de completion si le build échoue
+4. **Plan = référence** — tout ce qui est dans le plan doit être fait
+
+## Sortie Attendue
+
+```markdown
+✅ Vérification Before Completion
+
+Tests:        ✅ 47/47 passent
+Lint:         ✅ Aucune erreur
+Build:        ✅ Succès
+Plan:         ✅ 6/6 tâches complétées
+Git:          ✅ 3 fichiers modifiés, 0 temporaire
+
+🎉 TÂCHE TERMINÉE — Prêt pour l'étape suivante
+```
+
+## Si Quelque Chose Échoue
+
+```markdown
+❌ Vérification Before Completion — BLOQUÉ
+
+Tests:        ❌ 2 échecs
+  - `cache.test.ts:45` — expected 0 but received undefined
+  - `cache.test.ts:52` — timeout after 5000ms
+
+Lint:         ✅ Aucune erreur
+Build:        ✅ Succès
+Plan:         ✅ 6/6 tâches complétées
+
+🔧 Action requise: corriger les tests échoués avant de continuer.
+```
+
+## Exemple d'Utilisation
+
+```
+L'agent: "J'ai terminé l'implémentation du cache."
+
+→ Trigger automatique: Verification Before Completion
+
+1. $ npm test → 47/47 ✅
+2. $ npm run lint → Clean ✅
+3. $ npm run build → Success ✅
+4. Vérification plan → 6/6 tasks ✅
+5. $ git status → 3 fichiers modifiés ✅
+
+✅ TOUT EST VÉRIFIÉ — La tâche est réellement terminée.
+```

package/skills/writing-plans/SKILL.md

@@ -0,0 +1,101 @@
+# Writing Plans
+
+> Découper le travail en tâches de 2-5 minutes avec chemins exacts, snippets de code et étapes de vérification.
+
+## Triggers
+- Un design doc a été validé par l'utilisateur
+- L'utilisateur demande de planifier un travail
+- L'agent a compris le scope et est prêt à détailler l'exécution
+
+## Instructions
+
+### 1. Analyser le Design Doc
+- Identifier les composants/entités principaux
+- Lister les dépendances entre les composants
+- Déterminer l'ordre d'implémentation (TDD : tests d'abord)
+
+### 2. Découper en Tâches Atomiques
+Chaque tâche DOIT :
+- Être réalisable en **2-5 minutes**
+- Avoir un **résultat vérifiable** clair
+- Spécifier le **chemin exact** du fichier à créer/modifier
+- Inclure un **snippet de départ** si pertinent
+- Définir les **tests de vérification**
+
+### 3. Formater le Plan
+
+```markdown
+# Plan d'Exécution: [Nom]
+
+## Tâche 1: [Nom de la tâche]
+- **Fichier(s):** `src/path/to/file.ts`
+- **Type:** Test / Implementation / Refactor
+- **Description:** Ce qui doit être fait
+- **Snippet de départ:**
+  ```typescript
+  // code initial
+  ```
+- **Vérification:** `npm test -- --grep "nom du test"`
+- **Dépendances:** Aucune (ou tâche X)
+
+## Tâche 2: [Nom de la tâche]
+...
+```
+
+### 4. Ordonnancer
+- Les tests AVANT l'implémentation (TDD)
+- Les dépendances avant les dépendants
+- Les tâches parallélisables identifiées pour subagent dispatch
+
+## Règles
+
+1. **Granularité fine** — 2-5 minutes max par tâche
+2. **Chemins exacts** — pas de "un fichier quelques part"
+3. **Vérification explicite** — comment savoir que c'est fini
+4. **Ordre TDD** — tests avant implementation
+5. **Identifier le parallélisme** — quelles tâches peuvent être dispatchées
+
+## Sortie Attendue
+
+- [ ] Plan complet avec toutes les tâches
+- [ ] Chaque tâche a un fichier, description, snippet et vérification
+- [ ] Ordre d'exécution défini
+- [ ] Tâches parallélisables identifiées
+- [ ] Plan validé par l'utilisateur
+
+## Exemple d'Utilisation
+
+```markdown
+# Plan: Système de Cache API
+
+## Tâche 1: Test - Cache create/empty
+- **Fichier:** `src/cache/__tests__/cache.test.ts`
+- **Type:** Test
+- **Description:** Tester que new Cache() est vide
+- **Snippet:**
+  ```typescript
+  import { Cache } from '../cache';
+  describe('Cache', () => {
+    it('should be empty when created', () => {
+      const cache = new Cache();
+      expect(cache.size()).toBe(0);
+    });
+  });
+  ```
+- **Vérification:** `npm test -- --grep "empty when created"`
+- **Dépendances:** Aucune
+
+## Tâche 2: Implémenter Cache class
+- **Fichier:** `src/cache/cache.ts`
+- **Type:** Implementation
+- **Description:** Classe Cache avec Map interne
+- **Snippet:**
+  ```typescript
+  export class Cache {
+    private store = new Map<string, any>();
+    size(): number { return this.store.size; }
+  }
+  ```
+- **Vérification:** Test de la tâche 1 passe
+- **Dépendances:** Tâche 1
+```

package/skills/writing-skills/SKILL.md

@@ -0,0 +1,112 @@
+# Writing Skills
+
+> Comment créer, tester et documenter un nouveau skill pour Qwen Superpowers.
+
+## Triggers
+- L'utilisateur veut créer un nouveau skill
+- L'agent identifie un comportement réutilisable qui mérite un skill
+- Amélioration ou extension de la librairie de skills
+
+## Instructions
+
+### 1. Identifier le Besoin
+- Quel comportement ou processus veut-on standardiser ?
+- Quand ce skill doit-il être déclenché ?
+- Qu'est-ce qui le distingue des skills existants ?
+
+### 2. Créer la Structure
+```
+skills/<nom-du-skill>/
+├── SKILL.md          # Description, triggers, instructions, règles
+├── examples/         # (optionnel) Exemples d'utilisation
+└── tests/            # (optionnel) Tests de validation du skill
+```
+
+Utiliser la CLI : `qwen-powers create <nom-du-skill>`
+
+### 3. Rédiger le SKILL.md
+
+```markdown
+# [Nom du Skill]
+
+> Description en une phrase.
+
+## Triggers
+- Quand utiliser ce skill ?
+- Quels motifs ou contextes déclenchent ce skill ?
+
+## Instructions
+1. Étape 1 — description détaillée
+2. Étape 2 — description détaillée
+3. Étape 3 — description détaillée
+
+## Règles
+- Règle 1 — non-négociable
+- Règle 2 — importante
+- Règle 3 — recommandée
+
+## Sortie attendue
+- [ ] Élément vérifiable 1
+- [ ] Élément vérifiable 2
+- [ ] Élément vérifiable 3
+
+## Exemple d'utilisation
+\`\`\`
+Exemple concret avec entrée et sortie attendues.
+\`\`\`
+```
+
+### 4. Tester le Skill
+1. Activer le skill: `qwen-powers enable <nom>`
+2. Demander à l'agent de l'utiliser dans un scénario réel
+3. Vérifier que les sorties sont conformes
+4. Ajuster les instructions si nécessaire
+
+### 5. Documenter
+- Ajouter des exemples dans `examples/`
+- Documenter les cas limites connus
+- Lister les dépendances vers d'autres skills
+
+## Règles
+
+1. **Un skill = une responsabilité** — pas de skill fourre-tout
+2. **Triggers explicites** — quand exactement ce skill doit s'activer
+3. **Instructions actionnables** — étapes concrètes, pas de théorie
+4. **Sortie vérifiable** — on doit pouvoir vérifier si le skill a bien été exécuté
+5. **Compatible TDD** — si le skill touche au code, il doit respecter le TDD
+
+## Sortie Attendue
+
+- [ ] SKILL.md complet avec toutes les sections
+- [ ] Triggers clairs et détectables
+- [ ] Instructions étape par étape
+- [ ] Règles non-négociables listées
+- [ ] Sortie vérifiable définie
+- [ ] Exemple d'utilisation documenté
+
+## Exemple : Création du Skill "API-Design"
+
+```bash
+$ qwen-powers create api-design
+✓ Skill 'api-design' créé dans: skills/api-design
+
+# Puis éditer skills/api-design/SKILL.md avec le contenu approprié
+```
+
+```markdown
+# API Design
+
+> Concevoir des APIs RESTful cohérentes et documentées.
+
+## Triggers
+- L'utilisateur demande de créer une nouvelle API
+- Refactoring d'une API existante
+- Discussion sur les endpoints ou le contrat API
+
+## Instructions
+1. Identifier les ressources et leurs relations
+2. Définir les endpoints (GET, POST, PUT, DELETE)
+3. Spécifier les schemas d'entrée/sortie
+4. Documenter les codes de réponse HTTP
+...
+```