Workflow
If you have a workbook full of undocumented LAMBDAs, any capable AI assistant can draft the descriptions for you. Lambrary's JSON export gives the AI everything it needs, the formulas themselves, and the import brings the finished documentation back in. You review, edit, done.
.json file. Lambrary tab → Import Library → pick the file → tick the LAMBDAs you want → untick Import formulas if you only want the documentation → Import.The import is forgiving: unknown fields are ignored, malformed entries are skipped with a count, and nothing is overwritten without asking. If the AI mangles something, the worst case is a skipped entry, not a damaged workbook.
The most common AI mistake is dropping the backslash escapes inside formulas (every \" in a refersTo must survive the trip). The prompt below guards against it twice (a copy-verbatim rule and a validate-before-responding step), and if a broken file still slips through, Lambrary's import error names the exact line and column; paste that error back to the AI for a corrected file.
One thing to be aware of: the export contains your formulas, and the prompt sends them to whichever AI service you choose. If your LAMBDAs encode something you consider confidential, treat the file accordingly.
The easiest way to get this prompt is in the add-in itself: after a JSON export, Lambrary offers to copy the prompt and your exported file to the clipboard in one go: always the current version, one paste into your assistant. The copy below is the same prompt, for reference and for tooling.
You are documenting a library of Excel LAMBDA functions. I will give you a
JSON file in the "lambrary-library" format (schema:
https://lambrary.com/library.schema.json). Your job is to fill in the
documentation fields by reading each function's defining formula.
Return the COMPLETE file as valid JSON — same structure, same entries, with
documentation added. Deliver it as a downloadable .json file attachment
(suggested name: lambdas-documented.json), NOT as text in the chat. Only if
your platform cannot attach files, return the raw JSON as your entire
response — no commentary, no markdown fences, nothing but the JSON.
Rules — structure:
1. NEVER change "format", "formatVersion", any "name", or any "refersTo".
2. "refersTo" values contain JSON-escaped quotes (\") and escaped
backslashes (\\). Reproduce every "refersTo" byte-for-byte, keeping each
backslash exactly as received — dropping even one turns the file into
invalid JSON. Formulas using regular expressions (REGEXEXTRACT,
REGEXTEST, REGEXREPLACE) are the highest risk: a pattern written \d in
Excel appears as \\d in this file and MUST stay \\d in your output;
quoted literals inside formulas appear as \" and MUST stay \". The
safest method is to copy the entire "refersTo" line unchanged; never
re-type a formula from memory.
3. Never insert comments — JSON has no comment syntax (// or /* */) and a
single one corrupts the file. Never alter a property name in any way:
use exactly "name", "refersTo", "description", "documentationUrl",
"parameters", "values", "code", "label" — a renamed or decorated key
(e.g. "name//") makes that field invisible to the importer.
4. Never add, remove, or reorder entries in "lambdas".
5. For each lambda, add or improve: "description", and a "parameters" array
with one entry per parameter, in signature order. Parameter "name" must
match the names in the refersTo formula exactly (an optional parameter
like [mode] may be written with or without its brackets).
6. Keep any existing human-written documentation unless it is clearly wrong;
prefer improving over replacing.
Rules — content:
7. "description": plain text, no markdown. 1–3 sentences: what the function
does, then anything non-obvious (edge cases, assumptions, units). The
first line doubles as a one-line summary, so lead with the essence.
Work it out from the formula itself — follow LET steps and helper calls.
8. parameter "description": one short phrase or sentence. What the argument
is, expected shape (single value, range/array), and the default behavior
if it is optional.
9. Add a "values" array ONLY when a parameter accepts a small fixed set of
codes (modes, flags, switches) that the formula visibly branches on —
e.g. IF/IFS/SWITCH on that parameter. Each entry: "code" is the exact
token a user would type (e.g. "0" or "\"asc\""), "label" is 1–3 words,
"description" one short phrase. Do not invent value lists for free-form
arguments. Avoid commas and pipes inside labels.
10. Set "documentationUrl" only if the formula references something with an
obvious canonical page; otherwise omit it.
11. Calm, precise tone. No exclamation marks, no marketing language. Write
like Excel's own function documentation.
If a formula is too opaque to document confidently, write the best honest
description you can and start it with "Appears to" — do not guess
specifics like units or business meaning.
Before you respond, VALIDATE your output: parse it as strict JSON and
confirm it succeeds. Check especially that every quote inside "refersTo"
strings is still escaped as \", that there are no trailing commas, and no
comments. If it does not parse, fix it and validate again. Then respond
with the .json file attachment (preferred), or the JSON text alone.
Here is the file:
The format is deliberately simple and stable. A machine-readable JSON Schema lives at lambrary.com/library.schema.json. Point your validator, your scripts, or your AI agent at it. Files identify themselves with "format": "lambrary-library" and "formatVersion": 1; readers ignore unknown fields, so additive extensions are safe to propose.
Anything that produces a valid library file can feed a Lambrary import: a hand-written script over your formula inventory, a CI step, or an AI pipeline. If you build something on the format, tell me about it.