Skip to content

Importing and Exporting Skills

Skills are normally bound to the organization that created them, but the .qskill file format gives you a way to move them around. You can export any skill you can edit, and import a .qskill into any organization where you have edit permissions on Skills.

A .qskill is a small JSON file that contains everything the skill needs to be reconstituted in a new organization:

  • Title, description, and advanced instructions
  • The example plan (steps, tools, columns, dependencies)
  • Any code example
  • Format version information so future Querri releases can read older exports

A .qskill does not include:

  • The original creator’s identity or org
  • The skill’s UUID — the importing organization assigns a new one
  • Org-shared status — imported skills always start as personal, regardless of whether they were shared in the source org

This makes .qskill files safe to share between unrelated organizations: there’s no leaked metadata about who built it or where it ran.

Open the skill you want to export — either from the My Skills library or by clicking through to the editor — and use the export action in the skill card menu (the three-dot button on the right of each card). The browser downloads a file named after the skill (e.g., monthly-revenue-rollup.qskill).

You can export any skill you have edit access to:

  • Your own personal skills (always)
  • Any org-shared skill (if you’re an admin)

If you don’t see an export option on a skill, you don’t have edit access to it. Ask the creator or an admin for a copy.

Click Import at the top of the Skills page to open the import dialog. Drop a .qskill file (or pick one from the file picker), and Querri reads the file, validates it, and creates a new skill in your library.

The import flow:

  1. Validates the format. If the file is malformed or from a much older version of Querri, you’ll get a clear error message.
  2. Creates a new skill in your My Skills section. The imported skill is yours — you’re now the creator of record.
  3. Drops you into the editor for review. The fields are pre-filled from the imported file, but nothing is locked. Take a moment to read through and adjust anything that doesn’t match how your org talks about the data.
  4. Saves on confirmation. Until you save, the imported skill isn’t persisted — closing the editor cancels the import.

A few patterns where the .qskill format earns its keep:

Got a partner team with their own Querri organization that you want to share a recipe with? Export, hand them the file, they import. No sharing of credentials or org membership required.

If you’re about to make a substantial change to an org-shared skill, export the current version first. If the new version turns out to be worse, you can restore by re-importing the old .qskill.

If your team uses one Querri organization for development and another for production, the export/import flow is how you promote a tested skill from dev to prod.

You can keep a library of .qskill files outside Querri — in a Git repo, a shared drive, a wiki — as templates. New organizations can import them as starting points and then customize.

There’s no “update an existing skill from this .qskill” flow. Every import creates a new skill. If you want to update an existing skill from an export:

  1. Import the .qskill (creates a new skill).
  2. Manually copy the relevant fields from the new skill to the existing one.
  3. Delete the imported copy.

This is intentional — automatic merging would make it too easy to overwrite an org-shared skill that other people are actively using.

Querri reads .qskill files going back to the format’s introduction. If you’re importing from an older version, the importer fills in any new fields with sensible defaults — for example, an older export without a code_example field imports fine, just with that field empty.

Going the other direction (exporting to an older version) isn’t supported. A .qskill exported today may include fields that older Querri releases don’t understand — those releases will refuse the import rather than silently dropping data.

A few things to be explicit about, since they sometimes surprise people:

  • Imports don’t share automatically. Even if the source skill was org-shared, the imported copy is personal until an admin promotes it.
  • Imports don’t link back to the source. If the original is updated later, your imported copy doesn’t see the change. They’re independent from the moment of import.
  • Imports don’t bring data sources. A skill that references a customers table assumes you have one with the same name. The import doesn’t try to set up the data source for you.