settings-config

Skill: settings-config

Core position

This skill creates clean, production-ready application configuration management using pydantic-settings.

It enforces disciplined configuration patterns that prevent common problems such as:

• configuration drift
• unclear env var naming
• environment-specific branching
• accidental secrets in code

The skill favors minimal, explicit configuration surfaces and ensures configuration is:

• typed
• validated
• environment-driven
• testable

---

Goals

Produce a configuration system that:

1. Centralizes configuration in a single settings module
2. Uses typed settings via pydantic
3. Reads configuration from environment variables
4. Allows .env usage in local development
5. Avoids configuration logic scattered across the codebase

---

Step 0 — Inspect the existing project first

Before generating anything:

1. Check whether a config.py or settings.py already exists. If it does, extend it rather than creating a parallel one.

2. Note the existing package layout. If the project was scaffolded with fastapi-init, config lives at {pkg_name}/core/config.py — use that path, not app/config.py.

3. Check whether an env_prefix is already in use anywhere (env_prefix=, os.getenv("XYZ_, existing .env keys). If one exists, adopt it.

4. Check whether .env loading is already part of the project convention (for example a real .env file used locally, documented setup instructions, or an explicit user request). If so, adopt env_file=".env" in the config.

   Do not assume that the presence of .env.example alone means .env should be automatically loaded at runtime.

5. Only create new files if no config module is present.

---