declare-when-a-setting-takes-effect
A control that saves successfully and changes nothing until a restart is worse than one that fails. Say when it applies, and derive that from where it is read.
Conferred by a reviewer who read the card, not claimed by the file about itself. A card the agent distils during a run that consumed untrusted content is born tainted and is held for review before it is ever retrieved.
When it comes to mind
- adding a settings screen
- the config is cached
- why did my change not apply
- restart required
Avoid and Check are where the value usually is. Do is the section everybody writes.
Trigger
You are exposing a setting in a user interface, and the code that consumes it reads the value at some point other than every use: at process start, when a session is built, or into a cached object.
It does not apply to a setting read on every use. Those apply immediately and should say nothing — a note about a delay that does not exist teaches the same distrust as a missing one.
Do
- For each setting, find the line that reads it. When it applies is a property of that line, not of the control.
- Prefer making it read live. A property that resolves on access usually costs nothing and removes the problem instead of describing it.
- Where it genuinely cannot — something is started at boot — label it, and generate the label from the server or the same module that knows the read site, so the label cannot drift.
- Group the labels into meaningful classes: applies now, applies to your next conversation, applies after a restart.
Avoid
A settings screen that confirms a save and quietly does nothing. It is worse than an error: an error sends the user to look for a cause, while a success sends them to blame the feature, the model, or themselves.
Avoid hard-coding the list of "needs a restart" in the interface. That list is a copy of knowledge that lives elsewhere, and it goes stale the first time a read site moves — silently, which is how the original problem was created.
Avoid a blanket "some settings require a restart" note. It is true, unhelpful, and covers the ones that do not.
Check
Change the setting, use the feature, and observe the behaviour — not the screen. Read a value back from the running system, not from the form you just submitted.
The mechanical version: assert that no setting is labelled as immediate, and that every setting the interface exposes appears in the classification the server publishes.
Risk
Labels add noise to a settings screen, and a screen where every row has a badge is a screen where badges mean nothing. Only the delayed ones need one.
The deeper risk is treating the label as the fix. Declaring that a control is inert until restart is honest; making it live is better, and the label should not become a comfortable way to avoid the harder change.
Use it
The card is data. Clone the repository and import it by path — anything that arrives over the network is treated as tainted and held for approval, which is the behaviour you want and the reason there is no one-line installer here.
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/declare-when-a-setting-takes-effect/SKILL.mdIntegrity
SHA-256 of the file as published. An importer can check that what it received is what this page showed.
32cb01fd5f4b3a07c3f7047803a3eeab4adb3f0e863cb1e0c97e1ea251d2dac9