5 JsonLogic Mistakes Every AI Coding Agent Makes

Ask any LLM to write a JsonLogic rule and it will happily produce something that looks right. Then you run it and get false when you expected true, or an operator your library never implemented. I got tired of debugging hallucinated rules, so I packaged the fix as an open-source agent skill: jsonlogic-skill.

What it does

Drop it into your AI coding assistant and it picks JsonLogic up automatically. You describe the business requirement in plain language, and the assistant:

• turns it into a valid JsonLogic rule (checked against the real standard, not vibes),
• runs the rule against your data,
• validates whether an existing rule is well-formed,
• explains what a rule does, in words,
• debugs rules that return the wrong result.

It knows the actual operator set from jsonlogic.com and, importantly, checks whether your language's JsonLogic library supports the operators it wants to use. JavaScript, Python, Ruby, PHP, Java: one rule, many runtimes, no surprises.

Install

It follows the open Agent Skills format, so it works with Claude Code, Cursor, GitHub Copilot, VS Code agent mode, Codex, and Gemini CLI. For Claude Code:

git clone https://github.com/valeryia-piatrova/jsonlogic-skill.git ~/.claude/skills/jsonlogic

Restart the client and you are done. Every other client has its own one-liner in docs/installing.md.

A quick example

You type:

Give a 20% discount on orders over $200, or 10% over $100, otherwise no discount

The assistant produces:

{
  "if": [
    { ">": [{ "var": "total" }, 200] }, 0.20,
    { ">": [{ "var": "total" }, 100] }, 0.10,
    0
  ]
}

...and validates it before showing it to you. No data shape? It asks. Data shape given? Field names come from your JSON, not from the model's imagination.

Why a skill and not a prompt

A prompt tells the model what JsonLogic is. A skill gives it a workflow: gather the data shape, write the rule incrementally, validate it with a real script, then answer. That validate-before-you-answer loop is the whole difference between "looks right" and "runs right."

Try it

The repo is MIT licensed and free: github.com/valeryia-piatrova/jsonlogic-skill. If it saves you a debugging session, leave a star. And if you hit a JsonLogic edge case it handles badly, open an issue: real-world rules are how it gets better.

Comments

[Sina Rezaei]

One thing I'd add is testing the generated rules against the actual JsonLogic runtime, not just validating the JSON structure. A rule can look perfectly reasonable and still produce unexpected results because of truthiness, missing fields, or differences between interpreter implementations. This is especially important when rules become part of business-critical logic, where a subtle mismatch can silently change the outcome. Having a small regression suite for edge cases would make these AI-generated rules much more reliable.

[Pawel]

Good point, and I'd say this is the real gap. Schema validation catches malformed JSON, but the production failures come from truthiness quirks and missing-field behavior that only the runtime reveals. A small regression suite of edge cases is exactly the kind of thing that makes AI-generated rules safe for business-critical logic. Thanks for adding this.

[Sina Rezaei]

One edge case worth testing is how the same rule behaves across different interpreters. Imagine a fraud-scoring rule where a missing transaction.amount, an explicit null, and 0 can take different paths through the evaluation. If that rule runs in JavaScript and Python, a test suite should verify not just the final decision, but also semantic parity across runtimes. Property-based tests around boundary values, combined with differential tests against the production interpreter, could catch regressions that ordinary example-based tests miss.

[Pawel]

Exactly the class of bug that passes every example-based test. A fraud rule that treats a missing amount as zero is a very different rule from one that treats it as no data, and each interpreter has its own falsiness quirks around null. Differential testing against the production interpreter in every language you actually ship is the only approach that holds up. This deserves its own section next time I write about rule testing, thanks for spelling it out.