Skip to main content
This guide walks you through creating a custom identity from scratch. For the full identity.yaml field reference, see Identity Manifest.
The fastest way to create a new identity is with army-create — run npx army-create to scaffold all required files interactively. You can also copy the example identity and modify it, or see the multi-agent example for a complete multi-agent deployment.

Identity Structure

An identity is a self-contained directory with an identity.yaml manifest and workspace files:
Identities can live in a Git repo, a subdirectory of a monorepo, or a local directory on disk.

Step 1: Create identity.yaml

Start with the required fields:
Then add optional configuration as needed:
See the Identity Manifest Reference for the complete field listing.

Step 2: Write Workspace Files

SOUL.md — Personality

The most important file. It shapes how the agent thinks and communicates. Define:
  • Core truths — fundamental principles that guide behavior
  • Superpowers — what this agent excels at
  • Boundaries — what the agent should avoid or defer on
  • Vibe — one-line personality summary
  • Continuity — remind the agent that these files are its memory
Keep it focused — 30-50 lines is plenty. Agents work better with clear, concise personality guidance.

IDENTITY.md — Name Card

Short file with the agent’s name, role, emoji, and a one-line role description. Keep it to 5-10 lines.

HEARTBEAT.md — Periodic Tasks

A checklist the agent runs on each heartbeat cycle (every minute). Always include a bootstrap check at the top:

TOOLS.md — Tool Reference

A cheat sheet for the tools available to the agent:

AGENTS.md — Operational Instructions

Shared instructions for multi-agent coordination. Covers session startup, memory management, safety rules, and heartbeat behavior. You can use the example AGENTS.md as a starting point.

BOOTSTRAP.md — First-Run Setup

Integration checks that run once when the agent is first deployed. Verify each tool and plugin works, then delete the file. If any check fails, the file stays and the agent reports the failure.

USER.md — Owner Info

Templated file with the agent owner’s details:

Step 3: Create Skills

Skills are reusable workflows. Each skill lives in skills/<skill-name>/SKILL.md with YAML frontmatter:

Frontmatter Fields

Private vs Public Skills

Step 4: Use Your Identity

During Development (Local Path)

For Production (Git Repository)

Push your identity to a Git repo:

Monorepo Layout

Multiple identities can share a single repo:
Reference each with https://github.com/org/my-identities#researcher, #analyst, etc.

Template Variables

Workspace files support {{VARIABLE}} substitution.

How It Works

  1. Declare variables in templateVars in identity.yaml
  2. Use {{VARIABLE_NAME}} in any workspace file
  3. During clawup init, any template variables not auto-filled from owner info must be added to templateVars in clawup.yaml
  4. Values are substituted before files are injected into the agent

Standard Variables

Custom Variables

You can define any variable name:
Then reference them in workspace files: Check open issues in {{LINEAR_TEAM}}.

Declaring Additional Secrets

If your identity needs secrets beyond what its plugins and deps imply (e.g., a Notion API key, a Sentry DSN), declare them in requiredSecrets:
Each camelCase key is converted to SCREAMING_SNAKE_CASE and prefixed with the agent’s role for the env var name. Add the values to your .env file — clawup deploy validates that all required secrets are present and reports any that are missing. This is additive — plugin/dep-implied secrets are always included. If a key appears in both requiredSecrets and is already implied by a plugin, it won’t be duplicated. See Environment Variables for full details on secret resolution.

Tips

  • Start with army-create. Run npx army-create to scaffold a new identity interactively (GitHub · npm). Or copy examples/identity/ for a single agent, or examples/multi-agent/ for a full PM + Engineer + Tester fleet.
  • Keep SOUL.md focused. 30-50 lines is plenty. Agents work better with clear, concise personality guidance.
  • Test locally first. Use a local path identity during development, switch to Git URL for production.
  • One skill per workflow. Each skill should handle one complete workflow. If a skill is doing too much, split it.
  • Use user-invocable: false for skills that are triggered by the system (queue handlers, routers) rather than by users.