Synthèse automatique
Impose un cycle TDD strict — test rouge, implémentation minimale, refactorisation — pour toute modification de code couverte par des tests, avec Vitest comme framework imposé.
Points forts
- Exige un test qui échoue avant toute ligne d'implémentation, ce qui ancre le travail sur un comportement observable.
- Privilégie systématiquement la commande de test la plus ciblée (fichier, puis package, puis dépôt).
- Interdit explicitement `bun:test` et fournit les patterns Vitest attendus (vi.fn, vi.hoisted, vi.spyOn).
- Décrit une procédure de repli claire quand les tests ne peuvent pas s'exécuter (dépendances, identifiants, environnement).
Limites
- Fortement couplé à une stack précise (Turborepo, `bun run test`, Vitest) : les commandes ne sont pas transposables telles quelles.
- La règle « les types passent toujours » peut être irréaliste sur une base de code legacy avec des erreurs préexistantes.
- Ne définit aucun objectif de couverture ni de stratégie de test au-delà du plus petit comportement observable.
À utiliser pour toute correction de bug ou nouvelle fonctionnalité testable où l'on veut qu'un test échoue d'abord et guider l'implémentation.
À éviter sur des changements non testables (scripts jetables, configuration, prototypage exploratoire) ou sur une stack qui n'utilise pas Vitest.
Analyse de sécurité
SûrThe skill only defines a standard TDD workflow and uses Bash for running tests. It contains no destructive commands, credential handling, network exfiltration, obfuscation, or safety-disabling instructions.
Aucun point d'attention détecté
Comment cette analyse est faiteExemples
Add a processRefund function to packages/core that rejects refunds older than 90 days. Follow TDD: write the failing Vitest test first and show me the red run, then implement the minimal code to make it green.The applyDiscount helper rounds incorrectly for zero-decimal currencies. Write a failing Vitest test that reproduces the bug, make it pass with the smallest change, then refactor with tests still green.I don't have DB credentials locally. I need to add email validation to the signup handler — write the failing test first anyway, note the expected outcome, and give me the exact command to run once I have the env set up.name: tdd-red-green-refactor description: Enforce TDD workflow (red → green → refactor). Use for any code change that is testable. allowed-tools: Read, Grep, Glob, Edit, Write, Bash
TDD Red / Green / Refactor
Use this skill whenever making code changes that should be covered by tests.
Non-negotiables
- Start with a failing test that expresses the behavior (red).
- Implement the smallest change to pass (green).
- Refactor for clarity/structure after green, keeping tests passing.
- If no tests exist, add a minimal test harness + a failing test first.
Workflow
- Identify the smallest observable behavior.
- Add or update a test to fail on current code.
- Run the smallest relevant test command (targeted if possible).
- Implement the minimal code to make it pass.
- Refactor with tests still green.
- Report: test command(s) run + results.
If tests cannot run
- State why (missing deps, env, credentials, etc.).
- Still write the failing test first and note the expected outcome.
- Provide a suggested test command for the user to run.
Test targeting
Prefer the narrowest scope:
- single file
- package-level
- repo-level only if needed
Typecheck policy
Types always pass. Do not blame pre-existing errors. Fix or revert.
WE USE VITEST - NOT BUN:TEST
This is non-negotiable. Never use bun:test imports or APIs.
// ✅ CORRECT - Vitest
import { describe, it, expect, vi, beforeEach } from 'vitest'
// ❌ WRONG - bun:test (DO NOT USE)
import { describe, it, expect, mock } from 'bun:test'
Test commands
# All tests via Turborepo
bun run test
# Filtered by package
bun run test --filter=@skillrecordings/core
bun run test --filter=web
# Direct Vitest (when you need fine-grained control)
bun run test:all
bun run test:all -- -t "name of test"
bun run test:all -- packages/core/src/tools/process-refund.test.ts
Common Vitest patterns
// Mocking
const mockFn = vi.fn()
vi.mocked(someModule).someMethod.mockResolvedValue(result)
// Hoisting mocks (required for factory functions)
const mockClient = vi.hoisted(() => ({ method: vi.fn() }))
vi.mock('./client', () => ({ client: mockClient }))
// Spying
vi.spyOn(object, 'method').mockImplementation(...)
Notes to include in the response
- Which test you wrote first.
- The command used to hit red and green.
- Any refactor that changed structure but not behavior.
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/tdd-red-green-refactor-mmbizjlk/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/tdd-red-green-refactor-mmbizjlk' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/tdd-red-green-refactor-mmbizjlk/download' --output '.skill-downloads/tdd-red-green-refactor-mmbizjlk/SKILL.md.part' && mv '.skill-downloads/tdd-red-green-refactor-mmbizjlk/SKILL.md.part' '.skill-downloads/tdd-red-green-refactor-mmbizjlk/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.
Outils déclarés par l’auteur (à vérifier dans votre agent) : Read, Grep, Glob, Edit, Write, Bash
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
Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.
Claude Code
test -f '.skill-downloads/tdd-red-green-refactor-mmbizjlk/SKILL.md' && test -s '.skill-downloads/tdd-red-green-refactor-mmbizjlk/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/tdd-red-green-refactor' && cp -R '.skill-downloads/tdd-red-green-refactor-mmbizjlk' '.claude/skills/tdd-red-green-refactor'Cursor
test -f '.skill-downloads/tdd-red-green-refactor-mmbizjlk/SKILL.md' && test -s '.skill-downloads/tdd-red-green-refactor-mmbizjlk/SKILL.md' && mkdir -p '.cursor/skills' && test ! -e '.cursor/skills/tdd-red-green-refactor' && cp -R '.skill-downloads/tdd-red-green-refactor-mmbizjlk' '.cursor/skills/tdd-red-green-refactor'Codex
test -f '.skill-downloads/tdd-red-green-refactor-mmbizjlk/SKILL.md' && test -s '.skill-downloads/tdd-red-green-refactor-mmbizjlk/SKILL.md' && mkdir -p '.agents/skills' && test ! -e '.agents/skills/tdd-red-green-refactor' && cp -R '.skill-downloads/tdd-red-green-refactor-mmbizjlk' '.agents/skills/tdd-red-green-refactor'OpenSkills
OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.
Installation officielle d’OpenSkillsopenskills install './.skill-downloads/tdd-red-green-refactor-mmbizjlk'openskills read 'tdd-red-green-refactor-mmbizjlk'La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.
Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.
openskills syncMode 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/tdd-red-green-refactor-mmbizjlk/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.