agentleFS
aaronfloreyaaronflorey/agent-skills/skills/go-viper/SKILL.md

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.

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
  1. Distinctive:

    Use this skill to produce a clean Viper setup that reads configuration from file, flags, and environment with Viper's normal precedence:

    line 9
  2. Very specific:

    Prefer viper.New() over the package global.

    line 20
  3. Very specific:

    Keep configuration bootstrap in one place such as internal/config or pkg/config with a Load(...) function.

    line 22
  4. Distinctive:

    Treat the config file as optional only when the app design allows it.

    line 23
  5. Distinctive:

    When writing a Viper-based loader, follow this order:

    line 28
  6. Very specific:

    Create an instance with v := viper.New().

    line 30
  7. Very specific:

    Call Unmarshal(&cfg) into a typed struct.

    line 37
  8. Very specific:

    Use mapstructure tags on struct fields when file keys differ from Go field names.

    line 42
  9. Very specific:

    Add all config paths before ReadInConfig() and before WatchConfig().

    line 46
  10. Distinctive:

    If the user uses Cobra, bind command flags directly from the command's flag set.

    line 47
  11. Very specific:

    If the user wants testable code, return both the typed config and the configured *viper.Viper only when the caller truly needs both.

    line 48
  12. Very specific:

    Read references/clean-config-pattern.md for the recommended package shape, loader order, validation strategy, testing guidance, and common …

    line 59
  13. Very specific:

    Read references/file-env-flag-precedence.md when the task is specifically about how file, env, and flags interact or why one source wins …

    line 60
  14. Very specific:

    Read examples/clean_setup.go for a compact end-to-end loader example.

    line 61

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Use this skill to produce a clean Viper setup that reads configuration from file, flags, and environment with Viper's normal precedence:

  1. explicit Set
  2. flags
  3. environment variables
  4. config file
  5. remote key/value store
  6. defaults

Core approach

  • Prefer viper.New() over the package global; build one configured instance and pass it where needed.
  • Define a typed Config struct 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/config or pkg/config with a Load(...) 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:

  1. Create an instance with v := viper.New().
  2. Set config file name, type if needed, and search paths.
  3. Set defaults with SetDefault.
  4. Configure env loading with SetEnvPrefix, SetEnvKeyReplacer, AutomaticEnv, and BindEnv for special keys.
  5. Define and parse pflag or Cobra flags, then bind them with BindPFlag or BindPFlags.
  6. Call ReadInConfig().
  7. Handle viper.ConfigFileNotFoundError separately from parse errors when the file is optional.
  8. Call Unmarshal(&cfg) into a typed struct.
  9. Validate the resulting struct if the app has required fields or constraints.

Implementation rules

  • Use mapstructure tags on struct fields when file keys differ from Go field names.
  • For nested keys that should map to env vars, use strings.NewReplacer(".", "_", "-", "_") with SetEnvKeyReplacer.
  • 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 before WatchConfig().
  • 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.Viper only 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.md for the recommended package shape, loader order, validation strategy, testing guidance, and common pitfalls.
  • Read references/file-env-flag-precedence.md when the task is specifically about how file, env, and flags interact or why one source wins over another.
  • Read examples/clean_setup.go for a compact end-to-end loader example.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.