defense-in-depth
Skill4 starsChanged 15 days agoMITView on GitHub
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
- Reads credentials
We split this skill into the rules it gives an agent
7 rules. 7 are common, 0 are distinctive, and 0 are very specific to this project.
7
Common
Most of the 3 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Common: line 10
When you fix a bug caused by invalid data, adding validation at one place feels sufficient.
- Common: line 46
Purpose: Ensure data makes sense for this operation
- Common: line 94
When you find a bug:
- Common: line 106
Test setup → empty string
- Common: line 117
Result: All 1847 tests passed, bug impossible to reproduce
- Common: line 121
All four layers were necessary.
- Common: line 127
Don't stop at one validation point: Add checks at every layer.
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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.
Other versions6 projects use a version of this.
Word for word · 3
- OpenxIntelligence/Coding-Agent-Skills★ 4100% same
- kntism/skills★ 1100% same
- davidanthonyn/claude-skills★ 0100% same
Edited · 2
- PracticalSwan/agent-skills★ 2256% same
- Crumbgrabber/llm_system_template_agents_skills_patterns_tools_prompts★ 3100% same
Wrote their own version · 1
- liujiarui0918/claude-code-codex-strongest★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository169 other files it gives its agents.
- epub-skill/CLAUDE.mdCLAUDE.md
- linear-cli-skill/CLAUDE.mdCLAUDE.md
- AgentDB Advanced FeaturesSkill
- AgentDB Learning PluginsSkill
- AgentDB Memory PatternsSkill
- AgentDB Performance OptimizationSkill
- AgentDB Vector SearchSkill
- agent-evalSkill
- agentic-jujutsuSkill
- agile-product-ownerSkill
- ai-tool-pickerSkill
- algorithmic-artSkill
- api-connectorSkill
- api-design-patternsSkill
- architecture-diagram-creatorSkill
- article-extractorSkill
- aws-agentic-aiSkill
- aws-cdk-developmentSkill
- aws-cost-operationsSkill
- aws-serverless-edaSkill
- biogeobearsSkill
- brainstormingSkill
- brand-guidelinesSkill
- canvas-designSkill
- capa-officerSkill
- ceo-advisorSkill
- changelog-generatorSkill
- code-auditorSkill
- codebase-documenterSkill
- code-executionSkill
- code-explainerSkill
- code-refactorSkill
- code-reviewerSkill
- code-transferSkill
- content-creatorSkill
- content-research-writerSkill
- conversation-analyzerSkill
- csv-data-summarizerSkill
- cto-advisorSkill
- d3-vizSkill
- dashboard-creatorSkill
- deploy-itSkill
- developer-growth-analysisSkill
- dispatching-parallel-agentsSkill
- doc-coauthoringSkill
- docxSkill
- domain-name-brainstormerSkill
- dwa-councilSkill
- error-fixerSkill
- escalation-reasoningSkill
- evaluator-optimizerSkill
- executing-plansSkill
- extract-from-pdfsSkill
- fda-consultant-specialistSkill
- feature-planningSkill
- file-operationsSkill
- file-organizerSkill
- finishing-a-development-branchSkill
- firebase-buddySkill
- flowchart-creatorSkill
- The first 60 shown.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

