A Skill can preserve an analytical method and even package the SQL, context, and corrections from a specific project. On its own, however, it cannot preserve which data version was used, what actually ran, who approved the definitions, or how the conclusion connects to evidence. A Skill remembers how an analysis should be done. It does not preserve how a particular analysis actually happened.
I keep seeing a natural pattern. After an analyst and an Agent finally complete a useful analysis together, the analyst turns the hard-won Prompt, metric definitions, SQL, checks, and caveats into a Skill. The next time a similar question appears, the Agent can load that Skill and continue from there.
That is much better than burying the work in an endless chat history. But it also reveals a deeper problem: we are putting a reusable method and the record of a real analysis into the same container.
We are really talking about two kinds of Skill
The open Agent Skills format defines a Skill as a folder centered on SKILL.md, with optional scripts, references, templates, and other resources. It is well suited to giving an Agent specialized knowledge and workflows on demand.
In data analysis, I think people use Skills in at least two distinct ways:
| Type | What it preserves | Example | Primary value |
|---|---|---|---|
| Methodology Skill | General methods, steps, checks, and delivery standards | Funnel methodology, SQL review checklist, data-quality checks | Teaches an Agent how this kind of work should be done |
| Specific-analysis Skill | Definitions, SQL, context, corrections, and conclusions from one analysis | Q2 retention, monthly revenue, conversion for one product | Helps an Agent continue work that was already done |
The first is reusable expertise. The second is closer to a compressed analysis project: we want the Agent to remember not only the method, but also what it worked through with us last time.
That need is entirely reasonable. Chat is a poor storage format for analysis. Switch Agents, start a new conversation, or return three months later, and the details you previously resolved are easy to lose. A specific-analysis Skill is a practical patch.
But a patch is not the analysis itself.
SQL inside a Skill does not preserve the analysis that produced it
Suppose you and an Agent finish an analysis of 30-day paid conversion for new customers. You turn the following into a Skill:
- the definition of a new customer;
- rules for excluding test accounts and refunds;
- how to join user, order, and payment tables;
- the SQL used to calculate conversion;
- the charts and conclusions expected in the Report.
Three months later, another analyst loads the Skill to update the number. The Agent knows the intended procedure, but it may still be unable to answer:
- Did the SQL in the Skill actually run successfully, or was it only a suggestion?
- Which query result produced the 18.4% in the Report?
- What data range was used, and has the source changed since then?
- Which definitions did the analyst reject, and which version was approved?
- Were grain and JOIN fan-out checked before and after the JOIN?
- If the rerun returns 17.9%, did the data, SQL, or definition change?
You can keep adding files to the Skill: query results, dates, version notes, more SQL, or even a script that reconstructs the workflow. But once it is responsible for snapshots, dependencies, execution history, decisions, and the final deliverable, it is no longer just a Skill. It is a manually maintained analysis workspace.
The issue is not whether a Skill folder can hold those files. It can. The issue is that placing files together does not automatically establish the relationships among them.
The presence of SQL does not prove that it ran. A written number does not prove that it still connects to the data and conditions that produced it.
A method is instructions; an analysis is state and evidence
This is the fundamental distinction.
A Skill describes the intended path: which data to inspect, which steps to follow, which risks to check, and how to deliver the work.
An analysis preserves the actual path: which definition was chosen, which SQL ran, what data state it used, what result it produced, what reviewers decided, and which limitations remained.
Both matter, but their lifecycles differ. A method can be reused across projects. An analytical result is bound to a specific question, time, dataset, and set of decisions.
| What real analysis must preserve | Specific-analysis Skill | Lantide Data |
|---|---|---|
| Analytical method | Can preserve steps, rules, and Prompts | Can load and share a Skill |
| Business definitions | Written as context for the Agent to read later | Carried in References, Agent Memory, and the Plan |
| SQL | Can store a SQL file or example | Becomes an executable, reviewable analysis artifact |
| Execution results | Must be saved as snapshots or regenerated | Connected to SQL, the result viewer, and workspace state |
| Intermediate results and dependencies | Reconstruction must be described manually | Expressed through named cache, persistent SQL, and lineage |
| Human decisions | Often reduced to the cleaned-up final version | Retained through the Plan, annotations, and approval |
| Report evidence | Conclusions can become separated from query results | Plan, SQL, results, and Report remain in one project |
| Permissions and execution boundaries | A Skill is not authorization | Controlled by Agent state, tools, and access mode |
So the useful comparison is not “Skills versus Lantide.” A Skill is a method asset. Lantide is a working environment where that method can meet real data, execution, and review.
A durable analysis has at least five layers
I use this five-layer model for analysis that another person should be able to continue:
Method → Decision → Execution → Evidence → Delivery
| Layer | Question to preserve | Appropriate artifact |
|---|---|---|
| Method | How should this kind of problem usually be analyzed? | Skill |
| Decision | Which definition, scope, and assumptions apply this time? | Plan, Reference, annotations |
| Execution | Which query actually ran? | SQL and query environment |
| Evidence | Where did the result come from, and how can it be validated and rerun? | Results, lineage, activity |
| Delivery | How was the result interpreted, and what limitations remain? | Report |
If the only thing you save is the Skill, you preserve what could be done next time, but not necessarily what happened last time. That is why reproducible AI analysis needs more than a polished procedure. It needs an evidence chain from the conclusion back to its sources, transformations, and limitations.
This is why I built Lantide Data
I did not build Lantide Data because Skills lack value. Quite the opposite: I believe Skills will become important knowledge assets for analysts working with Agents. Lantide includes a Skill Library so its built-in Agent and external Agents connected through MCP can share the same method definition. But loading a Skill does not grant more tools or bypass governance. See the Skills user guide for how this works in practice.
What concerned me was this: when analysts start putting SQL, business definitions, results, corrections, and even an entire project inside a Skill, what they may actually be missing is not a more complete instruction file. They are missing an environment that can preserve the analytical work itself.
In Lantide's formal workflow, an Agent can use a Skill to draft the method. The question, scope, and checkpoints for this analysis go into a Plan. The user reviews it before Approve & Execute. The SQL that actually ran, its results, and intermediate dependencies remain in the workspace. The final Report stays with the evidence behind it. The method remains reusable without flattening every project into a method.
This does not mean Lantide can decide the one correct business definition for a team. Nor is it a data warehouse or an enterprise semantic layer. People still have to judge the question, data, and limitations. Lantide supplies the state, execution surface, and review interface an Agent needs to complete real analysis.
Skills are analysis assets, but not all analysis assets
When evaluating an Agent analysis workflow, ask two sets of questions.
The first is about capability: Does the Agent know how to analyze this kind of problem? Is it using the right Skill?
The second is about evidence: Which definition did this analysis use? What actually ran? How was the number produced? Who made the decision? Can the next person rerun it?
Skills can answer the first set. The second requires a real analysis environment.
Skills help an Agent learn how you work. Lantide helps you preserve the work you actually did.
The next time you turn a successful analysis into a Skill, try one separation: put the reusable method in the Skill, and keep the decisions, SQL, results, and limitations from this run in a project that can be reviewed and rerun. The Agent can then carry your method forward without your team losing the analysis itself.