Skills

A skill is a procedure you write once — how your company builds a BOM from a request email, how you wire a divisible room — that every AI agent in AVstackr then follows.

Why skills exist

Your best estimator has a process. They read the customer's email a particular way, they check certain things before pricing, they know which shortcuts cause callbacks later. That process lives in their head. When they're on holiday, the work gets done differently — and worse.

Skills are where that process goes instead. You describe the procedure in plain language, and from then on the AI follows your steps rather than improvising its own.

Skills and memory are different things

AVIP Assistant already has memory — it remembers facts. That you prefer Crestron over Extron. Your labor rate. The contact at a particular GC.

Skills are procedures. Not what's true, but how work gets done. The distinction matters when you're deciding where something belongs:

• "Our standard markup is 22%" — that's a fact. It goes in memory.
• "When a customer emails a scope, read the thread, create the customer, then the project, then the rooms they named" — that's a procedure. It goes in a skill.

Together they form what people building AI systems have started calling the agent's brain: the durable knowledge an agent carries between conversations, as opposed to whatever happens to be in the current chat.

How an agent decides to use one

Agents don't read every skill on every request — that would be slow and expensive. Instead, each agent sees a short index: every skill's key and its trigger description, one line each. When your request matches a trigger, the agent opens that skill and follows the steps inside.

This is why the trigger description carries more weight than anything else you write. The body can be excellent and never get used if the trigger doesn't sound like the thing you actually ask for.

Writing a skill

Open Skills in the sidebar and click New skill. Four fields:

• Name — what it's called, in plain words.
• Key — a short identifier like bom-from-email. Spaces become hyphens as you type, and it's fixed once created.
• Trigger description — one sentence, phrased the way you would actually ask. "Build a BOM from a customer's request email" works. "BOM utility" doesn't.
• Body — the procedure itself, in Markdown.

The body follows a four-part shape. You don't have to use it, but agents follow skills more reliably when you do:

## When to use
Trigger phrases someone would actually say.

## Steps
1. Read the email thread — note location and job number.
2. Create the customer, then the project against it.
3. Add the rooms if the scope names them.

## Tools
- create_customer — before the project, so it has an owner
- create_project — one per request, never one per room

## Pitfalls
- Don't invent rooms from a floor-plan attachment. Ask instead.

The Pitfalls section is the one people skip and later wish they hadn't. It's where a mistake gets recorded once so it stops repeating.

Letting the copilot write it for you

You don't have to author skills by hand. Run a job with AVIP Assistant the way you want it done, then say "skillify this". It drafts the procedure from what just happened, shows you the draft, and saves it once you approve.

Before drafting, it checks whether the job is worth saving at all: will you do this again, is it more than a single step, and is there a phrase you'd naturally use to ask for it? A one-off gets a polite no rather than clutter.

Yours, or your company's

New skills are personal — only your agents follow them. When one is good enough to be the way everyone does it, click Share on the card and it moves to Company skills, where every agent in your organization follows it.

Unshare moves it back out of circulation and into your personal skills. Anyone in your company can edit, share, or unshare a company skill, so treat it the way you'd treat a shared template — and note that replacing an existing company skill is deliberate by design: saving over one requires explicit confirmation, so a team standard can't be overwritten by accident.

Platform skills

There is a third pool alongside yours and your company's: Platform skills, maintained by AVstackr. Every company's agents can see them from day one, with nothing to write or share first. A few platform procedures are sold separately under a license — an agent following one for a company that hasn't bought it gets a purchase link instead of the steps.

When skills in different pools share a key, the more specific one wins, key by key: your personal skill wins over your company's, and your company's wins over the platform's.

Platform skills are read-only. To change one for your company, open it, click Customize, and save — that makes a company copy under the same key. From then on your company follows its own copy and no longer receives AVstackr's updates to that one skill, while every other platform skill keeps updating. A licensed platform skill your company hasn't bought opens locked: no body, no Customize, just a link to buy the license.

Keeping triggers distinct

An agent picks a skill by matching your request against trigger descriptions, so two triggers that describe the same request leave it guessing. If an agent keeps reaching for the wrong procedure, the fix is almost always in the trigger, not the steps — name the situation narrowly enough that only one skill fits.

Where skills are followed

• AVIP Assistant — reads, writes, and updates skills; this is where skillify lives.
• Schematics agent — reads and follows them, useful for standard wiring procedures. It doesn't author them.
• External MCP clients — Claude Desktop, Cursor, your voice agent. Four tools (skill_list, skill_read, skill_save, skill_delete) serve all three pools and are documented in MCP Server.

A skill you write once is followed everywhere. Sharing and unsharing stay in this page on purpose — moving a procedure to company-wide is a decision a person makes, not an agent.

Getting started

Don't try to write your whole process on day one. The skills that work best come from a job you just finished and thought went well. Do the work with the copilot, say "skillify this," check the draft, and keep it personal until you've watched it run correctly a couple of times. Then share it.