Skip to content
cccskills
FreePublished on GitHub

neru-add-config-option

Add or change a Neru config.toml option end to end: struct field, shared and platform defaults, validation, examples, docs, and hot-reload behavior. Use whenever a change adds, renames, or removes a key in the TOML config schema. Not for theme palette entries or CLI flags.

The English summary is being prepared. Showing the original description.

y3owk1n/neru873 stars(GitHub 873 + cccskills 0)

Run score Not tested

See how to install

Files included (2)

  • SKILL.md6.2 KB
  • agents/openai.yaml277 B

SKILL.md (original)

Review the instructions the agent will receive before you install.

Adding a config option to Neru

Config changes fail in review when one link of the chain is missing, such as a default that exists on macOS but not Linux, a validator that never runs, or an example file that still shows the old key. internal/config/AGENTS.md states the contract and which test fails per link. This skill gives the order to do it in.

Five steps are universal. Then check the conditional four, the ones that turn a one-line option into a ten-file one, and that no guide used to name.

The universal five

  1. Schema. Add the struct field in internal/config/config.go with a toml:"snake_case_name" tag matching the surrounding section. Follow the existing nesting. Options live in their feature's sub-struct, not at root. Then run just genschema, which renders the field into schemas/config.schema.json for editors. TestConfigSchema_IsGeneratedFromTheConfigStructs fails until you do.
  2. Shared default. Set it in newDefaultConfig() in internal/config/config_defaults.go. Assign the field by name even when the value you assign is the zero value, and say in a comment what the zero means, because a zero nobody wrote cannot be told from a forgotten one. TestEverySchemaFieldHasAnExplicitDefault fails on an omission.
  3. Example. Add the line to configs/default-config.toml, which is the file a user copies. Comment it out if the option has no default, because an uncommented empty value asserts a default that does not exist. TestConfigOptionsAppearInTheDefaultExample fails when the line is missing. Update the mode-specific examples (grid-only-config.toml, hints-only-config.toml, recursive-grid-only-config.toml) only if they show the affected section. They are deliberately partial, and only their keys are checked, by TestShippedExamplesWriteOnlySchemaKeys. Those four are the whole shipped set. configs/embed.go lists them, and anything else in configs/ is a working file rather than a project artifact. Only default-config.toml is embedded, and the rest are read from disk by the tests that check them.
  4. Docs. Add the row to docs/reference/configuration.md. That file is the single home for config reference facts. Do not also describe the option in docs/contributing/architecture.md or README. No test catches a missing row. This is the one universal link a reviewer has to check by eye.
  5. Platform column. Add the option's path to PlatformSupport() in internal/config/platform_support.go, saying which of macOS, Linux and Windows writing it actually does something on. Say so even when the answer is all three, because a column nobody wrote cannot be told from a forgotten one, and TestEveryConfigOptionDeclaresItsPlatformSupport fails on an option that is neither. A narrower column needs a note saying why, in the words the user reads, because it reaches the load-time warning, the neru doctor platform_support row and the published table, which you regenerate with just gensupportref. A config.Color is declared at the field, not at its light and dark leaves (docs/adr/0013-parity-is-measured-in-words-not-subsystems.md).

Steps 2 and 3 exempt three shapes, and an option with one of them passes both tests whether or not you do the work: the light/dark leaves under a Color, a collection that ships empty, and any field of a repeated table nobody ships entries for (app_configs, layers). Do the work anyway. See internal/config/AGENTS.md.

The conditional four

Each is skippable, and each is a whole file when it is not.

  • Platform override. If a platform needs a different default, set it in applyPlatformDefaults() in the matching config_<os>.go (config_darwin.go, config_linux.go, config_windows.go, config_other.go). Both layers are reached via DefaultConfig() in config_platform.go, so never call newDefaultConfig() directly from feature code. Nothing checks this, so pin the difference in a test.
  • Validator. Add checks to the relevant Validate* method on *Config in internal/config/validators_*.go (hints, grid, style, hotkeys, macros, pointer, appconfig, …). Invalid values must fail validation with a clear message, not get silently clamped. New enum-ish strings get an allowlist. A brand-new Validate* method must be called from ValidateWithWarnings in validate.go, or TestEveryConfigValidatorRunsInTheLadder fails.
  • Derivation helper. If the value the daemon runs on is not the value the user writes, resolve it once after the configuration is assembled rather than in each consumer. internal/config/grid_labels.go and held_repeat.go are the worked examples. The declared default stays what a user would type.
  • Cross-field rule. If the option only makes sense alongside another, and a user could act on the mismatch, collect it into Warnings so it rides out on LoadResult and reaches neru config validate. logger.Warn reaches nobody (ADR 0002, docs/adr/0002-severity-tiered-config-validation.md).

Hot reload

Config is hot-reloadable via internal/config/loader (load/watch/persist/ set-field). If the option should be settable at runtime with neru config set, confirm the field path resolves through the loader's set-field lookup. If it intentionally requires a restart, say so in the docs.

Tests

  • Table-driven validator tests next to the validator you touched (validators_*_test.go), covering the default, a valid custom value, and at least one rejected value.
  • If the default differs per platform, pin it in config_defaults_test.go or the platform-tagged config test.

Verify

just test-foundation    # the fast cross-platform-safe slice

That one recipe now runs every package this skill's guardrails live in: the config package, its loader, and internal/architecture.

Then the standard pre-commit gate from AGENTS.md.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Add a Neru CLI command or flag: cobra command in internal/cli, IPC handler in internal/app/ipcctrl, service/mode work behind it, man pages, and docs/reference/cli.md. Use when adding or changing user-facing commands, subcommands, or flags. Not for config.toml options.

The English summary is being prepared. Showing the original description.

y3owk1n/neru873Updated Oct 26, 2026

Implement or stub Neru functionality for a specific OS/backend: port contract, build-tagged file slots, factory wiring, CodeNotSupported stubs, capability matrix, contract tests, and the docs ownership table. Use for any change under internal/adapter/platform or any *_darwin/_linux/_windows file. Not for pure-Go domain logic.

The English summary is being prepared. Showing the original description.

y3owk1n/neru873Updated Oct 26, 2026

Answer a Neru user's question about what Neru does, which command, flag, or config key does a thing, why something does not work, or what to try next, from the help, man pages, and docs of their installed version rather than from memory. Routes config work to neru-setup-config. Use when a Neru user asks what Neru can do, how to do something with it, which command to run, why hints or a hotkey do nothing, or which skill to use.

The English summary is being prepared. Showing the original description.

y3owk1n/neru873Updated Oct 26, 2026

Help a Neru user build a tool on top of Neru, such as a status bar, a launcher, voice control, a companion UI, automation from another hotkey tool, a Go program, or a client for the IPC socket in another language. Picks the interface, checks the installed version has it, reads the contract from that version's docs, and runs the result against the live daemon. Routes config and hooks work to neru-setup-config. Use when a Neru user wants to script Neru, read its state, follow its events, drive it from another program, or write code against its CLI, socket, or Go client.

The English summary is being prepared. Showing the original description.

y3owk1n/neru873Updated Oct 26, 2026

Commit working changes and open a Neru pull request the maintainer's way: conventional commit subjects, a PR title written for the changelog, the just ci gate, and the repo PR template filled honestly. Use when asked to commit, create a PR, open a pull request, or ship finished work in this repo.

The English summary is being prepared. Showing the original description.

y3owk1n/neru873Updated Oct 26, 2026

File a Neru bug report or feature request that matches the repo's issue forms: duplicate check first, every required field filled with real diagnostics, correct labels. Use when asked to open, file, or draft a GitHub issue for Neru. Not for pull requests.

The English summary is being prepared. Showing the original description.

y3owk1n/neru873Updated Oct 26, 2026

See all skills by y3owk1n

Report a problem with this skill