sqemes blog

What are AI skills, and why teams need more than prompts

2026-11-12T00:00:00.000Z

Most teams start their AI journey with prompts. Someone writes a good one for a press release, shares it in a chat, and soon there is a document full of prompts that everybody copies from. It works for a while. Then the brand voice changes, the product gets a new feature, and half of those prompts quietly become wrong.

The missing piece is usually not a better prompt. It is the knowledge behind it.

Prompts are tasks, skills are knowledge

A prompt is what to do: a task with a few fields someone fills in. "Write a launch announcement for {{product}}, published on {{date}}." It produces a draft, and the next person can run it again with different values.

A skill is what to know: a reusable block of company knowledge that every answer should respect. Your brand voice. What your product does today. The rules for how your team writes a proposal, reviews code or answers a support ticket. A skill is not tied to one task. It applies whenever a task is in its scope.

The difference matters because knowledge changes more slowly than tasks, but it changes everywhere at once. When your positioning shifts, you do not want to edit thirty prompts. You want to update one skill.

What goes into a good skill

A good skill reads like the briefing you would give a new colleague on their first day:

The rules. Tone, wording you use and wording you avoid, the claims you never make.
The facts. What the product does, what it does not do, what changed in the last release.
The way of doing something. The structure of a good proposal, the checklist for a code review.
Files, when they help. A style guide, reference documents, a logo, even scripts that an AI tool can run on its side.

In sqemes, files are stored once per workspace and attached to the skills that need them. Update the file, and every skill that uses it works with the new version.

Where skills work

A skill is only useful if it reaches the place where people actually work with AI. That is rarely one tool. Marketing may prefer ChatGPT, engineering works in Claude Code or Cursor, and someone else uses Gemini.

That is why sqemes brings the same skill into every channel:

In ChatGPT, Claude and Gemini, the browser extension applies it next to the input box.
In sqemes Chat, it works with any AI provider you connect.
In Claude, ChatGPT, Claude Code, Cursor, Codex and other tools that support MCP, the AI tool can find the right skill mid-task and load it on its own, starting with the outline and reading a file only when the task needs it.

Why the knowledge part decides the quality

Ask two AI tools the same question without context, and you get two generic answers. Give both the same skill, and the answers start to sound like your company: the same terms, the same facts, the same tone. The task did not change. The knowledge did.

This is also why the value of a team's AI setup grows over time. Prompts are easy to write and easy to replace. A library of well-kept skills is the part that is hard to rebuild, because it holds what your company knows.

How to start

You do not need a big project. Pick the one piece of knowledge your team repeats most often, usually the brand voice or the product facts, and write it down as a skill. Use it for a week in the tools your team already uses. Then add the second one.

If you want to skip the blank page, the sqemes Setup Wizard drafts starter skills and prompts from your website, and the marketplace has ready-made playbooks you can adapt.

Learn more about skills or see how personas decide which skill to load.

How to give Claude Code, Cursor and Codex your team's coding standards

2026-11-12T00:00:00.000Z

Coding agents are only as good as the context they get. Without it, they write code that compiles but does not look like your codebase: different naming, a different error handling style, tests in the wrong place. So teams start feeding them context. And that is where the trouble begins.

The copy problem

The usual first step is a rules file in each repository. It works for one project. With five repositories, you have five copies that drift apart. Someone updates the error handling rule in one of them, the others keep the old version, and the agent in the next repository happily follows the outdated one.

The same happens across tools. One developer uses Claude Code, another Cursor, a third Codex. Each tool has its own place for instructions, and each copy needs to be kept in sync by hand.

One source, loaded on demand

The alternative is to keep your standards in one place and let the agents fetch them when a task needs them. That is what MCP, the Model Context Protocol, is for: an open standard that lets AI tools use outside tools and data.

With sqemes connected over MCP, an agent gets tools to search your library and load a skill. When a task touches your API, it can find the skill with your API conventions and load it. When a pull request is ready, it can load the review checklist. Nobody has to paste anything.

Skills load step by step. The agent sees the outline of a skill first and reads a reference file only when the task needs it, so a large style guide does not fill the context window for a one-line fix.

What to put into an engineering skill

Start with what reviewers comment on most often:

Coding conventions: naming, structure, error handling, logging.
The review checklist: what a pull request must have before it can be merged.
Architecture context: how the system fits together, as a reference file the agent reads when it needs it.
Docs style: one guide for every README and doc page.

A skill can also carry script files. They travel with the skill, and the tool that loads them runs them on its side. sqemes itself never runs code from a skill.

Personas for roles

Once you have a few skills, a persona ties them together. A Tech Lead persona can say: load the coding conventions while code is written, load the review checklist when a pull request is reviewed, use the release notes prompt when a version ships. Over MCP, Claude Code, Cursor and Codex can load that persona and work in the role.

Setting it up

In sqemes, Settings, API and MCP walks you through each client in three steps. Every developer connects with their own account and sees the playbooks they have access to. The rights are the same as in the app: if a skill is restricted to the platform team, it stays restricted in every agent.

Change a convention once, and every agent loads the new version from then on. With review switched on, a change to a shared skill waits for release before the rest of the team works with it.

See how the MCP server works or what sqemes does for engineering teams.

How to keep every AI answer on brand in ChatGPT, Claude and Gemini

2026-11-12T00:00:00.000Z

Every marketing team has brand guidelines. Most of them live in a PDF that nobody opens while writing a LinkedIn post at five in the afternoon. With AI in the mix, the gap gets wider: each person prompts their favourite tool in their own words, and the results sound like five different companies.

Why guidelines do not reach the chat

Guidelines fail for a simple reason: they are not where the writing happens. The writing now happens in ChatGPT, Claude, Gemini or a chat inside some other tool. If the brand voice is not in that chat, the AI does not know it.

Pasting the guidelines into every conversation does not work either. People forget, paste an old version, or paste only the part they remember.

Turn the brand voice into a skill

A brand voice skill is the part of your guidelines an AI actually needs, written so it can follow it:

Tone: for example confident, plain and warm.
Words you use and words you avoid, with examples.
Claims you never make, and the facts you can state.
Formatting rules: headlines, exclamation marks, length.

Keep it short and concrete. "We write like a helpful expert, not like an advert" is more useful to an AI than three paragraphs about brand values.

Product facts belong in a second skill. Then a launch post can be checked against what the product really does, and when the product changes, you update the facts once.

Bring it into every tool

The brand voice only helps if it is there when someone writes. With sqemes:

The browser extension applies the skill in ChatGPT, Claude and Gemini, next to the input box.
sqemes Chat uses it with any AI provider you connect.
Tools that support MCP can load it on their own when a task calls for it.

Add prompts for the work you repeat, such as the newsletter or the campaign brief. The prompt holds the task, the skill holds the voice.

Files in your look

Text is only half of it. Ask sqemes Chat for a one-pager, a Word document or slides, and the file comes out in your workspace's document style: your colours, font, logo, header and footer. A skill can also describe a different look, for example for a sub-brand.

Keep it under control

A brand voice that anyone can edit stops being a brand voice. Decide who may edit the skill and keep it readable for everyone. With review switched on, a change waits until someone releases it, and the team keeps working with the released version meanwhile. Every saved change is a version you can restore.

A simple first week

Write the brand voice skill from your guidelines, one page at most.
Add the product facts as a second skill.
Ask two colleagues to use both for a week in their usual tool.
Collect what the AI still gets wrong and add it to the skill.

See what sqemes does for marketing teams or learn how skills work.

AI personas: roles that load the right knowledge at the right moment

2026-11-12T00:00:00.000Z

Once a team has more than a handful of skills and prompts, a new question appears: which one should be used for this task? People should not have to remember. The AI should know. That is what a persona is for.

What a persona is

A persona is who to be: a working role like Tech Lead, Account Executive or Support Specialist. It has two parts:

A description of the role, in plain words, like a short job description.
A list of playbooks, each with a condition that says when to load it. "Load the positioning skill when researching an account. Use the proposal prompt when an offer is needed."

A persona is not another kind of playbook. It does not copy the skills and prompts it uses; it links to them. Update a skill once, and every persona that uses it works with the new version.

How a persona decides

A persona loads one playbook at a time, only when its condition applies. Ask it to research a prospect, and it loads your positioning. Ask it for a follow-up after a call, and it adds the follow-up prompt. A reply to a quick product question may only need the product facts.

If a task needs something none of its playbooks covers, the AI can look for a fitting playbook in your library and use it within the role.

The conditions are written in prose, and the AI tool does the routing. Nothing runs in the background, and no hidden step happens after the answer.

Where personas work

In sqemes Chat, you pick a persona for a conversation and it stays the role for the whole chat. Or you leave the picker on Automatic, and the AI picks a fitting persona when one applies.
Over MCP, tools like Claude Code, Cursor and Codex can find and load a persona while they work.
The browser extension works with skills and prompts. Personas live in sqemes Chat and in MCP tools.

A persona can also name the services the role works with, such as Notion or Linear. In sqemes Chat, choosing the persona brings each person's own connection into the chat and says when one is missing.

Personas teams start with

Most teams begin with one persona per role that uses AI every day:

Social Media Manager: brand voice for every post, the campaign brief when a launch is coming.
Account Executive: positioning for account research, the proposal prompt for follow-ups.
Tech Lead: coding conventions while code is written, the review checklist for pull requests.
Support Specialist: answers from the product knowledge skill, the escalation prompt when a case needs a person.

Writing your first persona

Write the role in three or four sentences. Then add the two or three playbooks the role uses most and give each a clear condition. Test it with real tasks and check which playbooks it loads: sqemes Chat shows them under every answer. Sharpen the conditions where it picks the wrong one.

Learn more about personas or read what skills are.

Rolling out AI know-how in a company of 250 people

2026-11-12T00:00:00.000Z

In a company of 250 people, AI use usually starts everywhere at once. Marketing has its prompts, sales has a shared document, engineering has rules files in a few repositories, and the rest of the company asks whoever seems to know. Nobody planned it, and nobody knows which version is the right one.

Bringing order to that does not need a big programme. It needs a library, a few clear rules and someone who owns each piece.

Step 1: Start with one team and one skill

Pick the team that already uses AI most and the knowledge they repeat most often. In marketing, that is usually the brand voice. In support, the product knowledge. Write it down as a skill, connect the tools the team already uses, and let them work with it for two weeks.

The point of the first step is not coverage. It is to show that one well-kept skill changes the answers people get.

Step 2: Decide who owns what

Every skill needs an owner: the person who keeps it current. The brand lead owns the brand voice, product management owns the product facts, the platform team owns the coding conventions. Ownership is not a job title in the tool; it is a decision you write down.

In sqemes, who may see a playbook and who may edit it are set separately. Most skills can be visible to everyone and editable by a few. Some, like pricing answers or a hiring plan, should be visible only to the people who need them.

Step 3: Set the defaults once

Instead of deciding every playbook by hand, set workspace defaults for how new playbooks start: who can see them and who can edit them. Use the three roles as they are meant: members use playbooks, editors write them, admins set the rules.

If you want a second pair of eyes, switch on review. New playbooks then stay with their author until they are released, and a change to a shared one becomes a proposal. The team keeps working with the released version until the change is approved.

Step 4: Add personas for the roles

Once two or three teams have their skills, add personas for the roles that use AI every day. A persona knows which skill or prompt to load for which task, so people do not have to choose. This is where the library starts to feel like part of the work instead of another tool.

Step 5: Keep it current

Knowledge goes stale silently. Three habits help:

Update in one place. When something changes, change the skill, not the chats.
Look at what is used. Usage statistics show which playbooks are used in which channel, never who used them. A skill nobody uses is either not needed or not found.
Use versions. Every saved change is kept, so a bad edit is one restore away.

What to keep in mind about data

Before a rollout, people will ask where the content goes. Be ready with clear answers: where the library is hosted (for sqemes, in the EU), whether content is used to train models (it is not), and whether you can use your own AI provider keys (you can). If a team needs everything on its own servers, sqemes can be self-hosted.

See how governance works or what sqemes does for team leads.

Bring your own key: what BYOK means for AI costs and data control

2026-11-12T00:00:00.000Z

BYOK stands for bring your own key. Instead of paying an AI tool for the model usage it buys for you, you connect the API key of a provider you already have a contract with. The requests then run on your account with that provider.

It sounds like a technical detail. For a company, it changes three things: costs, choice and control.

Costs: usage on your own contract

With your own key, the model usage is billed by the provider, at the prices in your contract with them. In sqemes, a workspace's own key is used before any included credits, there is no markup on it, and usage with your own key is not limited by your plan.

That makes costs easier to see. The AI usage shows up where your other AI usage already shows up, on the provider's invoice, instead of being hidden in a per-seat price.

Choice: the models you want

A key also decides which models you can use. Connect keys for the providers you trust, and pick the model that fits each task. With an OpenRouter key, sqemes Chat offers exactly the models your workspace added.

Different teams can use different models for different work, while the knowledge they work with stays the same. The skills and personas do not care which model reads them.

Control: whose terms apply

When a request goes to a provider on your key, it is governed by your contract with that provider. For many companies, that is the point: the AI usage falls under an agreement their legal team has already reviewed.

Independent of the key, a few things stay the same in sqemes: the library is hosted in the EU, your content is never used to train a model, and your keys are stored encrypted.

When included credits are enough

Not every team needs its own key on day one. Every sqemes plan includes a monthly allowance of AI credits for writing playbooks, the Setup Wizard and sqemes Chat. One credit is 1,000 tokens, and the allowance resets every month.

A sensible path for many teams:

Start with the included credits while you build your first skills.
Connect your own key once usage grows, or when a team wants a specific model.
Keep the credits as a fallback for people or tasks without a key.

Self-hosting

If you run sqemes on your own servers, your own keys are the only way: the self-hosted version has no plans and no credits. It is free for your own internal use under the Sustainable Use License.

See pricing and what each plan includes or learn about sqemes Chat.