Getting started with Qube Script

Qube Script is QubeSurvey’s default questionnaire language. You write the questionnaire as source, test a saved version, then use that version in a Run. ODIN remains a separate language and runtime for existing questionnaires.

Write and test your first script

  1. Write the source below in your editor and save it as feedback.qube. QUBE Survey Workbench for Visual Studio Code supports local editing and testing.
  2. Open Scripts and sign in. Uploading versions requires editing access; see People, access and billing.
  3. Choose the owning Account and create a Script in the sidebar, or open one where you are an owner or editor. A new hosted Script requires an eligible paid account and an assigned editor seat.
  4. In Versions, choose Upload new version and select feedback.qube. This saves an immutable version and opens Test. The filename selects Qube Script.
  5. Type an invented answer and continue. You should see Thank you, then the completion message. Test opens that exact version; it does not collect a response for a live Run.
@survey feedback @language en @mode cawi
 
@question comment text
What should we improve?
 
@question thanks display
Thank you.
 
@outcome complete
Finished.

@survey declares the questionnaire, language and mode. Each @question declares a named question and its type, followed by its text. This example uses a text answer and a display page. @outcome complete declares the final outcome.

AI authoring in VS Code

The supplied QUBE Survey Workbench beta VSIX includes local MCP tools for Qube Script and ODIN. Install it in VS Code 1.102 or later, then:

  1. Open a trusted workspace and run QUBE: Show AI Setup.
  2. Run MCP: List Servers, select QUBE Survey and start it when prompted.
  3. Select its tools in your MCP-capable AI chat. Ask the assistant to retrieve qss.guide.get, edit the source and run qss.check on the complete script.
  4. Review the edits and run QUBE: Run Interview before uploading a version.

This setup needs no source checkout, separate Node installation or QubeSurvey sign-in. VS Code controls server startup and tool permissions. You configure the AI assistant and model separately; source sent to that model and model costs follow the assistant’s settings. QUBE’s MCP tools check supplied source locally and do not read the hosted sign-in token. Disable the provider through qube.ai.mcp.enabled in User Settings if you do not need it.

MCP in other clients

If you are supplied a portable Survey MCP archive, extract the complete package to a permanent directory. It includes both parsers and the language guides; it requires Node.js 22 or later, with no npm installation or Rust toolchain. Configure your client’s MCP server to run node with the absolute path to survey-mcp.mjs. Add --legacy for clients using MCP 2025-11-25; the default entry uses MCP 2026-07-28. The configuration format depends on your client.

Run node /absolute/path/survey-mcp.mjs --verify to check the installed package. Keep its manifest, parser and asset files together. Replacing or omitting a packaged file prevents the server from starting. This MCP supplies language checks and guidance; it does not provide a model or a hosted account connection.

For scoring and feedback, try A self-paced practice quiz.

Versions and changes

Uploading creates another version; it does not replace an earlier version or change an attempt that has already started. Keep the source in your editor and upload again after making a change. Source files have a 2 MiB UTF-8 limit. Browser source editing is deferred; authoring is script-only.

For a problem or requested change, create a ticket while testing and explain the expected result. A proposed fix needs human comparison and testing before promotion. See Testing a script, Tickets and proposed fixes and How the Agent works. Those detailed guides illustrate the ODIN workflow; QSS Agent qualification and saved target journeys are still limited in beta.

From a script to a Run

  • Scripts contain source versions, tickets and collaborators.
  • Participants contain reusable people and Groups. An open-link survey does not require every respondent to become a panel member.
  • Runs select a script version and access policy. Attempts and responses belong to the Run, rather than the testing workspace.
  • Services provide optional capabilities that a script and Run can use. This example needs none.

Before opening a Run to real participants, test its access, completion and response export with invented data. Quotas, invitation sending, export volume, assessment feedback and online service use have separate beta limits; confirm the behavior your Run needs before using it for production collection. This guide does not establish confidential exam marking or million-interview capacity.

In a Run’s Settings, Pause run stops new starts, online reopening and submissions until you resume it. An already open interview can continue offline and keep its answers on the device. Close run permanently stops acceptance; it cannot be undone. Saved responses and history are retained. The confirmation explains the effect on unfinished interviews before applying either change.

For ODIN questionnaires, upload a .odin file. Getting started with ODIN describes its dedicated workspace and compatibility limits.