Skip to main content
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 for what to put in the body.

​
Frontmatter

FieldTypeRequiredDefaultDescription
orgstring | nullNotenantOrganization name. Omit (or null) to make the specialty available to every org in the tenant.
namestringYes—Display name. Used by agents to reference this specialty.
descriptionstringNo""Optional short summary shown in lists.
execution_modeinvestigate_only | nullNonullPin 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

specialties/linux-administration.mdx
---
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.