Add YAML agent template files with CLI apply command

[geoffjay]

Context

Creating agents currently requires either shell scripts with embedded curl/jq commands (see scripts/launch-planner.sh, scripts/launch-worker.sh) or long CLI invocations with many flags:

agent orchestrator create-agent \
  --name planner \
  --working-dir /Users/geoff/Projects/agentd \
  --user geoff \
  --shell /bin/zsh \
  --system-prompt "You are a project planning agent..." \
  --prompt "Analyze the agentd project..."

This is hard to version control, share, and reuse. Agent definitions should live as declarative YAML files in the project repository.

Proposal

Support agent template files at .agentd/agents/<name>.yml that fully describe an agent and can be applied with a single CLI command.

Template Format

# .agentd/agents/planner.yml
name: planner
working_dir: "."              # relative to project root, resolved at apply time
user: geoff                   # optional
shell: /bin/zsh               # optional, default: zsh
worktree: false               # optional, default: false
interactive: false             # optional, default: false

system_prompt: |
  You are a project planning agent for the agentd project. Your role is to:
  1. Analyze the codebase structure, especially the crates/ directory
  2. Understand the purpose and architecture of each service/crate
  3. Identify gaps, improvements, and next steps
  4. Propose well-structured GitHub issues

prompt: |
  Analyze the agentd project to identify the purpose of each service
  created in the crates/ directory...

CLI Commands

# Apply a template (create or update the agent)
agent apply .agentd/agents/planner.yml

# Apply all templates in a directory
agent apply .agentd/agents/

# Dry-run to see what would be created
agent apply --dry-run .agentd/agents/planner.yml

# Apply with overrides
agent apply .agentd/agents/planner.yml --working-dir /other/path

# Validate template without applying
agent validate .agentd/agents/planner.yml

Acceptance Criteria

• Define YAML schema for agent templates (matching CreateAgentRequest fields)
• Add serde_yaml (or serde_yml) as workspace dependency
• New agent apply <path> CLI command that:
  • Reads YAML file(s) from path (file or directory)
  • Resolves relative working_dir to absolute path based on file location
  • Creates agent via orchestrator API
  • Prints agent ID and status
• New agent validate <path> CLI command for offline validation
• Support --dry-run flag to show resolved config without creating
• Support field overrides via CLI flags (e.g., --working-dir, --prompt)
• Support environment variable interpolation in templates (e.g., $HOME, ${PROJECT_ROOT})
• The name field in the template is used as the agent name — if an agent with that name already exists and is running, warn and skip (or add --replace flag)

Relevant Files

• crates/cli/Cargo.toml — add serde_yaml dependency
• crates/cli/src/main.rs — new apply and validate top-level commands
• crates/cli/src/commands/ — new apply.rs module
• crates/orchestrator/src/types.rs — CreateAgentRequest (source of truth for fields)
• scripts/launch-planner.sh — reference for what the template replaces

Design Notes

• Templates are not stored server-side — they live in the project repo as plain files
• The CLI reads the YAML, resolves it into a CreateAgentRequest JSON body, and POSTs to the orchestrator API
• This is intentionally a thin layer: the orchestrator API remains the authority, templates are just ergonomic sugar
• Template discovery: agent apply with no path could default to .agentd/agents/ in the current directory

Dependencies

Blocks: #73, #75

Children:

• Add YAML workflow template files with agent name references #73 — Add YAML workflow template files with agent name references
• Add composite apply command for .agentd/ project directories #75 — Add composite apply command for .agentd/ project directories

Related: #78 (agent templates should support permission_mode/tools fields once implemented)