add-specialist

Add Specialist

Register a specialist agent so the Tech Lead considers it during implementation planning, incident analysis, and retrospectives. Trigger vocabulary for the specialist lives in the agent's own description field. This skill registers the agent and optionally adds project-local code-area overrides.

Input

$ARGUMENTS = agent name, optional target type, path-or-slug value, and zero or more project-local code-area override signals.

Register only (subagent, most common case):

my-security-agent
payments-specialist
data-engineer

Register with explicit target type (flag form):

security-gate --target-type=human "Alice Chen (CISO)"
ops-runbook --target-type=doc docs/ops/incident-response.md
write-runbook-skill --target-type=skill write-runbook
external-analyst --target-type=external-agent plugin-x:analyst-agent

Register with explicit target type (positional form):

security-gate human "Alice Chen (CISO)"
ops-runbook doc docs/ops/incident-response.md
write-runbook-skill skill write-runbook
external-analyst external-agent plugin-x:analyst-agent

Register subagent with project-local overrides:

payments-specialist "src/payments/**" "src/billing/**"
data-engineer "src/etl/**"

Trigger keywords such as authentication or pipeline belong in the agent's description, not in this argument list. If keyword-style arguments are provided, a warning is shown (see backward compatibility below).

The five valid target types are: subagent (default), skill, doc, human, external-agent. Omitting the target type registers a subagent entry in the legacy format, preserving full backward compatibility.

Process

1. Parse Arguments

Split $ARGUMENTS on whitespace, respecting quoted strings.

• First token = agent name (required).
• Second token = examined to determine whether it is a target-type token or an override signal:
  • If it is one of the five fixed strings (subagent, skill, doc, human, external-agent), treat it as the target type. The token immediately following it is the path-or-slug value for the registration.
  • If a --target-type=<type> flag appears anywhere in $ARGUMENTS, use that value as the target type. The non-flag tokens after the agent name are the path-or-slug value (if any) and override signals.
  • Otherwise, assume target type subagent and treat all remaining tokens as override signals (existing behavior).
• Path-or-slug value (required for non-subagent target types):
  • skill: the skill slug (e.g., write-runbook).
  • doc: the file path (e.g., docs/security/review-gate.md).
  • human: the contact identifier (name, role, or email address).
  • external-agent: the namespaced slug (e.g., plugin-x:agent-y).
• Remaining tokens = project-local code-area override signals (file globs or repo-specific keywords). May be empty.