Is the Fieldbase AI SP Kit free?

Yes — free and MIT licensed. No API key, no sign-in, no vendor lock-in. The core is a Markdown reference and a Node (and Python) linter you clone and run locally.

Which AI assistants are supported?

Three ready-to-use bundles: a Claude Skill (activates automatically), a ChatGPT custom GPT, and a Gemini Gem. For IDE workflows, integration shims exist for Cursor (.cursorrules), Claude Code (CLAUDE.md), and Continue/Copilot (AGENTS.md). Any other AI that can read Markdown and output text can use the core reference directly.

Do I need a Fieldbase account to use the kit?

No — the kit lets you author Fieldbase DSL (.yml) anywhere, offline, with any AI. To actually run the surveys you author (publish, collect responses, export data) you need the Fieldbase platform. The kit covers the authoring side independently.

What does a clean linter result actually mean?

It means no obvious mechanical violations (indentation, option syntax, naming, etc.) — not that the survey is valid. The platform’s own validator catches deeper semantic errors (unknown qids referenced in scripts, empty option sets, etc.) when the .yml is imported. Treat the linter and the platform validator as complements. Always import to a Fieldbase test project before fielding.

← Back to Fieldbase Free · open · MIT

Teach any AI
to write Fieldbase surveys.

Q: Which model tier should I use?

Flagship tier only. GPT-5-class, Claude Opus/Sonnet at high effort, Gemini Pro (not Flash/mini). Fast tiers pass the linter but silently drop logic — quota checks and validations get stripped quietly. The kit’s accuracy table shows real test results per tier.

The Fieldbase AI SP Kit ships with ready-made bundles for Claude, ChatGPT, and Gemini, integration shims for Cursor, Copilot, Continue, and Claude Code, a zero-dependency linter, and real accuracy numbers on a 36-question tracker brief. Author .yml, lint it, ship it.

Download on GitHub → See the bundles

Per-AI bundles

Each bundle is a self-contained folder with the reference, the examples, the linter, and a per-assistant HOW-TO. Grab the one folder you need, drop it in. The reference stays identical across bundles — only the install step changes.

Claude — a Skill

Drop-in Skill: add it once, it activates automatically whenever you ask Claude to write a Fieldbase survey.

bundles/claude/HOW-TO.md →

ChatGPT — a custom GPT

Pre-configured custom GPT: upload the bundle files to a GPT config and the knowledge + instructions are set.

bundles/chatgpt/HOW-TO.md →

Gemini — a Gem

Gem (Gemini's equivalent of a custom GPT): same approach, same reference, Gemini-shaped install.

bundles/gemini/HOW-TO.md →

IDE / agent integrations

For an IDE or a coding agent, the shims in integrations/ point the tool at the authoring reference automatically:

Cursor — .cursorrules file; drop into project root.
Claude Code — CLAUDE.md in the repo; auto-loaded as project context.
Copilot / Continue / other code-agents — AGENTS.md; recognised by any agent that reads an AGENTS convention file.

Tested accuracy

All three bundles tested on the same brief — a 36-question multi-market tracker — then imported to Fieldbase and checked against the platform's real validator. A clean validator result proves syntax, not logic — always import to a Fieldbase test project before fielding.

	Model & tier	Result
Claude	Opus 5, high effort	Complete and thorough — cleanest output.
ChatGPT	GPT-5.6 Sol	Complete; a few cosmetic duplicate-helper warnings.
Gemini	3.1 Pro	Complete, weakest of the three — left one empty quota `- script:` block, used a single generic error message instead of a pipeable error bank. Review those two spots.

⚠️ Use the flagship tier

These numbers are from the flagship / high-reasoning tier of each assistant — GPT-5-class, Claude Opus/Sonnet at high effort, Gemini Pro (not Flash/mini). Fast tiers pass the linter but silently drop logic — quota checks and validations get stripped quietly. If you need to run on a fast tier for cost reasons, review the generated DSL carefully, especially script blocks.

What's in the core kit

SURVEY-DSL-AUTHORING.md — the complete authoring reference. Every question type, every property, flow blocks, reusable lists, multilingual & multi-country patterns, the hard rules the DSL enforces. The same file every bundle uses.
lint/survey-dsl-lint.js — a standalone, zero-dependency Node linter. No npm install, no engine, no network. A byte-identical survey_dsl_lint.py is bundled for Python workflows (ChatGPT Code Interpreter, Python CI).
examples/ — validator-clean sample surveys (synthetic) to show the shape and give the AI few-shot material.
bundles/ — the three per-AI bundles (chatgpt, claude, gemini) above.
integrations/ — the IDE / agent shims above.

How it works

Clone the repo (git clone https://github.com/inginit/fieldbase-ai-sp-kit) or download the ZIP.
Install the right bundle for your assistant, or point your IDE at the shim.
Ask the AI to write a survey as .yml.
Run the linter: node lint/survey-dsl-lint.js my-survey.yml. Exit code 0 = no errors.
Fix what it flags, repeat until clean.
Import the .yml into Fieldbase (or hand it off to someone who will).

What the linter is — and isn't

It catches the frequent, mechanical mistakes fast and offline: tabs / non-4-space indentation, non-numeric or negative codes, true/false vs True/False, inline {k: v} options, underscored ids, Q.any( without .selected, snake_case style:, style: dropdown on gridSingle, questions: on a - loop:, duplicate qids / loop ids, multi-line options.from:, continue/break in scripts, and more.

It is not a compiler. It does not resolve the grammar or a symbol table, so it does not catch deep semantic errors (an unknown qid referenced in a script, a required question with an empty option set, etc.). Those are caught by the platform's own validator when the survey is imported or published. Treat a clean lint as "no obvious violations," not "provably valid." The linter and the platform validator are complements.

Why we published it

We built this kit for ourselves — it's how our own AI-assisted authoring works inside Fieldbase. Rather than gatekeep the DSL knowledge behind the platform, we're publishing it under MIT so anyone can author Fieldbase .yml with any tool they prefer. The kit is the authoring front-end; the Fieldbase platform is where surveys actually run (publish, respondent runtime, quotas, translations, SPSS exports — the parts you can't do with a Markdown file).

FAQ

Is it really free?

Really free. MIT license. You use whatever AI assistant you already pay for (or a local model). We don't bill, meter, or phone home.

Can I use the kit if I'm not on Fieldbase?

You can author DSL anywhere, but .yml files aren't surveys on their own — they need a runtime. To actually publish, collect responses, run quotas, translate, and export data, you'll need the Fieldbase platform. We're in early access — get in touch.

Does the kit stay in sync with the platform?

Yes — the reference tracks the current Fieldbase DSL contract (engine v3.34.0 at the time of writing). The repo CHANGELOG.md records updates. Watch the repo on GitHub to get notified.

Found a bug in the DSL reference or the linter?

File an issue on GitHub or send a PR — we review them. MIT license, contributions welcome.

Download on GitHub → See the DSL →

Teach any AI to write Fieldbase surveys.