specx-settings

Name: specx-settings
Author: maksimzayats

199stars36forks

How to install specx-settings?

maksimzayats/specx/specx-settings

$npx -y skills add maksimzayats/specx --skill specx-settings

Installs into the current project.

Summary

Add runtime configuration to specx Python services with pydantic-settings. Use when creating settings classes, environment variables, .env.example, injecting settings at delivery, infrastructure, or composition edges, documenting config, mapping configuration into typed core

Files · 1

View on GitHub

SKILL.md

1	# specx Settings
2
3	Use this skill whenever runtime configuration is needed. Read
4	`references/settings.md` before adding settings code.
5
6	## Rules
7
8	- Model runtime config with classes that inherit `BaseRuntimeSettings`.
9	- Give each settings class a docstring that explains the configuration scope
10	and includes a concrete `Example:`.
11	- Place settings near the class that consumes them unless the setting is truly
12	application-wide.
13	- Logging settings are application-wide and live beside
14	`infrastructure/logging/configurator.py` and its `LoggingConfigurator`.
15	- Use `BaseStrEnum` for finite configuration values such as logging levels.
16	- Inject settings objects only into delivery, infrastructure, and composition
17	classes. Do not inject `BaseRuntimeSettings` subclasses into core use cases,
18	services, capabilities, entities, repositories, or gateway ports.
19	- When configuration represents a genuine business policy, map it at the
20	composition root into a typed core value or capability that has no dependency
21	on Pydantic or `BaseRuntimeSettings`.
22	- Let `diwire` auto-register settings as root-scoped singletons. Register a
23	settings instance explicitly only for an intentional override.
24	- At operational entrypoints, load required runtime values with
25	`SettingsClass.from_environment()`. Build explicit test or composition
26	overrides with `SettingsClass.model_validate({...})` so strict type checking
27	does not mistake raw input strings for already-validated field types.
28	- Do not read `os.environ` outside settings classes or composition code.
29	- Use clear environment variable names and safe defaults only when safe.
30	- Type secret fields with `SecretStr`, keep secrets out of examples, and unwrap
31	them only at the adapter call that needs the raw value.
32	- Update `.env.example` when adding user-provided environment variables.
33	- Isolate settings-source tests from a developer's `.env` by changing to
34	`tmp_path`, then override environment values with `monkeypatch`.
35	- Do not inherit raw `BaseSettings`; inherit
36	`specx.infrastructure.foundation.settings.BaseRuntimeSettings`.
37
38	## Code Style
39
40	Use blank lines as logical separators in all code. Keep related statements
41	together, but separate independent setup, action, assertion, response, branch,
42	and transformation groups so long blocks stay readable.
43
44	## References
45
46	- `references/settings.md` - settings placement, examples, env naming, and test
47	overrides.

People who liked this also viewed

6 picks

Type

specx-settings

199stars36forks

View on GitHub

How to install specx-settings?

maksimzayats/specx/specx-settings

$npx -y skills add maksimzayats/specx --skill specx-settings

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# specx Settings
2
3	Use this skill whenever runtime configuration is needed. Read
4	`references/settings.md` before adding settings code.
5
6	## Rules
7
8	- Model runtime config with classes that inherit `BaseRuntimeSettings`.
9	- Give each settings class a docstring that explains the configuration scope
10	and includes a concrete `Example:`.
11	- Place settings near the class that consumes them unless the setting is truly
12	application-wide.
13	- Logging settings are application-wide and live beside
14	`infrastructure/logging/configurator.py` and its `LoggingConfigurator`.
15	- Use `BaseStrEnum` for finite configuration values such as logging levels.
16	- Inject settings objects only into delivery, infrastructure, and composition
17	classes. Do not inject `BaseRuntimeSettings` subclasses into core use cases,
18	services, capabilities, entities, repositories, or gateway ports.
19	- When configuration represents a genuine business policy, map it at the
20	composition root into a typed core value or capability that has no dependency
21	on Pydantic or `BaseRuntimeSettings`.
22	- Let `diwire` auto-register settings as root-scoped singletons. Register a
23	settings instance explicitly only for an intentional override.
24	- At operational entrypoints, load required runtime values with
25	`SettingsClass.from_environment()`. Build explicit test or composition
26	overrides with `SettingsClass.model_validate({...})` so strict type checking
27	does not mistake raw input strings for already-validated field types.
28	- Do not read `os.environ` outside settings classes or composition code.
29	- Use clear environment variable names and safe defaults only when safe.
30	- Type secret fields with `SecretStr`, keep secrets out of examples, and unwrap
31	them only at the adapter call that needs the raw value.
32	- Update `.env.example` when adding user-provided environment variables.
33	- Isolate settings-source tests from a developer's `.env` by changing to
34	`tmp_path`, then override environment values with `monkeypatch`.
35	- Do not inherit raw `BaseSettings`; inherit
36	`specx.infrastructure.foundation.settings.BaseRuntimeSettings`.
37
38	## Code Style
39
40	Use blank lines as logical separators in all code. Keep related statements
41	together, but separate independent setup, action, assertion, response, branch,
42	and transformation groups so long blocks stay readable.
43
44	## References
45
46	- `references/settings.md` - settings placement, examples, env naming, and test
47	overrides.

People who liked this also viewed

6 picks

Type