Skill — Defense in Depth

When this skill activates

Any task that introduces or modifies code handling external input, enforcing business rules, managing environment-specific behavior, or adding observability. Activate whenever you are building anything that crosses a trust boundary or touches validation logic at any layer of the stack.

Mandatory actions when this skill is active

Four independent validation layers must be applied. Each layer is autonomous: failure or absence in one layer does NOT exempt the others.

Layer 1 — Entry Point Validation

Apply at the API boundary (route handler, CLI argument parser, event handler):

• Schema validation using a strict schema library (Zod, Joi, Pydantic, etc.)
• Type coercion with explicit rules (string-to-number only where defined)
• Reject invalid input immediately with a 400-level response
• Never pass unvalidated input deeper into the system
• Strip unknown fields; never allow arbitrary pass-through

Layer 2 — Business Logic Guards

Apply inside domain/service layer functions:

• Assert domain invariants (e.g., balance >= 0, state transitions are valid)
• State machine guards: verify current state allows the requested transition
• Authorization assertions: re-check permissions at the service boundary
• Fail loudly with descriptive errors when invariants are violated
• Never rely solely on entry point validation; business logic must self-protect

Layer 3 — Environment Guards

Apply environment-specific behavior through configuration, not conditionals:

• Production: strict mode, no debug endpoints exposed, minimal error detail

in responses, all logging structured and shipped to aggregator

• Staging: production-like but with extended logging and feature flags
• Test: relaxed logging, verbose error output, mock services allowed
• Guard debug endpoints behind environment checks (never reachable in prod)
• Validate required environment variables at startup; crash early if missing

Layer 4 — Debug Instrumentation

Apply observability that aids debugging without compromising security:

• Structured logging with consistent fields (timestamp, traceId, userId, action)
• Trace IDs propagated through all layers (generate at entry point, pass down)
• Development assertions (enabled in test/dev, compiled out or disabled in prod)
• Never log secrets, tokens, passwords, or full request bodies in production
• Include enough context to reproduce issues from logs alone

Independence principle

Each layer must function correctly even if the others are absent. This means:

• Business logic must not assume entry point already validated
• Environment guards must not assume instrumentation is active
• Instrumentation must not assume any specific validation has occurred
• Entry point validation must not assume business logic will catch overflows

Self-check before task completion

Before marking a task done when this skill was active:

• [ ] Did I validate at the entry point (schema, types, rejection of invalid)?
• [ ] Did I add business logic guards (invariants, state checks, auth assertions)?
• [ ] Did I implement environment guards (prod strict, test relaxed, no debug in prod)?
• [ ] Did I include debug instrumentation (structured logs, trace IDs, assertions)?
• [ ] Are all four layers independent (no layer relies on another for correctness)?
• [ ] Did I verify that secrets are never exposed in any logging layer?