Intro to Goose Recipes and Sub-Recipes Goose, an open-source AI agent framework originally created by Block and donated to the Agentic AI Foundation (AAIF), enables users to build reusable, parameterized agentic workflows called recipes, which support sub-recipes as helper functions. The article by avillela explains the anatomy of a Goose recipe using a YAML example that deploys a local Kubernetes cluster with KinD, detailing components such as version, title, description, instructions, prompt, parameters, extensions, settings, and author. Intro to Goose Recipes and Sub-Recipes Using Goose to create re-usable and shareable prompts Last year, as I was starting my agentic AI journey, a tool called Goose https://goose-docs.ai caught my eye. I’ve talked about Goose on a few occasions /tag/goose/ in the past year. 😄 Goose is an open source AI agent framework originally created by Block https://block.xyz/inside/block-open-source-introduces-codename-goose the company formerly known as Square , which was recently donated to the Agentic AI Foundation AAIF https://aaif.io/ . I like Goose because it provides an abstraction layer on top of your LLM e.g. Claude Sonnet, GPT-5.6 Sol, Gemini Flash and provider e.g. Claude, GitHub Copilot, Gemini . This means that you can swap out provider and model combinations but keep your prompts the same. Well, in theory, anyway… not all LLMs are created equal post/prompt-based-reusable-workflows-for-lazy-developers/ lesson-2-llms-are-on-a-spectrum . 🫠 This came in handy for me last year when I was playing around with Goose and ran out of premium tokens on GitHub Copilot and had to switch my model from Claude Sonnet to GPT-4.o. But also, GPT-4.o is no Claude Sonnet. Anyhooooo…there’s another reason why I like Goose: you can use it to create reusable, parameterized agentic workflows, which you can share within and outside of your organization. I like to think of Goose recipes as the Ansible Playbook https://www.redhat.com/en/topics/automation/what-is-an-ansible-playbook of agentic workflows. It also supports sub-recipes. Think of these as helper functions. And with that in mind, today I’ll be digging into how Goose recipes and sub-recipes work. Let’s get started Anatomy of a Goose recipe anatomy-of-a-goose-recipe Below is an example Goose recipe that I wrote called deploy-local-k8s-cluster.yaml , which creates a KinD cluster. version: 1.0.0 title: Local Kubernetes Deployment description: This recipe deploys and configures a local Kubernetes cluster using KinD instructions: | Persona You are a Platform Engineer. Your role is to deploy and configure infrastructure to be used by developers. Rules/inputs/constraints Install kubectl if it's not already installed. Use KinD to create a local Kubernetes cluster. - Install kind if it's not already installed. Install docker if it's not already installed. Output format Summarize task output as follows: Results in tabular format The summary table should have 2 columns: - First column: Component - Second column: Details prompt: | Objective Create a new KinD cluster. Tasks: Create a single-node local Kubernetes cluster named {{ cluster name }}. - If the cluster {{ cluster name }} already exists, delete the old one and create a new one Cluster must be accessible via kubectl post-install This task is not considered complete until the kubernetes cluster is up and running. This means: - Node status is "Ready" - All system pods are running Provide output summary as per output instructions above. Do NOT deviate from the format. parameters: - key: cluster name input type: string requirement: required default: "my-cluster" description: "Name of the k9s cluster to create" extensions: - type: builtin name: developer display name: Developer Tools description: null timeout: 300 bundled: true available tools: settings: goose provider: anthropic goose model: claude-sonnet-5 temperature: 0.0 author: contact: avillela Let’s break it down: - version : The version of the recipe the can be whatever you want . - title : Name of the recipe. - description : What is your recipe about? - instructions : General directives for the model to follow when executing the recipe. These include things like: persona : What role is the model taking on? rules/inputs/constraints : This includes things like dos and don’ts, and links to reference documentation. outputs : What do you want the model to output in the end, and in what format? - prompt : The actual things you want the recipe to do. I like to provide a task list. Don’t try to do too many things in the prompt. You should have one specific goal, and the tasks should be related to that goal. - parameters : Just like you can pass parameters to a script or function, you can pass parameters to a Goose recipe You must define the parameter name, default value, parameter type, and whether it’s mandatory or optional. You reference parameters in the recipe using double curly braces: {{ parameter name }} - settings : This section is totally optional. If you include it, it overrides the provider settings in ~/.config/goose/config.yaml . The settings values include: goose provider : In our case, it’s set anthropic . To use this provider, you will need an ANTHROPIC API KEY . You are prompted for this value to set up the anthropic provider when you run goose configure . You can also set it as an environment variable. Be sure to set it before running goose session or goose run --recipe