AIDA automatically ships with a strong analytical baseline. It understands schemas, writes SQL across federated sources, joins concepts, and reasons over results. While that baseline is enough for many tasks, it is not always enough for the questions a specific business asks. Those kinds of questions require business context, and specifically, they require that context to be engineered.
Business context in action
Let’s look at an example. A retail planner wants AIDA to know what a “cohort retention curve” means in their warehouse. A capital markets desk needs to run Monte Carlo simulations for revenue forecasts. A supply-chain analyst wants an inventory turnover calculation that uses the company’s specific definition of “stockout.”
Each is a small piece of domain knowledge that a generic assistant cannot infer from table names alone. Today, in the private preview of AIDA Skills, we are giving customers a way to teach AIDA those techniques directly.
What is a skill?
A Skill is a reusable, potentially parameterized capability that customers author, save to their account, and invoke through natural language. For example, this might include:
- The exact steps AIDA should take for a workflow
- Instructions on reporting with a report template
- Definition of how to use specific MCP servers and tools
- Other capabilities
AIDA matches the request to the right Skill and runs it under the user’s own permissions.
This post walks through the Skill format, the two authoring paths in this preview, where we are heading with AI-assisted authoring, how matching and execution work, and the safety model that lets customers contribute content without giving up enterprise guarantees.
What is a Skill
What form does a Skill take? A Skill is a single, human-readable file in the open agentskills.io format. It is a Markdown document with frontmatter for metadata and a body that describes what the Skill does, when to use it, the parameters it accepts, the expected output, and example prompts that should trigger it. When a Skill needs SQL to do its work, the SQL lives in the file as a parameterized Trino statement.
A minimal Skill looks roughly like this:
--- name: monte-carlo-revenue description: Run a Monte Carlo simulation on quarterly revenue using historical variance to produce P10/P50/P90 forecasts. --- ## When to use User asks for revenue scenarios, probabilistic forecasts, or "what is the range we should plan for." ## Parameters - `quarter`: target fiscal quarter (e.g., "Q4 2026") - `iterations`: simulation runs (default 10000) ## Outputs A table with percentile bands and a short summary of assumptions. ## Example prompts - "Give me a P90 revenue forecast for next quarter." - "What is the downside scenario for Q4 revenue?" ## Instructions 1. Pull the last 16 quarters of revenue from the `finance.revenue_actuals` data product. 2. Compute the quarter-over-quarter percent change distribution. 3. Run `{{iterations}}` Monte Carlo simulations against the most recent quarter to project `{{quarter}}`. 4. Return percentile bands and a brief explanation of assumptions. ## SQL template WITH historical AS ( SELECT quarter, total_revenue FROM finance.revenue_actuals ORDER BY quarter DESC LIMIT 16 ) ...
Three properties of this format matter for enterprise use:
- Portability. A Skill is a plain text file. It lives in version control, moves between environments, and survives any single product release. There is no proprietary binary, no exported package format.
- Open spec alignment. We chose to align with the agentskills.io community spec rather than invent our own, so Skills authored against AIDA are not locked to Starburst. Customers who already write skills for other agents can bring them. Customers who write skills for AIDA can take them with them.
- Description-first. The natural-language description is not a comment. Rather, it is the matching signal. AIDA looks at the description and example prompts when deciding whether a user’s question warrants a Skill. The quality of the description directly determines the quality of the match.
Two authoring paths in this preview
The audience for Skills is broader than the audience for SQL authoring. A data engineer should be able to write a Skill from scratch with full control. A business analyst should be able to bring an existing Skill from a teammate without learning a new editor. We ship both paths in this preview.
Structured form
The first path is a guided form inside the AIDA Skills dialog. The author provides the skill name and a short description about the skill and when to use it. The author then provides instructions on what the skill should do, what parameters it should expect, and other criteria that define what AIDA should do. If the skill needs specific SQL, this can also be defined in the instructions with parameters and defaults. On save, the form stores the Skill against the account in the standard SKILL.md format.
This path is the right starting point for an author who is creating a Skill for the first time and wants the schema to guide them. The form enforces required fields and validates the slug format, so the result is well-formed by construction.
SKILL.md upload
The second path is a drag-and-drop file upload. The author writes the Skill in their editor of choice, in any environment, and uploads the resulting .md file to AIDA. The uploader parses the frontmatter, validates the structure against the spec, and surfaces any issues before the Skill is saved.
This path is the right starting point for an author who already has a Skill they want to bring in, or a team that maintains Skills in a shared Git repository and treats AIDA as one of several consumers.
Both paths produce identical artifacts. A Skill authored through the form behaves no differently at invocation time than a Skill that was uploaded.
Where we are heading: AI-assisted authoring
The form and the upload path serve authors who can already articulate a technique in writing. The next step, and the largest piece of our roadmap for Skills, is conversational authoring: a flow in which the author describes what they want in plain English, AIDA asks clarifying questions about inputs, outputs, and trigger conditions, and a Skill draft is produced and refined iteratively in chat.
We are designing that flow to feel like teaching a colleague: state the intent (“I want a Skill that does a Monte Carlo simulation for revenue forecasting”), answer a few targeted questions about parameters and data sources, review the draft, refine it conversationally, and confirm. The author should not need to know SQL or the Skill spec. They should know their own technique.
We are sharing the direction now because the file format does not change. The artifact a conversational flow produces is the same SKILL.md a manual author writes today. Whichever way an author writes a Skill, the artifact is portable, reviewable as plain text, and version-controllable. AI-assisted authoring is an accelerant, not a different product.
How AIDA picks and runs a Skill
A Skill is only useful if AIDA reliably notices when to use it. The matching loop today works in two modes:
- Implicit. When a user asks a question, AIDA looks at the active Skills’ descriptions and example prompts. When the request matches a Skill, AIDA applies that Skill and surfaces which Skill was used in the response, so the user is never guessing whether a custom technique was applied.
- Explicit. A user can invoke a Skill by name in their request, for example, by writing “use the Monte Carlo skill” or invoking it directly with a slash command like /monte_carlo_revenue. Explicit invocation always wins over implicit matching, which gives power users a reliable handle when they want a specific technique.
Once a Skill is selected, the model is responsible for interpreting it. We do not spawn a subagent or hand the Skill off to a separate execution engine in this release. The Skill content goes into the active context window, the model reads the instructions and the parameterized SQL, fills in the parameters from the user’s question, and proceeds with the rest of its workflow. This keeps the system simple, the latency predictable, and the behavior debuggable, since the entire run lives in one trace.
A non-negotiable property: a Skill’s SQL runs under the invoking user’s permissions. There is no privilege escalation, no impersonation, no service account running Skills on the user’s behalf. If the user cannot see a table directly, the Skill cannot read it for them. Skills are an extension of what the user can already do with AIDA, not a way around it.
Safety: Treating Skill content as untrusted input
A Skill is a string of text supplied by a customer and inserted into a model’s context. That is the exact shape of a prompt injection. We treat it that way. Once it has been added to a session’s context, it cannot be removed.
However, before a Skill is saved, we validate its structure and run content-safety checks on the description and instructions. At invocation time, we present the Skill content to the model with framing that separates Skill instructions from the user’s request. The system prompt instructs the model to ignore any attempts inside Skill text to override its operating constraints. These defenses are imperfect, and we know it, which is why we layer them. The validator catches obvious cases at authoring time. The runtime framing catches what slips through. Skill execution under the user’s own permissions caps the blast radius if both fail.
Skill activation is also session-scoped. A Skill that exists in the account library is not silently available in every conversation. The user selects which Skills AIDA can select from for a given session – AIDA activates the correct skills on an as-needed basis. We record the activated Skill IDs on every message, so any answer can be traced back to the exact set of Skills that contributed to it.
What is in this private preview
The private preview is intentionally focused. The point of the preview is to validate the artifact, the matching loop, and the safety model with real customer techniques against real customer data. We are deliberately holding back features that we want to design with preview feedback in hand, not against guesswork.
In this preview:
- The Skill spec, aligned with agentskills.io.
- Structured-form authoring.
- SKILL.md upload authoring.
- Implicit and explicit invocation, with the selected Skill surfaced in the response.
- Skill execution under the invoking user’s permissions.
- Session-scoped activation with per-message provenance.
- Prompt-injection defenses on Skill content.
- A small library of starter Skills covering common analytical techniques such as Monte Carlo simulation, time-series forecasting, and anomaly detection.
What is coming next, and where do we want preview feedback to shape the design:
- AI-assisted, conversational authoring. The flow described above, with AIDA generating drafts from a natural-language description and refining iteratively.
- In-editor test execution. Run a Skill against a sample dataset from inside the editor, before saving, so the author can validate that the SQL works and the output is shaped correctly.
- Governance. Role-based authoring, so administrators can restrict Skill creation to authorized roles while keeping invocation open to all AIDA users. An admin can review, enable, disable, or delete any Skill in the account.
- Audit and telemetry. Every authoring and invocation event is captured for compliance, with attribution of LLM token usage to Skills separately from chat, so the value of a Skill can be measured against the cost.
- SQL validation at authoring time. Validate the SQL template against the user’s connected data sources before the Skill is saved, rather than waiting for runtime to surface a schema mismatch.
Why Skills, why now
Skills are important for several reasons, but two stand out particularly.
The first is the anticipated customer need. As AIDA matures, customers in specialized domains hit the ceiling of any built-in analytical vocabulary. Without extensibility, every new technique requires a product release. Skills raise that ceiling. The platform gets richer with every Skill a customer writes, and Starburst does not have to be in the critical path of someone else’s analytical question.
The second is positioning. AIDA is not a chatbot. It is the AI surface of a federated query engine that already crosses every system a customer has. The right place for domain knowledge is next to the data it operates on, in a portable file the customer owns. Skills make that concrete.
We are excited to put this in customers’ hands. If you are a Starburst Galaxy or Starburst Enterprise customer interested in the private preview, talk to your account team. If you are not yet a customer, start a free trial of Starburst Galaxy, and you will see Skills as the preview opens up.
We will be back with a follow-up post on what we learned from the preview and on how conversational authoring lands. The artifact will be the same SKILL.md file. How it gets written will change.
