> ## Documentation Index
> Fetch the complete documentation index at: https://docs.2501.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Prompting for a Specialty

> Shape how an agent thinks about a domain — vocabulary, priorities, and approach

A [Specialty](/0.8/configure/specialties) 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.

```text theme={null}
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.

```text theme={null}
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.

```text theme={null}
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](/0.8/configure/operational-rules) + [Knowledge](/0.8/configure/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.