Skip to main content

Skill types and triggers

A Skill has a content type (what it carries) and a trigger (when it reaches the model). Picking the right pair is most of what makes a Skill useful. This page gives you the decision rules and worked examples. For the conceptual model, see the Skills feature reference.

The two choices​

Content type — what the Skill is:

  • Knowledge — facts, glossaries, documents, business rules.
  • Instruction — how QRY should behave (tone, format, preferred tools).
  • Procedure — a numbered playbook for a recurring kind of request.
  • Script — Python QRY runs in its sandbox.

Trigger — when it reaches the model:

  • Always — in every matching conversation's prompt.
  • Similarity — retrieved only when the question is semantically relevant.
  • Model-driven — the model sees a one-line description and loads the full Skill (or runs the script) on demand.

Choosing a trigger​

Ask two questions:

  1. Is it short? If the content is a few lines, Always is fine — the token cost is negligible and you never risk it failing to retrieve.
  2. Is it always relevant? If it only matters for some questions, don't inject it everywhere. Use Similarity for big reference material, Model-driven for playbooks and scripts.
ShortLong
Always relevantAlwaysSimilarity (or trim it down to Always)
Sometimes relevantModel-drivenSimilarity / Model-driven

Worked examples​

Knowledge + Always — the house glossary​

A dozen metric definitions and naming conventions, system or workspace scope. Small, always useful, so inject it everywhere.

- MRR = SUM(monthly_amount) WHERE status='active' on the snapshot date.
- Tables prefixed stg_ are staging — never query them directly.
- Fiscal year starts July 1.

Knowledge + Similarity — a 120-page policy manual​

Far too big to always inject. Upload it as a document-backed knowledge Skill with the Similarity trigger so QRY pulls in only the relevant passages when a question touches policy. See Domain Context for the document/RAG details.

Instruction + Always — team output preferences​

Always show the SQL you ran. Default to a chart when the result has a time
dimension. Currency is EUR; format with thousands separators.

Workspace scope, Always — every conversation in the workspace should follow these.

Procedure + Model-driven — the monthly-close playbook​

A numbered walkthrough that only matters when someone asks about the close. Description: "Steps for the monthly financial close: trial balance, reconciliation, variance flags." The model loads it only when the question matches — it doesn't clutter unrelated conversations.

Script + Model-driven — a reusable cohort calculation​

A deterministic Python computation you don't want the model to re-derive each time. Description: "Compute monthly retention cohorts from an orders query." QRY calls run_script when relevant, runs it in the sandbox under the user's permissions, and uses the result.

A note on model-driven Skills​

Model-driven only works if an admin has enabled it for the tenant. When enabled, every model-driven Skill contributes just its one-line description to the prompt, and full content loads on demand — so you can have a large library without bloating the context window. This is why the description is the most important field for a model-driven Skill: it's the only thing the model uses to decide whether to load it.

See also​

QRYA product of IXEN.