Prompting for a Specialty

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 scope	Bad scope
`Kubernetes Operator` — handles K8s-only problems	`Storage Manager` — filesystem + mount points + cloud storage + backups (too broad; should be 3-4 specialties)
`AWS CLI` + `Terraform` as separate specialties	`Everything Infrastructure`
`Linux Disk Manager` + `Windows Disk Manager`	`Disk 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

Out	Belongs in
Tool usage instructions for standard CLIs	Tool definitions — the agent already gets these
Exhaustive knowledge dumps about the environment	Operational Rules + Knowledge
Task-specific behavior that only applies to one ticket type	Operational 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.

​Scope first

​What goes in a specialty

​1. How to approach a task

​2. Perspective and judgment style

​3. Worked examples for typical problems

​What does NOT belong in a specialty

​When to split a specialty