Synthèse automatique
Ce skill guide l'ajout de validations à chaque couche traversée par une donnée (point d'entrée, logique métier, garde d'environnement, journalisation de débogage) afin de rendre un bug structurellement impossible plutôt que simplement corrigé.
Points forts
- Fournit un cadre clair en quatre couches avec des exemples TypeScript concrets pour chacune
- Décrit une méthode de traçage du flux de données étape par étape pour localiser tous les points de contrôle
- Explique comment tester chaque couche en tentant de contourner la précédente, ce qui évite les fausses impressions de sécurité
- S'appuie sur un cas réel (projectDir vide déclenchant un git init au mauvais endroit) avec les quatre correctifs appliqués
Limites
- Les exemples sont en TypeScript/Node.js ; l'adaptation à d'autres langages ou frameworks reste à la charge de l'utilisateur
- Le skill ne discute pas du coût en duplication ni du moment où arrêter d'empiler les validations
- Ne traite pas des schémas de validation déclaratifs (Zod, JSON Schema) qui pourraient remplacer certains contrôles manuels
À utiliser après avoir corrigé un bug causé par une donnée invalide, lorsqu'on veut empêcher sa réapparition par d'autres chemins d'exécution plutôt que se contenter d'un seul point de contrôle.
À éviter sur du code jetable ou des scripts internes où la multiplication des validations coûte plus cher que le risque réel encouru.
Analyse de sécurité
SûrThe skill contains only instructional guidance and code examples about validation. It declares no tools and performs no execution, network access, file operations, or secret handling. There is no obfuscation or destructive instruction, so listing it poses no meaningful security risk.
Aucun point d'attention détecté
Comment cette analyse est faiteExemples
We just fixed a bug where an empty projectDir made git init run in the repo root. Walk the data flow and add defense-in-depth validation at every layer so it can't happen again.Add entry-point validation to createProject for the workingDirectory argument, and tell me which business-logic and environment guards I should also add downstream.Write tests that try to bypass Layer 1 validation for workspace initialization and confirm Layers 2 and 3 still catch the invalid input.name: defense-in-depth description: Use when invalid data causes failures deep in execution, requiring validation at multiple system layers - validates at every layer data passes through to make bugs structurally impossible
Defense-in-Depth Validation
Overview
When you fix a bug caused by invalid data, adding validation at one place feels sufficient. But that single check can be bypassed by different code paths, refactoring, or mocks.
Core principle: Validate at EVERY layer data passes through. Make the bug structurally impossible.
Why Multiple Layers
Single validation: "We fixed the bug" Multiple layers: "We made the bug impossible"
Different layers catch different cases:
- Entry validation catches most bugs
- Business logic catches edge cases
- Environment guards prevent context-specific dangers
- Debug logging helps when other layers fail
The Four Layers
Layer 1: Entry Point Validation
Purpose: Reject obviously invalid input at API boundary
function createProject(name: string, workingDirectory: string) {
if (!workingDirectory || workingDirectory.trim() === '') {
throw new Error('workingDirectory cannot be empty');
}
if (!existsSync(workingDirectory)) {
throw new Error(`workingDirectory does not exist: ${workingDirectory}`);
}
if (!statSync(workingDirectory).isDirectory()) {
throw new Error(`workingDirectory is not a directory: ${workingDirectory}`);
}
// ... proceed
}
Layer 2: Business Logic Validation
Purpose: Ensure data makes sense for this operation
function initializeWorkspace(projectDir: string, sessionId: string) {
if (!projectDir) {
throw new Error('projectDir required for workspace initialization');
}
// ... proceed
}
Layer 3: Environment Guards
Purpose: Prevent dangerous operations in specific contexts
async function gitInit(directory: string) {
// In tests, refuse git init outside temp directories
if (process.env.NODE_ENV === 'test') {
const normalized = normalize(resolve(directory));
const tmpDir = normalize(resolve(tmpdir()));
if (!normalized.startsWith(tmpDir)) {
throw new Error(
`Refusing git init outside temp dir during tests: ${directory}`
);
}
}
// ... proceed
}
Layer 4: Debug Instrumentation
Purpose: Capture context for forensics
async function gitInit(directory: string) {
const stack = new Error().stack;
logger.debug('About to git init', {
directory,
cwd: process.cwd(),
stack,
});
// ... proceed
}
Applying the Pattern
When you find a bug:
- Trace the data flow - Where does bad value originate? Where used?
- Map all checkpoints - List every point data passes through
- Add validation at each layer - Entry, business, environment, debug
- Test each layer - Try to bypass layer 1, verify layer 2 catches it
Example from Session
Bug: Empty projectDir caused git init in source code
Data flow:
- Test setup → empty string
Project.create(name, '')WorkspaceManager.createWorkspace('')git initruns inprocess.cwd()
Four layers added:
- Layer 1:
Project.create()validates not empty/exists/writable - Layer 2:
WorkspaceManagervalidates projectDir not empty - Layer 3:
WorktreeManagerrefuses git init outside tmpdir in tests - Layer 4: Stack trace logging before git init
Result: All 1847 tests passed, bug impossible to reproduce
Key Insight
All four layers were necessary. During testing, each layer caught bugs the others missed:
- Different code paths bypassed entry validation
- Mocks bypassed business logic checks
- Edge cases on different platforms needed environment guards
- Debug logging identified structural misuse
Don't stop at one validation point. Add checks at every layer.
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/defense-in-depth-validation-mrx3xzty/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/defense-in-depth-validation-mrx3xzty' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/defense-in-depth-validation-mrx3xzty/download' --output '.skill-downloads/defense-in-depth-validation-mrx3xzty/SKILL.md.part' && mv '.skill-downloads/defense-in-depth-validation-mrx3xzty/SKILL.md.part' '.skill-downloads/defense-in-depth-validation-mrx3xzty/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
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/defense-in-depth-validation-mrx3xzty/SKILL.md' && test -s '.skill-downloads/defense-in-depth-validation-mrx3xzty/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/defense-in-depth' && cp -R '.skill-downloads/defense-in-depth-validation-mrx3xzty' '.claude/skills/defense-in-depth'Cursor
test -f '.skill-downloads/defense-in-depth-validation-mrx3xzty/SKILL.md' && test -s '.skill-downloads/defense-in-depth-validation-mrx3xzty/SKILL.md' && mkdir -p '.cursor/skills' && test ! -e '.cursor/skills/defense-in-depth' && cp -R '.skill-downloads/defense-in-depth-validation-mrx3xzty' '.cursor/skills/defense-in-depth'Codex
test -f '.skill-downloads/defense-in-depth-validation-mrx3xzty/SKILL.md' && test -s '.skill-downloads/defense-in-depth-validation-mrx3xzty/SKILL.md' && mkdir -p '.agents/skills' && test ! -e '.agents/skills/defense-in-depth' && cp -R '.skill-downloads/defense-in-depth-validation-mrx3xzty' '.agents/skills/defense-in-depth'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/defense-in-depth-validation-mrx3xzty'openskills read 'defense-in-depth-validation-mrx3xzty'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/defense-in-depth-validation-mrx3xzty/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.
Bonnes pratiques React Hook Form
Developpement
Maîtrisez React Hook Form : évitez les anti-patterns, gérez les abonnements, et traitez correctement reset, dirty state et entrées contrôlées.
Migration Emotion vers Mantine
Developpement
Migrer les styled-components Emotion vers des composants Mantine avec style props et modules CSS. Pour convertir .styled.tsx ou supprimer les imports @emotion.
Détecteur de dérive de périmètre
Developpement
Analyse les diffs git par rapport à une intention pour détecter la dérive de périmètre, fichiers non liés et PR trop larges, puis suggère de garder, diviser ou justifier.