claris-filemaker-pro

Imported from CadenceUX/claris-filemaker-pro-skill (SKILL.md). Install upstream with npx skills add CadenceUX/claris-filemaker-pro-skill. Copyright stays with the author.

Claris FileMaker Pro — Skill v2.0.0

What this skill is

A reference skill for FileMaker Pro — script steps, calculation functions, field types, and the client platforms a solution runs on. It is deliberately scoped to FileMaker Pro rather than the wider Claris platform, and it goes deep on that one surface: verified call signatures and return types, per-step platform support, worked usage examples, error codes, and the API surfaces a Pro developer actually reaches for.

It is not a minimal name-and-signature vocabulary list, and not a link index that defers every real answer to a web fetch. The local reference files carry verified content and are designed to answer most questions without a network round-trip. It does not cover FileMaker Server administration, Claris Connect, Claris Studio, or deep ODBC/JDBC configuration.

The Claris Help Centre at https://help.claris.com remains the authoritative upstream source. Every local file records how and when it was verified against it.

Local-first: when to answer locally, when to fetch

Default: answer from the local reference files. They were re-derived from the live Claris documentation on 2026-07-25 — every function signature, return type, and originated-in version, and every script step's full seven-product compatibility matrix. Treat them as correct.

This matters for generation speed and accuracy: composing a script, or a set of field definitions, should not require a network fetch per step.

Fetch live only when one of these is true:

Do not fetch merely because a function is old, because the question mentions a platform, or out of habit. Per-step platform support is local, verified and complete — use it.

If a live page contradicts a local file, the live page wins; say so explicitly in your answer.

Version drift detection

When you do fetch a page, check ## Originated in version in the page body — not the YAML frontmatter.

Every .md help page returns YAML with version: / version_year:, but that tracks the documentation build, not the feature release — verified 2026-07-04: FM 26 features still return version: 22 / version_year: 2025. Comparing frontmatter against last_known_fm_version never fires, and mislabels current docs as old.

1. Read ## Originated in version from the page body.

2. Compare with last_known_fm_version in the catalog meta block (currently 26).

3. If higher, flag it:

   ⚠️ Skill version drift detected — this page documents a feature originated in FM [X], but this skill's local reference files were last verified for FM 26. New functions, script steps, or behaviour changes since then may not be reflected locally.

4. Still answer from the fetched content — the flag is advisory.

5. Don't flag versions ≤ last_known_fm_version.

topic_type is not a reliable roster signal

When rebuilding catalogs, derive the roster structurally — a script step page has a ## Compatibility table; a function page has ## Format and ## Data type returned. Claris mislabels at least four pages as topic_type: conceptual (set-dictionary, getpersistentdata, listpersistentdataids, get-systemstorageavailable). A topic_type sweep alone undercounts, and previously caused a real script step to be missed entirely.

Version self-check

At the start of each session, on the first FileMaker question, run once:

1. Fetch https://github.com/CadenceUX/claris-filemaker-pro-skill/raw/main/VERSION

2. Compare with this skill's installed version (currently "2.0.0")

3. If latest > installed, prepend:

   ⚠️ Skill update available This skill is v[installed]. v[latest] is available at https://github.com/CadenceUX/claris-filemaker-pro-skill/releases

4. Don't repeat in the same session. If the fetch fails, skip silently.

Mandatory trigger: FileMaker functions, script steps, and fields

Any request involving a FileMaker calculation function, script step, or field definition — by name, by category, or by describing what it should do — must use this skill.

Workflow: check the relevant example file → confirm format, return_type and platform_exceptions in the catalog → answer with the signature inline and cite the doc URL. Fetch live only per the rules above.

Reference files — all 14

Platform support — how to read it

script-steps-catalog.json carries verified support for all 216 steps across seven products: Pro, Go, WebDirect, Server, Cloud, DataAPI, CWP.

Support is delta-encoded: platform_exceptions lists only the products where a step is not fully supported. If platform_exceptions is absent, the step is supported everywhere.

Measured totals across 216 steps — Pro 204 yes / 6 partial / 6 no · Go 154/20/42 · WebDirect 103/38/75 · Server 108/29/79 · Cloud 106/27/83 · DataAPI 91/26/99 · CWP 99/26/91.

Treating "Partial" as supported is a common and costly mistake. Several very common steps are Partial rather than Yes, including Go to Layout, Go to Portal Row, Go to List of Records, Execute SQL and Export Records in various contexts.

os_restriction is separate and orthogonal — a desktop-OS limit (macOS only / Windows only).

Calculation functions do not carry a Compatibility table in Claris documentation, so per-function platform support is not available as structured data. Where it matters, read the function's own page notes, or detect at runtime with Get(ApplicationVersion). Error 1225 ("Function referred to is not supported in this context") is the runtime signal.

Automatic version notes

Read originated_in_version from the catalog and inject a version note automatically — don't ask the user which version they're on. Versions are stored in Claris's own precise form (6.0 or earlier, 19.6.1, 22.0, 26.0.1).

FM 19 is the practical floor; anything older is noted only as "may not be available on legacy versions".

Fetching strategy — which file first

Related skills

For paste-ready field definition XML — the fmxmlsnippet / FMObjectList envelope, the auto-enter, validation and storage element structure, and the paste-handler rules that cause silent failures — use the filemaker-field-xml skill. That skill is authoritative for the XML layer; field-types-catalog.json here covers the capability layer (what a field type can do) and deliberately does not duplicate the XML shape.

Name that skill exactly when you depend on it. Generic phrasing such as "a dedicated FileMaker field XML reference" gets substituted for a different same-domain source under context pressure.

Tips

• function-catalog.json is the master for signatures and return types; the example files are the master for usage patterns. Per-entry notes carry behaviour detail.
• Mobile functions (Location, LocationValues, GetSensor, RangeBeacons, GetAVPlayerAttribute) work only in FileMaker Go — branch on Get(ApplicationVersion).
• Japanese functions require Japanese language support; Furigana() depends on the IME and is context-sensitive.
• Trig functions work in radians — convert with Degrees() / Radians().
• Financial functions take the rate per period, not annual. PMT() returns a negative number; wrap in Abs() for display.
• AI/RAG workflow requires three steps in order: Configure RAG Account → Configure AI Account → Perform RAG Action. Always fetch live for AI options — provider support (including Google Gemini, added in FM 26) and parameters change between point releases.
• Generate Response from Model — in agentic mode, append the DDL schema from GetTableDDL to the execute_sql tool parameter description. Custom function tool definitions must match the function name and parameter order exactly, all parameters typed "string".
• Field annotations narrow DDL. When any field in a table is annotated, only annotated fields appear in that table's generated DDL. Read with FieldAnnotation().
• The persistent data store is not a field storage type. It is a per-file, schema-resident named-value store (Name + optional Instance ID), separate from record data, holding a value of any of the six data types. Write with Configure Persistent Data; read with GetPersistentData / ListPersistentDataIDs. Unrelated to Get(PersistentID), which returns a device identifier.
• ROWID / ROWMODID are the FileMaker SQL system columns (equivalent to Get(RecordID) and Get(RecordModificationCount)). They are not named RECORDID / MODID.
• Sub-version doc drift: Claris updates pages between releases without bumping the version field. Where an exhaustive option matrix matters, fetch the live page.

Licence

This skill is released under CC BY 4.0.

Built and maintained by Darrin Southern from CadenceUX.

Version history

See CHANGELOG.md for the full version history.