How Recipes Work in goose

Updated

A Recipe in goose is a portable YAML configuration that captures a workflow so it can be reused, shared, and run again — by you, your team, or an automated system like CI. Instead of re-explaining a task and re-selecting tools every time, you save the instructions, extensions, parameters, and any subrecipes into one file, then run that file whenever you need the workflow. This is the mechanism goose uses to turn a one-off agent session into something repeatable and distributable.

What a Recipe contains

Based on goose's documentation, a Recipe can bundle:

  • Instructions — the prompt or task description that tells the agent what to do.
  • Extensions — the MCP connections the workflow needs (databases, APIs, browsers, GitHub, Google Drive, and others from the 70+ documented extensions).
  • Parameters — values you can supply at run time so the same Recipe adapts to different inputs.
  • Subrecipes — smaller Recipes nested inside a larger one, letting you compose complex workflows from reusable parts.

Because it's a single YAML file, a Recipe is self-contained: whoever runs it gets the same instructions and tool setup without manual configuration.

Why Recipes matter

The core problem Recipes solve is repetition. A task you do once in a chat — reviewing a pull request, processing files, running a research pass — normally has to be re-set-up every time. A Recipe freezes that setup so it can be:

  • Reused — run the same workflow on demand without rebuilding it.
  • Shared — hand the YAML to a teammate so they run your exact process.
  • Automated — run inside CI, where no human is present to configure anything.

This is what makes Recipes the unit of reuse and distribution for agent workflows in goose, rather than something tied to a single interactive session.

How to use a Recipe

  1. Define the workflow you want to repeat — the task, the tools it needs, and any values that change between runs.
  2. Capture it as a Recipe — write the instructions, list the extensions, and expose variable inputs as parameters. Break out reusable chunks as subrecipes if the workflow is large.
  3. Run it — execute the Recipe in goose (Desktop, CLI, or API) or in CI. Supply parameter values for that run.
  4. Verify the result — check that the agent used the expected extensions and produced the intended output. If a parameter was wrong or an extension wasn't connected, the run will reflect that.
  5. Share or version it — commit the YAML so your team and CI use the same definition.

Expected result: the same workflow runs consistently across machines and people, because the instructions and tool connections travel with the file.

Common sticking points

  • Missing extensions — a Recipe references an extension that isn't connected in the environment where it runs. The workflow can't complete until that MCP connection exists.
  • Unset or wrong parameters — parameters are the run-time inputs; if they're not supplied or are incorrect, the agent works on the wrong target.
  • Subrecipe scope — nesting Recipes adds structure but also more places for a misconfigured piece to fail; test subrecipes individually before composing them.
  • CI differences — an environment that runs a Recipe in CI may lack credentials or tools that exist on your local machine, so validate there separately.

Where Recipes fit in goose

Recipes sit alongside goose's other capabilities: it runs on your machine as a general-purpose agent (not only for code), works with 15+ LLM providers including your existing Claude, ChatGPT, or Gemini subscriptions via ACP, and connects to tools through the Model Context Protocol open standard. Recipes are the layer that makes any of those workflows portable and shareable rather than session-bound. For the exact YAML schema and current field names, check the Recipes documentation on goose-docs.ai, since the format is the authoritative source for how to author one.