Create a Skill

Why this matters

A Skill is a reusable instruction pattern: the way you want an agent to handle a specific kind of work, packaged once and attached to as many agents as need it. If you’ve ever found yourself typing the same instructions into chat over and over (“when summarizing, always include action items by owner…”), that pattern wants to be a Skill.

Skills sit alongside context files and tool policies. Context files give the agent knowledge, tool policies give it reach, and Skills give it specific, reusable behaviors it should always apply. Today, you build one. The next time that kind of work comes up, your agents handle it the way you want without you reminding them.

Skills package “how you want this handled” once; agents inherit the pattern wherever you attach: no dedicated Settings UI yet, so conversation plus confirm is still the authoring loop.

Quick start

Skills today ship through Admin-Agent chat plus the REST API: no Skills page in Settings yet (roadmap item). Paste the recurring behavior first; approve the drafted structure before attachments land so tone stays yours.

1. Sign in: open Auxot in your browser and log in.
2. Open chat with the Admin Agent: click Chat in the left menu, make sure the agent picker reads “Admin Agent.”
3. Describe the pattern you want bundled: type something like “I want a Skill that tells any agent to always cite sources when answering research questions, and to flag when a source is older than two years.”
4. Answer the Admin Agent’s questions: what to call the Skill, which tools it needs, and which agents to attach it to.
5. Confirm: the Admin Agent creates the Skill and attaches it to the agents you named, in one move.

Done? The Skill is live. Any agent it’s attached to picks up the pattern when you chat with that agent: test it by sending a question the Skill should shape.

The agent can do that?

Pattern capture beats blank YAML: paste recurring work into Admin-Agent chat first; skim the proposal, tighten wording, confirm: API power users can script the same payloads later.

1. Bundle a repeating task from chat history

Chat → Admin Agent:

I keep doing this kind of work with my "[agent name]": [describe a recurring task — e.g., "every Monday I ask it to read last week's customer feedback and pull out themes, but I have to remind it every time to organize by sentiment and to only include feedback with at least two mentions"]. Bundle that into a Skill and attach it to the agent. Give the Skill a clear name.

Why it’s non-obvious: Naming and instruction boundaries stall people who otherwise ship great chat. Narrating “every Monday…” hands the scaffolding work to the assistant; you sanity-check attachments and required tools before anything goes live.

2. Promote a pasted prompt into a Skill

Hold a prompt that already survives review? Paste verbatim:

I've been pasting this prompt into chat with my "[agent name]" every time I want a contract review: [paste the prompt]. Turn this into a Skill so the agent applies these instructions automatically when I ask for a contract review. Attach it to that agent.

Why it’s non-obvious: Winning prompts evaporate inside threads. Turning the paste into Skill instructions pins the shape while you still prune edge-case fluff manually.

3. Untangle orphaned Skills vs agents

After the library grows:

Look at my agents and the Skills I've created. Which Skills are attached to the right agents? Are there agents that should have a Skill they don't have? Are there Skills attached to agents that don't actually need them? Be specific about which Skill goes where.

Why it’s non-obvious: Passive libraries sprawl: research agents sans citation Skills while brand voice hangs on infra bots. Paste for a remap plan, then detach or attach deliberately; nothing auto-balances overlaps for you yet.

Go deeper

Skills vs context files vs tool policies: what’s the difference?

These three are the levers you have for shaping how an agent works:

• Context files = knowledge the agent has access to. Brand voice docs, FAQs, and product specs. They tell the agent what to know.
• Tool policies (with MCP servers) = capabilities the agent can reach for. APIs, integrations, and external systems. They tell the agent what to do.
• Skills = reusable instruction patterns. Specific behaviors the agent always applies. They tell the agent how to handle certain kinds of work.

You’d use a context file for “our brand voice is friendly, direct, no jargon.” You’d use a Skill for “when responding to a customer complaint, always: acknowledge → summarize → propose next step.” Different layers, different purposes.

Skill scopes

Like context files, Skills have three scopes:

• User scope: only your agents see this Skill. Use for personal patterns.
• Team scope: all team-scoped agents can use this Skill. Available on Business tier and above.
• Org scope: all org agents can use this Skill. Use for company-wide behaviors (citation rules, compliance patterns).

Org admins create org-scoped Skills. Team admins create team-scoped. Any user can create user-scoped.

The required_tools list

A Skill can declare which tools it needs to function (e.g., “this Skill requires get_calendar_events to work“). If you attach a Skill to an agent that doesn’t have those tools, the Skill won’t function correctly. The Admin Agent checks this when attaching: if a tool is missing, expect a suggestion to extend the agent’s tool policy.

Skills today: API + Admin Agent only

Skills don’t have a dedicated Settings page yet. The full feature set is available via:

• The Admin Agent: chat-based create / attach / edit / delete (recommended).
• The REST API: POST /api/skills, GET /api/skills/{id}, PUT, DELETE, plus the agent-attachment endpoints under /api/agents/{agentId}/skills.

A dedicated Settings page is on the roadmap. For now, the Admin Agent is the path: conversational creation is genuinely faster than form-filling for most Skills.

Pre-installed Skills

Auxot ships one builtin Skill: auxot-openui (used internally for rendering OpenUI apps). You don’t manage this one; it’s there to make other features work. Your custom Skills sit alongside it.

Troubleshooting

• The Admin Agent says “Permission denied” when creating a Skill. Skill creation requires admin permissions for org and team scopes. User-scoped Skills work for everyone. If you need an org-scoped Skill and aren’t an admin, ask whoever is.
• The Skill is attached but the agent isn’t applying it. The Skill’s instructions might conflict with the agent’s existing description, or the pattern only triggers in specific conditions that aren’t being met. Test with a clear example case. If still not working, ask the Admin Agent to review.
• The agent’s behavior changed in unexpected ways after I attached a Skill. Skills add to the agent’s behavior; they don’t replace it. If the new behavior is wrong, the Skill’s instructions need refinement. Ask the Admin Agent to update the Skill.

Variations & edge cases

• Attaching one Skill to multiple agents: The Skill is defined once and applied everywhere it’s attached.
• Multiple Skills on one agent: supported. Skills have a sort_order that controls which one applies first when multiple match.
• Editing a Skill in place: changes the Skill for every agent it’s attached to. Useful when you want to update a pattern across all your agents at once.
• Disabling vs detaching: is_active = false keeps the Skill in your library but stops it from being applied. Detaching removes it from a specific agent.
• Free tier: Skills work at all tiers. Team-scope and org-scope Skills depend on having the right tier for teams (Business+).

Walkthrough

Skills are built and attached through the Admin Agent: chat-based, no Settings UI today.

Step 1: Open chat with the Admin Agent

Click Chat in the left menu. Make sure the agent picker at the top reads “Admin Agent.”

Step 2: Describe the pattern you want bundled

Talk to the Admin Agent like you’d talk to a colleague who’s helping you write a runbook. The clearer the recurring pattern, the better the Skill:

• “I want a Skill that tells any agent to cite sources when answering research questions, and to flag when a source is older than two years.”
• “Bundle this into a Skill: when summarizing meeting notes, always organize by decisions, action items by owner, and unresolved questions.”
• “Create a Skill for our customer support agent that always: acknowledges the issue, asks the right diagnostic question if unclear, and offers a human handoff for technical complaints.”

Be specific about what the agent should always do. That’s what a Skill is for.

Step 3: Answer the Admin Agent’s questions

The Admin Agent will work through:

• What to call it: a clear name that anyone scanning your Skills list will understand.
• What scope it should have: User (personal), Team (team-shared), or Org (everyone).
• Which tools it needs: if the Skill’s instructions mention specific tools, the Admin Agent will list them.
• Which agents to attach it to: pick one or more.

Step 4: Confirm and create

The Admin Agent proposes the full Skill (name, scope, instructions, required tools, and attached agents). Read it. If it looks right, say “yes, create it” (or anything similar).

The Skill is created and attached in one move. The Admin Agent confirms and tells you which agents now have it.

Step 5: Test the Skill

Open chat with one of the attached agents and ask a question the Skill should shape. If the agent’s response follows the pattern, you’ve wired it right. If not, head back to the Admin Agent:

The "[agent name]" isn't applying the "[Skill name]" Skill correctly when I ask [example question]. What's wrong, and how do we fix the Skill's instructions?

The Admin Agent reasons over the Skill, the agent metadata, and your example: tighten instructions from there yourself if copy still misses.

Tip: If you find yourself running the same prompt in chat every week, that’s a Skill waiting to happen. Tell the Admin Agent: “Turn this prompt into a Skill and attach it to my [agent name].”

What’s next

• → Add your first context file. Skills give patterns; context files give knowledge. Often you want both on the same agent.
• → Define a tool policy. If your Skill requires specific tools, the agent needs a tool policy that grants them.
• → Add an MCP server. Extend what tools are available; combine with Skills to make agents that handle complex work.
• → Set up multi-team isolation. When the same org needs different Skills and tool surfaces per department, team rows are the boundary.

Reference

• How Skills are created today: via the Admin Agent (chat) or the REST API. A dedicated Settings page is on the roadmap.
• Built-in Skill: auxot-openui (used internally for rendering apps).
• Skill scopes: User / Team / Org
• Skill structure: name, description, instruction body, required tools, scope, and is_active flag
• Agent attachment: per-agent, with sort_order to control priority
• API endpoints: /api/skills and /api/agents/{agentId}/skills
• See also: Add your first context file, Define a tool policy, Add an MCP server, Set up multi-team isolation