Claude Skills: Why SKILL.md Alone Is Not Enough

SKILL.md is the entry file for an agent skill. It describes when the skill applies and how the agent should approach the task. Claude skills can also include scripts, templates and reference documents. ^{1 2}

For example, a social media analysis skill might tell the agent to read the business context, retrieve competitor activity, compare results and propose content ideas with supporting sources.

A bundled script can help with part of that work. But adding the skill to Claude or ChatGPT does not, by itself, establish a shared data store or a collection process that keeps running after you close the conversation.

For a business task, check which systems the skill can actually read from or act on.

We have been building a social media agent for Swiss Product Studio. It needs competitor posts, account information and measurements collected at known times.

There is little reason to ask a language model to decide, every few hours, that it should fetch the same accounts and save the results. Once the sources and collection rules are defined, that is a regular automation task.

A scheduled n8n workflow can do it. So can a custom collector deployed to a cloud host. The important part is having a running process that retrieves the data, handles failures and records the outcome. n8n's Schedule Trigger, for example, starts workflows at fixed intervals or times. ³

Fetching a known endpoint, checking IDs, removing duplicates and saving records can all happen without a language-model call. Ordinary collection does not need to consume your Claude or OpenAI credits.

Use AI where interpretation helps: deciding what a pattern means, assessing a source or developing an idea. Let the collector keep doing its defined job in the background.

Once you collect the data, where does it go?

For an experiment, saving files on your laptop is convenient. For a company process used by several people, agents and tools, a shared database provides a more useful foundation.

The social media agent can read the same records as a dashboard. Another assistant can use them for a report. An authorised application can make them available from a laptop or phone, without depending on a particular conversation or one person's computer.

You also keep the history when the assistant changes. The company might use Claude today and an OpenAI-based agent six months later. A separately managed database and collection process give both a consistent place to work.

You may need to adapt a connector or tool interface. You should not have to collect the company's history again because you changed the model reading it.

A database needs more thought than somewhere to put the collector's output. Its data model defines what the records represent and how they relate.

For our studio's social media agent, we separated the brand being promoted, the companies or people being tracked, their social accounts, their posts and the observations collected for those posts.

A post's publication time and a metric's collection time are different facts. Saving them separately lets the agent distinguish a post published yesterday from an older post measured yesterday. Repeated observations can then support a comparison over time.

Relationships matter too. One company can have several accounts. One account can have many posts. One post can have several measurements. Stable IDs connect those records without asking the model to match names from scratch every time.

Our first review also found a personal post inside a company feed. Before comparing its engagement with the company's follower count, we needed to verify who actually wrote it. The records and source references made that check possible. A well-written instruction alone could not supply the missing attribution.

The same thinking applies to customers, invoices, projects and meetings. Define the entities, relationships, dates and business rules so the agent can query meaningful records. AWS describes shared terminology, relationships and metric definitions as part of giving agents the business context behind the data. ⁴

If you have numerical data in a database, use the database to calculate with it.

An agent can translate a question such as “Which of these accounts had the highest median interaction rate last month?” into a suitable query or call a tool that runs an agreed calculation. SQL can filter the records, join the relevant tables and calculate the result. The language model can then explain it.

That gives you a calculation you can inspect and repeat. PostgreSQL provides aggregate functions for counts, sums, averages and statistical calculations, along with numeric types for quantities that require defined precision. ^{5 6}

The query and business definition still need to be right. Dividing a person's post interactions by a company's followers remains a bad comparison, even when SQL executes the arithmetic perfectly.

For our own social media analysis, we used a calculator and independently checked the results with SQL. The principle is the same: execute the mathematics in software, rather than asking the language model to produce a number from its reasoning.

A skill can document the formula and when to use it. A tested query or calculation tool performs the work.

Now consider meeting transcripts. If you have hundreds of long conversations, repeatedly handing all the raw text to an assistant is a poor default for finding one relevant discussion.

You can keep the original transcripts, split them into useful text sections and store each section with a meeting ID, date, speaker information and a reference to its location in the original transcript. Vector embeddings represent the meaning of the text as numbers, helping the system find relevant sections even when the question uses different words. Keyword search can work alongside this semantic search. ⁷

The embeddings can be stored in a vector database or in a relational database with vector support. ⁷

This supports retrieval-augmented generation (RAG): the system retrieves relevant company information and gives it to the language model as context for its answer. Vector embeddings help find the information. RAG is the wider process of using retrieved information to generate a response. ⁴

For example, a question about a client's pricing objections can first narrow the search to that client's meetings, then retrieve the relevant text sections. The agent can use those sections to answer and link back to the original transcripts when someone wants to check the context.

This is another data-model decision: how the text is organised, which metadata connects it to the business and how access is controlled. A small set of documents may only need ordinary text search. A larger, varied archive may benefit from semantic or hybrid retrieval.

Generating vector embeddings can itself use a model and incur a cost. It is a separate, defined processing step, rather than asking a conversational agent to reread the whole archive for every question.

The architecture we would aim for separates four responsibilities:

With those parts in place, different assistants can work with the same business systems. Claude can review the data today. An OpenAI-based agent can use it later. A dashboard can query it without involving a language model at all.

That separation also makes the skill easier to improve. You can refine the analysis steps, add a better example or change the expected output while the collector continues running and the database retains its history.

The skill becomes a reusable way to work with the system you have built.

Skills are worth using. They make procedures easier to share, repeat and revise. But building a dependable agent also means deciding which work belongs in ordinary automation, where company data lives and which tools expose it.

For our studio's social media agent, the value comes from connecting those parts: collection processes, structured records, reproducible analysis and instructions that help the assistant turn the results into useful proposals.

Start with one task and identify its data source, collection schedule, storage and required tools. Keep improving the skill file as you go, while those systems remain useful when the conversation ends or the model changes.

1. Anthropic: Equipping agents for the real world with Agent Skills. Skill instructions, progressive loading and bundled scripts. ↑1
2. Agent Skills specification. Required entry file and optional resources. ↑1
3. n8n: Schedule Trigger. Running published workflows at defined intervals and times. ↑1
4. AWS: Building a data foundation for agentic AI. Data relationships, metric definitions, freshness and business meaning. ↑1 ↑2
5. PostgreSQL: Aggregate functions. Calculations over sets of records. ↑1
6. PostgreSQL: Numeric types. Integer, exact numeric and floating-point types. ↑1
7. Supabase: Semantic search. Embeddings, search by meaning and combining semantic with keyword search. ↑1 ↑2