validate-config-on-every-write
Skill663 starsChanged 23 days agoApache-2.0View on GitHub
Make a rule that the config rebuild enforces on an entity also run before the blob is written, on PUT, /v1/admin/validate and /v1/admin/apply. Use when adding a validation to ConfigPostProcessor or auditing an entity type whose rule runs only at reload.
In this repository7 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- openspec-apply-changeSkill
- openspec-archive-changeSkill
- openspec-exploreSkill
- openspec-proposeSkill
- openspec-sync-specsSkill
- openspec-update-changeSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 1 is distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 23
Put the invariants in one validate<Entity>Invariants(entity, ..., warnings) and call it from the rebuild too, so the gate cannot drift (see …
- Very specific: line 25
Call it before the write on every path.
- Very specific: line 36
Add the requirement to openspec/specs/config-store/spec.md and any operator docs.
- Distinctive: line 42
Do not change the rebuild's behaviour.
≈ “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
Validate on every write path
Arguments: $ARGUMENTS — optionally the entity type (e.g. route, translator) and the rule to enforce (e.g.
BEARER upstream needs a key). With none, audit every entity type for rules that run only at reload.
Rule: whatever the rebuild (ConfigPostProcessor) rejects, a write must reject first.
Why: a rule checked only at reload lets a write store a blob the next rebuild rejects. The caller gets a 500 (apply
says APPLIED), the blob stays, and under onInvalidEntity: abort the pod will not start. Seen with model invariants
(#2001) and route BEARER upstream without a key (#2225).
Steps
- Find the entity's rebuild rules (
processSemantic,validateSingle<Entity>). A rule that reads only the entity is an invariant: hard at every gate. A rule that reads another entity (interceptor names) followssoftValidation. - Put the invariants in one
validate<Entity>Invariants(entity, ..., warnings)and call it from the rebuild too, so the gate cannot drift (seevalidateModelInvariants,validateRouteInvariants). Call it before the write on every path. An empty
-> { }arm or a missinginstanceofbranch is the gap.Path Place Failure PUTConfigResourceController.handlePut, after the secret merge, beforeputResource422viarejectWithValidationWarningsvalidate ConfigValidationService.validateOnlyFAILEDapply ConfigApplyService, before the blob writeFAILEDApplications and toolsets: hook in
ApplicationService/ToolSetService.- Tests in the existing API classes:
PUTgives422,GETgives404, a retry withIf-None-Match: *gives200(nothing was written); an update omitting a secret passes; validate and apply withprecheck: falsegiveFAILED. - Add the requirement to
openspec/specs/config-store/spec.mdand any operator docs.
Traps
PUTchecks the merged entity; apply checks the manifest as sent.- The gate has no entity name yet; keep message prefixes null-safe.
- Do not change the rebuild's behaviour.
Present the plan and wait for approval before editing code; use the OpenSpec flow.
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.

