auto-silent-defaults

Enforce fail-on-missing required data and null for optional fields.

6|Updated Mar 31, 2026
One-click install
npx skills add https://github.com/Corvalis-LLC/Crow-Stack --skill auto-silent-defaults
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: auto-silent-defaults
Source: https://github.com/Corvalis-LLC/Crow-Stack/tree/main/skills/auto-silent-defaults
Command: npx skills add https://github.com/Corvalis-LLC/Crow-Stack --skill auto-silent-defaults

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Data handling often masks issues by substituting default values, leading to silent failures and hard-to-trace bugs. This Skill enforces failing on missing required data, returning null/None for optional data, and applying safe, correct defaults only when guaranteed to be appropriate.

Core Features & Use Cases

  • Enforces strict startup validation for required config fields.
  • Propagates None/null for optional fields while keeping explicit defaults.
  • Provides guidance for refactoring code to avoid unwrap_or_default and similar pitfalls.

Quick Start

Apply strict handling: fail on missing required data, return null for optional data, and only use legitimate defaults where appropriate.

Frequently Asked Questions about auto-silent-defaults

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
Why does using default values for missing config fields cause silent failures in production?

Substituting default values masks missing data, causing silent failures and hard-to-trace bugs. Enforcing strict validation surfaces missing required fields as errors and returns null for optional fields, ensuring deterministic behavior in production.

How do I handle missing required data and optional fields during config loading?

Fail immediately on missing required data to expose errors early, return null for optional fields, and apply safe defaults only when guaranteed appropriate. This ensures deterministic behavior across config loading, data parsing, and function results.

What is the best way to avoid unwrap_or_default pitfalls when refactoring code?

Refactor code to eliminate unwrap_or_default patterns by enforcing strict validation rules. Surface missing required data as errors, propagate null for optional fields, and apply conservative defaults only when explicitly appropriate.

Does this validation approach work for both config loading and data parsing?

Yes, this validation discipline applies across config loading, data parsing, and function results. It enforces failing on missing required data and returning null for optional data to ensure deterministic behavior throughout your application.

When should I not use safe defaults for missing data handling?

Avoid using defaults when data is required for startup or critical operations. Defaulting should only occur when guaranteed appropriate; required fields must surface as errors to prevent silent failures and maintain conservative defaulting rules.