Your build starts here
Replace bracketed details with your own goal, context, and checks. Keep the first build small enough to inspect.
Diagnose configuration for [local application] by writing an explicit precedence contract for defaults, configuration files, environment variables, and command arguments. Inspect the actual loader rather than assuming a conventional order. Create a fixture where the same harmless setting appears in several layers and include a missing setting, an empty string, an invalid value, and an unknown key. Provide a safe explain-config view that reports the final non-sensitive value or redacted status, the winning source, and validation result; do not dump the complete environment or raw files. Test each override combination and verify startup fails clearly when a required value is invalid. Keep credential values out of output even in error paths. Propose a focused correction if behavior differs from the written policy, then rerun the same fixture matrix and document the final order.Make this prompt yours
Use when local and deployed behavior disagree despite similar files. The application defines precedence; a parser library alone does not define every layer.
You might also hear
- configuration precedence
- explain config
- environment override
- empty setting
- config provenance
The docs behind it
These references explain the underlying concepts and APIs. The prompt templates and project plans are original examples to adapt to your own setup.
Research sources reviewed .
Editorial review · October 28, 2026
Limited: Original instructional template; not executed. ConfigParser documents layered file precedence, while environment/CLI/default precedence remains the application's chosen loader policy; the prompt correctly requires inspecting it.