> ## 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.

# Specialty

> MDX frontmatter reference for specialty resources

**Subdirectory:** `specialties/` · **Body:** the specialty prompt

The MDX body is the specialty prompt itself — the text the agent reads to shape how it thinks about a domain. See [Prompting for a Specialty](/0.8/prompting/specialty) for what to put in the body.

## Frontmatter

| Field            | Type                         | Required | Default | Description                                                                                     |
| ---------------- | ---------------------------- | -------- | ------- | ----------------------------------------------------------------------------------------------- |
| `org`            | string \| null               | No       | tenant  | Organization name. Omit (or `null`) to make the specialty available to every org in the tenant. |
| `name`           | string                       | **Yes**  | —       | Display name. Used by agents to reference this specialty.                                       |
| `description`    | string                       | No       | `""`    | Optional short summary shown in lists.                                                          |
| `execution_mode` | `investigate_only` \| `null` | No       | `null`  | Pin every agent using this specialty to read-only mode (overrides ticket tags).                 |

## Fields NOT supported

* `id`, `tenant_id`, `created_at`, `updated_at`, `key` — system-set (the `key` is derived from `name`)
* The prompt itself — lives in the **body**, not frontmatter

## Example

```mdx specialties/linux-administration.mdx theme={null}
---
org: platform-team
name: linux-administration
description: Generalist Linux operator — system services, file system, package management.
---
# Identity

You are a senior Linux operator. You prefer reversible, incremental changes
and you always verify state before and after acting.

# Process

1. Inspect first — confirm service status, recent logs, and configuration
   before reaching for a fix.
2. Validate the proposed change in isolation when possible (`nginx -t`,
   `systemctl --dry-run`, `--dry-run` on Ansible, etc.).
3. Apply the smallest change that resolves the issue.
4. Re-verify after acting and report what changed.

# Warnings

- Service restarts can drop in-flight requests. Prefer `reload` where the
  service supports it.
- Do not `mkfs` on any block device without explicit confirmation from a human.
```

## Gotchas

* **`execution_mode: investigate_only` is a ceiling.** Any agent using this specialty runs read-only even if a ticket asks for `@2501:remediate`. The resolution comes back as `partial`. Use this on critical-system specialties; lift it explicitly when you want remediation.
* **Changes apply immediately.** Editing the body and syncing affects every agent using this specialty on its very next task — test on a non-critical specialty first.
* **Renaming a specialty is a coordinated change** — every agent referencing it by `name` must update too. Pull first, edit both sides, then sync.