Synthèse automatique
Ce skill impose un cycle TDD strict — rouge, vert, refactorisation — pour toute nouvelle fonctionnalité, correction de bug ou refactorisation.
Points forts
- Exige explicitement un test en échec avant toute implémentation.
- Découpe le travail en petites unités de comportement testables et nommées clairement.
- Protège contre les régressions en demandant une suite verte après chaque changement.
- Inclut une phase de refactorisation séparée, sans ajout de nouveau comportement.
Limites
- Ne traite pas des tests d’intégration, E2E ou de performance.
- Peut ralentir les prototypes exploratoires ou le code jetable.
- Suppose que l’agent peut exécuter les tests et interpréter correctement les échecs.
À utiliser pour développer ou corriger du code de production lorsque des tests automatisés existent et que la prévention des régressions compte.
À éviter pour des spikes exploratoires, des prototypes jetables ou des environnements où les tests ne peuvent pas être exécutés.
Analyse de sécurité
SûrThe skill is a pure TDD methodology guide with no tool declarations, commands, network access, file operations, or secrets handling. It cannot cause execution risk as written.
Aucun point d'attention détecté
Comment cette analyse est faiteExemples
Use the Test-Driven Development skill to add a `calculateTotal` function to `src/cart.js`. Start with a failing test for an empty cart, then implement only enough code to pass, and refactor before adding the next behavior.Fix the bug where `formatDate` returns an invalid string for leap days. First write a failing unit test that reproduces the issue, then make it pass with the smallest change, and run the full test suite.Refactor the `useTransactions` hook to remove duplicated filtering logic. Keep the existing test suite green after every change and do not add new behavior without a new failing test.Skill: Test-Driven Development
Trigger
Load this skill whenever:
- Writing a new function, hook, component, or module
- Fixing a bug (the bug must have a test that reproduces it before the fix)
- Refactoring existing code
- Adding a new API endpoint or store action
Type
Rigid — The RED → GREEN → REFACTOR cycle is non-negotiable. Never write implementation code before a failing test exists.
Instructions
Phase 1 — RED (Write a failing test)
- Identify the smallest possible unit of behavior to implement.
- Write a test that describes the expected behavior. The test must:
- Have a descriptive name (
it('returns zero when no transactions exist', ...)) - Test one thing only
- Currently fail (you have not written the implementation yet)
- Have a descriptive name (
- Run the test. Confirm it fails with the expected error, not an import error or syntax error.
- Do not proceed to Phase 2 until the test fails for the right reason.
Phase 2 — GREEN (Make the test pass with minimal code)
- Write the simplest possible implementation that makes the test pass.
- Do not add logic the test does not require. Resist the urge to generalize.
- Run the test. Confirm it passes.
- Do not proceed to Phase 3 if any other tests are broken.
Phase 3 — REFACTOR (Clean up without changing behavior)
- Improve the implementation: extract duplication, rename variables, simplify logic.
- Run the full test suite after every change. All tests must stay green.
- Do not add new behavior during refactor. If you think of something new, write a new test first (return to Phase 1).
Repeating the cycle
- For each additional behavior, return to Phase 1. One cycle per behavior unit.
Verification
- A failing test exists before any implementation is written.
- The test name describes behavior, not implementation details.
- After GREEN, no other tests are broken.
- After REFACTOR, the test suite is fully green and the code is cleaner than before.
- At no point was implementation written without a corresponding test.
Du fichier au premier essai
Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.
Consulter la source et ses fichiers annexesCe téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.
1. Télécharger le fichier
Télécharger SKILL.mdDepuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/test-driven-development-ms47vpy5/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.
Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.
mkdir -p '.skill-downloads/test-driven-development-ms47vpy5' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/test-driven-development-ms47vpy5/download' --output '.skill-downloads/test-driven-development-ms47vpy5/SKILL.md.part' && mv '.skill-downloads/test-driven-development-ms47vpy5/SKILL.md.part' '.skill-downloads/test-driven-development-ms47vpy5/SKILL.md'2. Vérifier les prérequis
Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.
Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.
Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.
3. Charger la skill
Le fichier ne fournit pas un en-tête name/description exploitable pour cette procédure native. Le téléchargement reste disponible pour lecture ; utilisez le mode manuel ci-dessous.
Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.
4. Faire un premier essai
Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :
Lis .skill-downloads/test-driven-development-ms47vpy5/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.
Comparaison de performances ClickHouse
Testing
Évaluez les résultats de tests de performance ClickHouse, analysez les régressions de PR, comparez avec l'historique et vérifiez la fiabilité des mesures.
Analyse des rapports de performance CI
Testing
Analyse les rapports de comparaison de performance CI pour une PR ClickHouse. Recoupe l'historique master pour distinguer les vraies régressions des tests instables.
Méthode Santa
Testing
Vérification adversarial multi-agents avec deux réviseurs indépendants. La sortie est vérifiée deux fois et corrigée itérativement jusqu'à ce que les deux acceptent avant publication.