Recipe

Recipe System for Claude Code

Recipes are parameterized, composable, shareable YAML workflow definitions. They package instructions + required tools + typed parameters + sub-recipes into portable automation units.

Recipe Schema

version: "1.0"
title: "Human-readable recipe name"
description: "What this recipe does"
author: "creator name"
tags: ["domain", "category"]

# Typed parameters — resolved before execution
parameters:
  - key: param_name
    input_type: string | number | boolean | select | file
    description: "What this parameter controls"
    requirement: required | optional
    default: "default value"
    options: ["a", "b", "c"]  # only for select type

# MCP servers and skills required
requires:
  mcp_servers: ["github", "filesystem"]
  skills: ["security-review"]
  cli_tools: ["ruff", "trivy"]

# Sub-recipes — composable building blocks
sub_recipes:
  - name: "step_name"
    path: "./sub/step.yaml"
    params:
      inherited_param: "{{ parent_param }}"

# Agent routing — which agent should execute
routing:
  agent: "security-engineer"
  authority: "L2"
  risk_tier: "T1"
  fallback: "code-reviewer"

# The prompt template — Jinja-style {{ param }} interpolation
prompt: |
  Execute the following workflow:
  Target: {{ target }}
  Depth: {{ depth }}
  
  Steps:
  1. First do X
  2. Then do Y
  3. Finally verify Z

Recipe Directory

All recipes stored in ~/.claude/recipes/:

~/.claude/recipes/
  lib/              # Shared utilities (recipe-runner.sh)
  sub/              # Reusable sub-recipes
  security/         # Security domain recipes
  engineering/      # Engineering domain recipes
  trading/          # Trading domain recipes
  README.md         # Recipe catalog

Commands

Create a Recipe

/recipe create <name>

Interactive recipe builder:

1. Ask for title, description, tags
2. Ask for parameters (name, type, required/optional, default)
3. Ask for required MCP servers and skills
4. Ask for agent routing preferences
5. Ask for the prompt template
6. Write YAML to ~/.claude/recipes/<domain>/<name>.yaml

Run a Recipe

/recipe run <name> [--param key=value ...]

Execution flow:

1. Load recipe YAML from ~/.claude/recipes/
2. Validate all required parameters are provided (prompt for missing ones)
3. Resolve {{ param }} placeholders in prompt
4. Verify required MCP servers are available
5. Verify required skills exist
6. Load sub-recipes recursively (max depth 3)
7. Route to specified agent or execute directly
8. Track execution in ~/.claude/recipes/lib/history.jsonl

List Recipes

/recipe list [--domain <domain>] [--tag <tag>]

Show all available recipes with their parameters and descriptions.

Convert Skill to Recipe

/recipe convert <skill-name>

Read an existing SKILL.md file and generate a parameterized recipe YAML from it:

1. Extract the skill's triggers and description
2. Identify implicit parameters (things the skill expects the user to provide)
3. Map skill's MCP server usage to requires.mcp_servers
4. Generate the recipe YAML
5. Preserve the original skill (recipes complement, don't replace)

Execution Rules

1. Parameter validation first — never execute with missing required params
2. Tool verification — confirm MCP servers are active before running
3. Sub-recipe depth limit — max 3 levels of nesting
4. History tracking — log every execution with params, duration, outcome
5. Template safety — sanitize parameter values before interpolation (no command injection)
6. Composability — sub-recipes can reference other sub-recipes
7. Idempotency — recipes should be safe to re-run (document exceptions)

Parameter Resolution Order

1. CLI --param key=value arguments (highest priority)
2. Recipe default values
3. Interactive prompt for missing required params
4. Environment variables matching RECIPE_<KEY> pattern

Example: Security Audit Recipe

version: "1.0"
title: "Security Audit Pipeline"
description: "Full security audit: dependency scan, SAST, secrets detection, container scan"
author: "<your-name>"
tags: ["security", "audit", "ci"]

parameters:
  - key: target_path
    input_type: string
    description: "Path to scan (relative or absolute)"
    requirement: required
    default: "."
  - key: scan_depth
    input_type: select
    description: "How thorough the scan should be"
    requirement: optional
    default: "standard"
    options: ["quick", "standard", "deep"]
  - key: fix_issues
    input_type: boolean
    description: "Auto-fix safe issues"
    requirement: optional
    default: false

requires:
  mcp_servers: ["filesystem"]
  skills: ["security-review"]
  cli_tools: ["trivy", "gitleaks", "semgrep", "ruff"]

routing:
  agent: "security-engineer"
  authority: "L2"
  risk_tier: "T1"
  fallback: "security-auditor"

prompt: |
  Run a {{ scan_depth }} security audit on {{ target_path }}.
  
  Steps:
  1. Dependency vulnerability scan: `trivy fs {{ target_path }}`
  2. Secret detection: `gitleaks detect --source={{ target_path }}`
  3. SAST analysis: `semgrep --config=auto {{ target_path }}`
  4. Python lint (if applicable): `ruff check {{ target_path }}`
  {% if fix_issues %}
  5. Auto-fix safe issues where possible
  {% endif %}
  
  Report findings by severity (Critical > High > Medium > Low).
  For each finding: file, line, description, remediation.