Skip to main content
A Specialty is a focused prompt that gives the agent a perspective for a domain, technology, or class of host. Think of it like a SKILL.md for an agent: it brings a particular lens, vocabulary, and set of priorities to the tasks it handles.

​
Scope first

Pick a scope that is broad enough not to limit the agent, narrow enough that it doesn’t get lost.
Good scopeBad scope
Kubernetes Operator — handles K8s-only problemsStorage Manager — filesystem + mount points + cloud storage + backups (too broad; should be 3-4 specialties)
AWS CLI + Terraform as separate specialtiesEverything Infrastructure
Linux Disk Manager + Windows Disk ManagerDisk Manager covering both OSes

​
What goes in a specialty

​
1. How to approach a task

General process and tooling guidelines for solving tasks in this domain. Mention the tools at the agent’s disposal, the step-by-step process to troubleshoot, and how to know when to stop and call for a human. 
Good:
"To handle AWS resources, use the AWS CLI to inspect resources. Resources
tagged 'Managed by Terraform' must not be modified directly — propose
Terraform changes instead. After a deep inspection and identifying the
root cause, start operating."

Bad:
"Directly modify resources to optimize tokens. Install missing tools as needed."

​
2. Perspective and judgment style

How the agent frames problems and what it pushes back on. This is the “thinking style” layer. 
Good:
"Prefer incremental, reversible changes. Each dependency encountered
through deployment or logs must also be inspected. If a resource is
outside scope, report back without altering the system."

Bad:
"Solve the crashing service, make no mistakes."

​
3. Worked examples for typical problems

Show the typical sequence a senior operator would follow. Include commands that should be avoided because they are rarely the right approach. 
Good:
"To troubleshoot a crashing container, first identify the problematic
container with `docker ps`. Inspect with `docker inspect <id>` and
`docker logs <id>`. Grep for 'error' to find the root cause. Attempt
restart with `docker compose up -d`. Re-verify state and logs."

Bad:
"Restart the container and see what happens. If not working, redeploy."

​
What does NOT belong in a specialty

OutBelongs in
Tool usage instructions for standard CLIsTool definitions — the agent already gets these
Exhaustive knowledge dumps about the environmentOperational Rules + Knowledge
Task-specific behavior that only applies to one ticket typeOperational Rules — specialties must stay polyvalent
Hard prohibitions (e.g., “never restart X”)Operational Rules — they have higher priority

​
When to split a specialty

If a specialty starts mixing concerns — SSL config, ACLs, redirections, all under “Reverse Proxy” — split it. Smaller, focused specialties produce better outcomes and lower maintenance cost. Rule of thumb: if you can’t explain the specialty’s purpose in one sentence, it’s too broad.