jsonlogic

jsonlogic 是做什么的？

A skill for work with JsonLogic.

JsonLogic is a small, portable format for expressing conditional logic as JSON.

The JsonLogic standard is the universal rule format and defines its semantics. A rule at this level is language-agnostic. See references/jsonlogic.md and references/operations.md.

A specific library is the code that executes JsonLogic in a particular language, such as json-logic-js for JavaScript or json-logic-rb for Ruby. Libraries can differ in the operations they support, as well as their API shape and error handling.

Running JsonLogic

Library

If a specific implementation is named, such as json-logic-js, use that exact implementation. A language name alone, such as “in Python”, means use the library for that language from references/libraries.md. If neither a library nor a language is named, default to scripts/jsonlogic.rb.

Support

A rule can be valid JsonLogic and still be unsupported by the selected library or its current version. Flag unsupported operations. Never rewrite a valid JsonLogic rule just because one library can't run it. Say which level the limitation is at and offer the real options:

• a custom operation
• a different library if operation is not supported in specific implementation
• logic change

Playground artifact

Whenever a concrete rule is in play (created, explained, fixed, or executed), render it live instead of only describing it in text: seed assets/playground.html with that rule and data, then publish it with the Artifact tool. This runs under whoever installed the skill — each publish call creates the artifact under that person's own account, so it works the same way for every installer with no sharing step needed. The artifact is private by default, and publishing here just updates the same URL, so there's no separate decision to check on each time.

Two files, one static and one templated: assets/jsonlogic-core.js is the JsonLogic interpreter — it never changes between invocations, so publish it once per conversation (via the Artifact tool's files param) and never again. assets/playground.html is the thin page with the placeholders below; it's the only one that gets re-templated and republished on every change.

1. Read assets/playground.html. It's a fixed-design page (rule, live result, data) — never hand-edit its CSS/layout; only the placeholders below change per invocation.
2. Replace __INITIAL_RULE__ and __INITIAL_DATA__ with the rule/data objects, each as a JS/JSON literal (the output of JSON.stringify(...), valid to drop in as-is). No concrete rule yet → leave both untouched, the template falls back to a built-in default.
3. Replace __CURRENT_LANG_MODE__ with "ruby" when the target language is Ruby, otherwise "jsonlogic" (every other language shown here follows JsonLogic's own truthy/falsy rules; only Ruby's diverge). No language decided yet → leave it untouched, falls back to "jsonlogic".
4. Replace __VERIFY_LIB_LABEL__ with the same library Running JsonLogic → Library (above) resolved to for this task — this is what the page's "Verify in chat" button names when asking to confirm against the real implementation, so it must match, not default to Ruby just because that's this file's own fallback:
   • Ruby → "json-logic-rb (scripts/jsonlogic.rb)"
   • JavaScript / TypeScript → "json-logic-js"
   • Python → "maykin-json-logic-py"
   • Java → "json-logic-java"
   • PHP → "json-logic-php (jwadhams/json-logic-php)"
   • Go → "diegoholiveira/jsonlogic"
   • C# / .NET → "JsonLogic (json-everything)"
   • Any other language from references/libraries.md → that library's name as given there. No language/library decided yet → leave it untouched, falls back to Ruby's "json-logic-rb (scripts/jsonlogic.rb)", matching this skill's own default.
5. Write the result to a working file and publish it — the first time in a conversation: Artifact tool, action:"publish", that file's path, title:"JSON Logic Playground", icon:"code", plus files:{"jsonlogic-core.js":"assets/jsonlogic-core.js"} so the interpreter ships alongside it unmodified.
6. Whenever the rule, data, or language changes later in the same conversation, redo steps 1–4 with the new values and publish again with the same file path and the same url — but omit files this time, since jsonlogic-core.js never changes and an omitted file is kept as-is. This updates the same artifact in place instead of creating a new one.

Skip this for requests that never produce a concrete rule (e.g. "what does missing do").

The user can edit the rule/data directly in the artifact to test things — that's the point, it recalculates live. Never republish over those manual edits. Only republish when the user asks for a new or changed rule/condition in chat.

Writing JsonLogic

Step 1: Get the data shape

Always ask how to get the data’s field names before creating a new rule. Present this as choice. Use the client’s structured question mechanism, such as buttons or a picker, when available. Otherwise, present the choices as plain text.

Question: "How should I get your data's field names?". Offer three options:

• Option Schema — "I'll paste a schema — JSON Schema, OpenAPI, whatever format."
• Option Sample data — "I'll paste a real JSON example."
• Option Just guess — "Infer field names from my description."

The dialog only picks the method. The actual answer still comes as a normal follow-up message, not inside the dialog itself.

Step 2: Build the expression

Write the rule using the field names from Step 1.

Before writing a new rule, check references/operations.md for the full supported list and examples/ for worked patterns. For real upstream test cases per operator, see references/tests/.

Customization

Don’t expect JsonLogic to include every specialized operation. It’s intentionally small and not a programming language. It will never do everything. However JsonLogic support extentions. Before you reach for a custom solution, see if you can express your logic using the supported operations (built-in). Often, a simple change in perspective is all you need to get the job done with what's already there.

Step 3: Explain what it does

Cover:

• the requirement being encoded
• the operations used and what each does
• the expected input shape
• what the rule returns
• edge cases worth flagging (missing fields, type coercion, empty arrays)

Skip items that don't apply.

Missing information

If business condition unclear – you should ask what the rule should check, but don't ask about things you can already resolve from context.

Validate JsonLogic

Checking shape against references/jsonlogic.md, references/operations.md, or scripts/validate_skill.rb only confirms the rule is shaped like JsonLogic.

Real validation means writing test cases and running them through scripts/jsonlogic.rb. See references/testing.md for how to pick them. Cover the normal case and the boundary, but weight it toward edge cases especially: missing fields, empty arrays, unexpected types. A rule with no test cases isn't safe to hand off — there's no way to guarantee it behaves as expected.

For the individual operators a rule uses, check references/tests/ first — real upstream cases for both the core spec (core.json) and the community extensions (community/), bundled locally. Reuse a matching case as a sanity check before writing new ones from scratch; these test the operators in isolation, not the rule's actual business logic, so still add rule-specific cases on top.

Debug JsonLogic

Step 1: Reproduce it

Use Running JsonLogic with the rule and data as reported. See the actual output yourself before diagnosing anything.

Step 2: Find the actual cause

Lead with the real cause, not just the symptom — common culprits: type coercion, missing fields, operator misuse.

Step 3: Fix and verify

Give the corrected rule, then re-run Step 1 with the fix to confirm the new output is right. If the fix needs to be handed back as runnable code, continue to Execute JsonLogic below.

After any

Verify running

See Running JsonLogic above to actually execute the rule. If there's no data example on hand yet, create a representative one first. Verifying needs real input to run against, not just a description of what the rule should do.

Flag concerns

Don't claim JsonLogic is "safe" just because it's JSON.

Reference files

Read these as needed rather than loading everything up front:

• references/jsonlogic.md — core semantics: truthiness, type coercion, var path resolution, how missing data behaves, what "compliant" means.
• references/operations.md — every standard operation: syntax plus behavior notes worth knowing (short-circuiting, three-argument comparisons, reduce's current/accumulator, etc).
• references/libraries.md — the library landscape across languages: what was found, what was verified, what wasn't. Read before writing any language-specific code, including for languages not listed — check there first rather than assuming none exists.
• references/testing.md — how to verify a rule or implementation, and how to be honest about what "verified" means in a given answer.
• references/tests/ — bundled upstream test cases (core spec + community extensions) for validating individual operators.
• examples/ — worked examples:
  • basic-rules.json
  • conditions.json