go-viper
Skill2 starsChanged 7 months agoMITView on GitHub
Write, debug, and explain Go configuration code with `github.com/spf13/viper`. Use this skill whenever the user mentions Viper, `viper`, config structs, reading config from files plus env vars plus flags, Cobra or `pflag` integration, unmarshaling into structs, env key replacers, config precedence, config watching, or a clean Viper bootstrap.
In this repository26 other files it gives its agents.
- other/AGENTS.mdAGENTS.md
- beamng-modsSkill
- bootstrap-vueSkill
- charmbraceletSkill
- depsdotdevSkill
- find-domainSkill
- github-cliSkill
- go-cobraSkill
- goreleaserSkill
- kasettoSkill
- laravel-actionsSkill
- lefthookSkill
- miseSkill
- pelican-panel-pluginsSkill
- php-monorepo-builderSkill
- php-saloonSkill
- prd-todo-slicerSkill
- prd-to-kandev-tasksSkill
- qodo-mergeSkill
- release-pleaseSkill
- rewrite-in-goSkill
- shieldsioSkill
- skill-researcherSkill
- skill-scoutSkill
- taskfileSkill
- website-visual-testingSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 4 are distinctive, and 10 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
10
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 9
Use this skill to produce a clean Viper setup that reads configuration from file, flags, and environment with Viper's normal precedence:
- Very specific: line 20
Prefer viper.New() over the package global.
- Very specific: line 22
Keep configuration bootstrap in one place such as internal/config or pkg/config with a Load(...) function.
- Distinctive: line 23
Treat the config file as optional only when the app design allows it.
- Distinctive: line 28
When writing a Viper-based loader, follow this order:
- Very specific: line 30
Create an instance with v := viper.New().
- Very specific: line 37
Call Unmarshal(&cfg) into a typed struct.
- Very specific: line 42
Use mapstructure tags on struct fields when file keys differ from Go field names.
- Very specific: line 46
Add all config paths before ReadInConfig() and before WatchConfig().
- Distinctive: line 47
If the user uses Cobra, bind command flags directly from the command's flag set.
- Very specific: line 48
If the user wants testable code, return both the typed config and the configured *viper.Viper only when the caller truly needs both.
- Very specific: line 59
Read references/clean-config-pattern.md for the recommended package shape, loader order, validation strategy, testing guidance, and common …
- Very specific: line 60
Read references/file-env-flag-precedence.md when the task is specifically about how file, env, and flags interact or why one source wins …
- Very specific: line 61
Read examples/clean_setup.go for a compact end-to-end loader example.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Use this skill to produce a clean Viper setup that reads configuration from file, flags, and environment with Viper's normal precedence:
- explicit
Set - flags
- environment variables
- config file
- remote key/value store
- defaults
Core approach
- Prefer
viper.New()over the package global; build one configured instance and pass it where needed. - Define a typed
Configstruct and unmarshal into it after all defaults, file paths, env bindings, and flag bindings are configured. - Keep configuration bootstrap in one place such as
internal/configorpkg/configwith aLoad(...)function. - Treat the config file as optional only when the app design allows it; otherwise return a clear error.
- Bind flags and env explicitly for important keys, and use
AutomaticEnv()plus an env key replacer for the general case.
Clean Viper bootstrap
When writing a Viper-based loader, follow this order:
- Create an instance with
v := viper.New(). - Set config file name, type if needed, and search paths.
- Set defaults with
SetDefault. - Configure env loading with
SetEnvPrefix,SetEnvKeyReplacer,AutomaticEnv, andBindEnvfor special keys. - Define and parse
pflagor Cobra flags, then bind them withBindPFlagorBindPFlags. - Call
ReadInConfig(). - Handle
viper.ConfigFileNotFoundErrorseparately from parse errors when the file is optional. - Call
Unmarshal(&cfg)into a typed struct. - Validate the resulting struct if the app has required fields or constraints.
Implementation rules
- Use
mapstructuretags on struct fields when file keys differ from Go field names. - For nested keys that should map to env vars, use
strings.NewReplacer(".", "_", "-", "_")withSetEnvKeyReplacer. - Remember that env vars are case-sensitive and are read when accessed, not cached at bind time.
- Remember that Viper does not deep-merge complex values; later sources replace the whole value.
- Add all config paths before
ReadInConfig()and beforeWatchConfig(). - If the user uses Cobra, bind command flags directly from the command's flag set.
- If the user wants testable code, return both the typed config and the configured
*viper.Viperonly when the caller truly needs both; otherwise return just the typed config.
Output expectations
- Give a small, production-leaning config package, not scattered snippets.
- Show how file, env, and flags work together in one example.
- Make precedence explicit in the explanation.
- Mention the exact env var names and flag names generated or bound.
References
- Read
references/clean-config-pattern.mdfor the recommended package shape, loader order, validation strategy, testing guidance, and common pitfalls. - Read
references/file-env-flag-precedence.mdwhen the task is specifically about how file, env, and flags interact or why one source wins over another. - Read
examples/clean_setup.gofor a compact end-to-end loader example.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

