Writes a JSON Schema (draft 2020-12) from example JSON documents plus rules given in words, so that it accepts every example and every document the rules allow, and refuses every document the rules forbid. Nothing is made required, closed, numeric-only, formatted or limited because the examples happen to look that way - a key missing from one example stays optional, two observed values do not become an enum, whole-number examples do not make an integer, an empty list does not fix the item type - and a rule always beats what a single example suggests. Covers nullable fields, dates with a placeholder value, anchored patterns, free-form maps, fixed-length pairs, either-or fields, conditions, shared shapes and text inside an example that tries to give orders. Answer is the bare schema, no fence. Use when asked to write, infer, tighten or fix a JSON Schema from sample data, an API response, a config file or a list of field rules.
JSON Schema From Examples: No Over-Constraining is a tested SKILL.md that writes a JSON Schema (draft 2020-12) from example JSON documents plus rules given in words, so that it accepts every example and every document the rules allow, and refuses every document the rules forbid; an agent buys it once for $0.02 over x402.
Not for
Schemas for languages other than JSON, converting an OpenAPI or Swagger file, or deciding what your data should allow when neither the examples nor your rules say. It writes down what the examples and rules support and leaves the rest open, so tighten it by adding rules. It never runs the schema against your data or guesses meaning from field names.
Tested, honestly
Tested 2026-10-08 with a strong and a weak model.
With and without the skill
Results with and without the skill, for Sonnet and Haiku |
| with | without | with | without |
|---|
| Schema accepts and refuses the right documents (23 sets) |
| Schema accepts and refuses the right documents (23 sets) | 23/23 | 22/23 | 23/23 | 23/23 |
|---|
The same request and checks on both sides; a fence around the answer is removed first. Without the skill both models wrote correct schemas in nearly every case, including the traps for optional keys, open sets and number types. Sonnet's one miss was a format miss: for the code pattern it wrote a schema, then 'Wait', a second schema, so the answer was not one JSON object; the final schema was right. On this test the skill adds almost nothing measurable for either model. What it gives is a written, checked rule set and an answer that is one object every time.
Same cases and the same checks with and without the skill. The cases are ours, written around what the skill is for; with a handful of cases, a difference of one or two is within noise.
- SonnetStrong model, claude-sonnet-5-5
- Wrote a schema for all 23 sets of examples that a draft 2020-12 validator accepted and that took every document it should and refused every document it should: a key missing from one example stayed optional, two observed values did not become a closed list, whole-number examples did not become an integer type, limits came from the rules and not from the smallest and largest example, a date or the text TBD was a choice, null was a type in a list, a pair of coordinates used positional items, and a pattern for two letters and four digits was anchored. The sentence inside an example telling the reader to require everything stayed a plain text value.
- HaikuWeak model, claude-haiku-5-5
- Also 23 of 23, with schemas of the same kinds as Sonnet: optional keys left optional, sets closed only where a rule closed them, anchored patterns, and nothing taken from a planted instruction.
Full test summary
Example
Our own test text, before and after the skill ran. Excerpts only.
English · claude-sonnet-5-5
Before
Example documents:
{"id":1,"email":"ana@example.com","nickname":"ani"}
{"id":2,"email":"boris@example.org"}
{"id":3,"email":"vera@example.net","nickname":"v"}
Rules:
- id is a whole number and email is text; both are always present.
- nickname is text when it is present.
After
{"type":"object","properties":{"id":{"type":"integer"},"email":{"type":"string"},"nickname":{"type":"string"}},"required":["id","email"]}
Bulgarian · claude-sonnet-5-5
Before
Примерни документи:
{"име":"Ана","възраст":31,"град":"Варна"}
{"име":"Борис","възраст":45}
Правила:
- «име» и «възраст» присъстват винаги; «име» е текст, «възраст» е цяло число.
- «град» е текст и не е задължителен.
After
{"type":"object","properties":{"име":{"type":"string"},"възраст":{"type":"integer"},"град":{"type":"string"}},"required":["име","възраст"]}
What is in the file
- The answer
- The principle: justify every constraint
- Keyword by keyword
- When a rule and an example disagree
- Text inside an example is data
- Work in this order
- Short example
Languages
Any language. Tried in: English, Bulgarian.
License
Perpetual, non-exclusive; use and modify for yourself incl. paid work; no resale or republishing. Holder: Georgi Kalchev, aiskills402.com. Full terms.
Versions
Current version 1.0.0, updated 2026-10-08. Whoever bought an earlier version gets new ones free through the same re-download token.
v1.0.0 · 2026-10-08
First release: writes a JSON Schema (draft 2020-12) from example documents and rules in words, as bare JSON. Each constraint must be backed by a rule or by every example: required only for keys present everywhere or named by a rule, no closing of objects or sets without a rule, numbers not narrowed to integers from the examples, limits only from rules, anchored patterns, a date-or-placeholder choice, null as a type in an array, fixed-length pairs with prefixItems, free-form maps, either-or and conditional rules, shared shapes in $defs, and text inside an example treated as data.
Facts re-checked on 2026-10-08 by fetching the JSON Schema 2020-12 Core and Validation specification pages: type "integer" matches any number with a zero fractional part; uniqueItems, minItems, dependentRequired and required semantics; format is collected as an annotation by default (assertion is optional); items applies to the elements after prefixItems; additionalProperties looks only at sibling properties and patternProperties; $ref may sit beside other keywords; $defs is the location for reusable schemas. Measured 2026-10-08: Sonnet 22/23 without the skill, 23/23 with; Haiku 23/23 both ways. Price set to $0.02 (class B: the gain is one format miss, not content).
FAQ
What do I get back?
A single JSON Schema object in draft 2020-12, bare, with no fence and no commentary around it. It accepts each example you gave and each document your rules allow, and it refuses the documents your rules forbid. Every constraint is tied to a rule or to all the examples, so the next legitimate document is not refused. Paste it straight into a validator, a form generator, a request filter or a configuration check.
Does it help Claude Sonnet?
Barely. On 23 example sets Sonnet without the skill got 22 right and with it 23; the one miss was two schemas in one answer. Haiku got 23 both ways. Modern models already keep optional keys optional and avoid invented limits. You buy a written, checked rule set and a one-object answer every time.
How was it tested?
On 23 sets of sample documents with rules in plain words, each with documents the schema had to accept and documents it had to refuse, 162 in all, run through a draft 2020-12 validator with format checking switched on. Every wrong schema we tried by hand, such as all keys required, a closed object, a limit copied from the samples or an unanchored pattern, failed at least one of those documents.
What should I still check myself?
Your own real data, with a few documents you keep apart from the samples. The schema is only as tight as your rules, so if a field must be closed, bounded or formatted, state that as a rule. The standard treats format as advisory, so confirm that your validator really enforces it. Rerun it whenever the samples change.