Skip to main content
They come in two flavors:
  • agent recipes — scaffold one agent workspace
  • team recipes — scaffold a shared team workspace plus role agents
This doc explains the format you actually need to write.

Where recipes live

Recipes are discovered from:
  • built-in plugin recipes: recipes/default/*.md
  • workspace recipes: ~/.openclaw/workspace/recipes/*.md
You can inspect available recipes with:

Smallest useful recipe


Common frontmatter fields

Field meanings

  • id — stable recipe id
  • name — human-readable name
  • kindagent or team
  • version — recipe version string
  • description — short summary
  • requiredSkills — skills the recipe really needs
  • optionalSkills — nice-to-have skills

Agent recipe example

Scaffold it with:

Team recipe example

Scaffold it with:

Team ids and agent ids

Important rule:
  • team ids used with scaffold-team must end with -team in many real setups / conventions
Role agent ids normally become:
Examples:
  • development-team-lead
  • development-team-dev
  • development-team-test

Templates and files

templates

templates is a string map of template names to template bodies.

files

files tells ClawRecipes which files to write into the scaffolded workspace. Example:

Template rendering

Rendering is intentionally simple:
  • {{var}} replacement only
  • no conditionals
  • no code execution
Common variables include:
  • agentId
  • agentName
  • teamId
  • teamDir

Tools policy

Recipes can write tool policy into agent config when you scaffold with --apply-config. Example:
Team recipes can also define per-agent tool policies.

Cron jobs

Recipes can optionally define cron jobs. Example:
Notes:
  • use valid 5-field cron
  • keep id stable
  • ClawRecipes can install/reconcile these during scaffold

Skill declarations

If a recipe declares skills, you can install them with:
That installs the recipe’s declared requiredSkills / optionalSkills.
  • keep recipes small and readable
  • keep requiredSkills minimal
  • use optionalSkills for non-essential extras
  • prefer file-first workflows
  • make the generated workspace obvious to a human reader
  • include enough commands/examples in generated docs that a user can actually run the system

Good next steps

After reading this, do one of these:
Then read: