跳到正文
cccskills
免费在 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.

中文简介正在准备中。当前显示原文说明。

y3owk1n/neru星标 873(GitHub 873 + cccskills 0)

实测评分 未实测

查看安装方法

包含的文件(2)

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

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

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.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

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.

中文简介正在准备中。当前显示原文说明。

y3owk1n/neru8732026年10月26日 更新

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.

中文简介正在准备中。当前显示原文说明。

y3owk1n/neru8732026年10月26日 更新

neru-ask

免费

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.

中文简介正在准备中。当前显示原文说明。

y3owk1n/neru8732026年10月26日 更新

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.

中文简介正在准备中。当前显示原文说明。

y3owk1n/neru8732026年10月26日 更新

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.

中文简介正在准备中。当前显示原文说明。

y3owk1n/neru8732026年10月26日 更新

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.

中文简介正在准备中。当前显示原文说明。

y3owk1n/neru8732026年10月26日 更新

查看 y3owk1n 的全部技能

报告此技能的问题