Goose Recipes in 2026: Automate Repeatable Local AI Workflows with Ollama

If you have already set up goose with Ollama, the next useful step is not another model comparison. It is turning a successful agent session into a workflow you can reliably repeat. Goose calls those reusable workflows recipes: portable YAML configurations that can package instructions, prompts, model settings, extensions, parameters, retries and even sub-recipes.

This makes recipes particularly interesting for local AI users who want to move from “I can get an agent to do this once” to “I can run the same controlled workflow again.” Goose's official documentation describes recipes as reusable configurations, and its current CLI supports listing, opening, validating and generating shareable recipe links. Goose Recipe Reference and Goose CLI documentation are the primary references for the behavior covered here.

Why goose recipes are a different Local AI use case

A normal prompt is usually tied to one conversation. A skill is useful when an agent needs reusable knowledge or a repeatable procedure on demand. A custom agent changes the role and behavior of the agent. A recipe goes one step further: it packages a repeatable task with configuration and can be prepared for automation.

That distinction matters if you are running local models. You may want the same code-review process, documentation check, release-risk scan or repository maintenance workflow to run against different projects without rebuilding the entire prompt and tool configuration every time.

What a goose recipe actually contains

The current recipe reference supports YAML or JSON, although the documentation recommends YAML and notes that .yml files are not supported by the goose CLI. A recipe must have a title and description and provide either instructions or a prompt.

A minimal recipe can look like this:

version: "1.0.0"
title: "Review a Python Project"
description: "Inspect a Python repository and report actionable issues."

instructions: |
  Review the repository systematically.
  Inspect the project structure before making changes.
  Run relevant tests where possible.
  Do not modify files unless explicitly asked.

prompt: |
  Review the current repository for correctness, maintainability,
  dependency risks, and obvious test gaps.
  Produce a concise report with findings and recommended next steps.

The important point is that this is configuration, not just a saved prompt. Goose recipes can also define model/provider settings, parameters, extensions, structured responses, retry behavior and sub-recipes.

Build a practical local recipe with Ollama

If your existing workflow already uses goose with Ollama, keep the first recipe deliberately small. Do not start by giving an agent ten MCP extensions and permission to modify your whole machine.

For example, a repository review recipe could explicitly select a local provider and cap agent turns:

version: "1.0.0"
title: "Local Repository Review"
description: "Review a repository with a local Ollama model."

settings:
  goose_provider: "ollama"
  goose_model: "YOUR_LOCAL_MODEL"
  temperature: 0.2
  max_turns: 20

instructions: |
  Work read-only unless the user explicitly authorizes edits.
  Inspect the repository before making conclusions.
  Run focused tests when they are available.
  Separate confirmed findings from suggestions.

prompt: |
  Review the current repository.
  Check architecture, error handling, tests, dependency risks,
  and obvious security issues.
  Return findings grouped by severity and include file paths
  and concrete recommendations.

Replace YOUR_LOCAL_MODEL with a model that is actually available in your Ollama installation. Do not copy a model name from an old tutorial and assume it still exists locally.

Verify the recipe before running an agent

Goose provides a dedicated validation command. This is useful because YAML errors and schema mistakes are much cheaper to catch before an agent session starts.

goose recipe validate local-review.yaml

You can also inspect the recipes goose can currently discover:

goose recipe list
goose recipe list --verbose
goose recipe list --format json

The JSON form is especially useful when you are building scripts around goose. The CLI documentation also provides commands for opening recipes and generating shareable deep links.

Run the recipe without turning it into a dangerous automation

Once validation succeeds, open the recipe from the CLI:

goose recipe open local-review.yaml

If the recipe is parameterized, values can be supplied when opening it. The exact parameter names come from your recipe definition.

For a local AI workflow, treat the first few runs as verification runs. Confirm that the selected provider and model are the ones you expected, that the extensions are the ones you intended to expose, and that the agent is operating inside the correct project directory.

Add parameters instead of cloning recipes

One of the most useful recipe features is parameterization. Instead of maintaining separate recipes for every project or environment, define values that change from run to run.

parameters:
  - key: project_name
    input_type: string
    requirement: required
    description: "Project name to review"

prompt: |
  Review the project named {{ project_name }}.
  Focus on correctness, maintainability and test coverage.

The exact parameter syntax and available fields should be checked against the current recipe reference before deploying a production workflow. Parameters become especially useful when a team shares one recipe but applies it to different repositories or environments.

Use extensions carefully

Recipes can package extension configuration. This is powerful because the workflow can arrive with the tools it expects, but it also increases the security boundary.

Goose currently describes itself as an extensible local agent with MCP-based extensions, and its official site lists security controls including tool permissions and sandbox mode. Its documentation also makes clear that extensions can provide access to external systems.

For a local recipe, start with the smallest extension set that can accomplish the task. A repository review normally does not need access to your browser, cloud drive, production database and shell tools simultaneously.

Sub-recipes: when a workflow becomes a pipeline

Recipes can call sub-recipes. This is where goose starts becoming interesting as an automation framework rather than simply an interactive coding assistant.

A larger workflow might be structured like this:

1. Inspect the repository.
2. Run a test-planning sub-recipe.
3. Run a security-review sub-recipe.
4. Run a documentation-review sub-recipe.
5. Combine the findings into a final report.

The recipe reference supports named sub-recipes, paths, parameter values and a setting for whether repeated sub-recipes should run sequentially. Keep these workflows bounded. More agents do not automatically mean better results, especially with smaller local models.

Use max_turns to control runaway local workloads

A local agent can consume significant CPU, GPU, RAM and time if it is allowed to iterate indefinitely. Goose recipes expose max_turns in settings. The official reference notes that this controls how many iterations an agent can perform before stopping and that recipe-level settings can also affect subagents unless they override the value.

For a first local recipe, a conservative limit is sensible. If a workflow repeatedly needs far more turns, investigate why before simply increasing the limit. Common causes include a model struggling with tool calls, a task that is underspecified, a test command that never terminates, or an agent repeatedly revisiting the same failure.

Make the output machine-checkable when automation matters

Recipes also support a response configuration for structured outputs and retry settings with success checks. This is useful when a workflow is expected to produce something that another step can evaluate.

For example, a CI-oriented recipe could be designed around a small structured result such as:

status: pass | fail
summary: short explanation
blocking_findings: number

The exact response schema should be defined using the current goose recipe schema rather than assuming that arbitrary YAML will be accepted. The benefit is that success criteria become explicit instead of relying on a human to decide whether an agent “looked okay.”

Where recipes fit with skills and MCP

This is where the broader local-agent ecosystem gets confusing. Goose supports MCP extensions, recipes, skills and custom agents, while other tools such as LM Studio Bionic also support the Agent Skills format.

LM Studio's current Bionic documentation says Bionic can use standard SKILL.md files, install skills from URLs, create skills and use compatible skills from other applications. That makes skills a useful cross-tool format for reusable agent knowledge. Goose recipes solve a different problem: packaging a repeatable workflow and its configuration.

If your goal is “teach several agents how our team performs database migrations,” a skill may be the right abstraction. If your goal is “run the migration-review workflow with these extensions, this model configuration, these parameters and these checks,” a recipe is closer to the problem.

Recipe discovery and sharing

Goose can load recipes from local filesystem locations and, when configured, GitHub repositories. The recipe reference documents GOOSE_RECIPE_PATH for local search paths and GOOSE_RECIPE_GITHUB_REPO for a configured GitHub recipe repository.

The CLI can also create a shareable deep link:

goose recipe deeplink local-review.yaml

For a team, keep recipes in version control and review changes like code. A recipe can change what an agent is instructed to do and which extensions it can use, so treating recipe files as harmless prompt snippets is a mistake.

Security checklist before sharing a recipe

• Review every extension. Do not assume an MCP server is harmless because its name sounds familiar.
• Limit permissions. Give the agent only the filesystem, shell and network access it needs.
• Keep secrets out of prompts. Use the provider's supported credential mechanisms instead of hard-coding keys in YAML.
• Cap turns. Use max_turns for workflows that can loop.
• Validate first. Run goose recipe validate before distributing a recipe.
• Test on a non-production repository. Especially when shell or write-capable extensions are enabled.
• Review downloaded recipes. A portable workflow is still executable agent configuration.

When goose recipes are not the right choice

Do not create a recipe simply because you can. For a one-off question, a normal prompt is simpler. For reusable knowledge that should only be loaded when relevant, a skill may be better. For a stable agent identity, use a custom agent. And if the workflow is primarily a conventional deterministic script, a normal shell script, Make target or CI job may be easier to test and maintain.

Goose recipe troubleshooting

The recipe will not validate

Start with the exact error from goose recipe validate. Check YAML indentation, required fields, file extension and whether the schema fields match the current recipe reference. Remember that the current reference recommends .yaml and explicitly says .yml is not supported by the CLI.

The recipe uses the wrong model

Check the recipe's settings and provider configuration. Confirm that the model is installed or otherwise available through the selected provider. Do not confuse the model name displayed in a GUI with the identifier expected by the provider.

A sub-recipe fails while the main recipe works

Validate the sub-recipe independently and then test the parent workflow. Inspect paths, parameters and session behavior. Sub-recipes are separate execution units, so a working parent prompt does not prove that every child workflow is correctly configured.

The agent keeps looping

Reduce max_turns, make the success condition explicit and inspect the tool output. If the model repeatedly fails to interpret a tool response, changing the model or simplifying the workflow can be more effective than simply increasing the turn limit.

A practical starting workflow

If you already have goose + Ollama working, the sensible progression is:

1. Pick one workflow you have manually repeated at least a few times.
2. Write the workflow as a minimal YAML recipe.
3. Validate it with goose recipe validate.
4. Run it interactively on a non-critical project.
5. Add parameters only where repetition requires them.
6. Add one extension at a time and verify the permission boundary.
7. Add sub-recipes only when the workflow genuinely benefits from separation.
8. Introduce structured responses or retry checks when another system needs to consume the result.
9. Store the recipe in version control and review changes like code.

This approach keeps the local AI stack understandable. Instead of accumulating dozens of prompts and extensions, you build a small library of tested workflows that can be rerun consistently.

FAQ

Can goose recipes use Ollama?

Yes. Goose supports Ollama as a provider, and recipe settings can specify a provider and model. The exact model identifier depends on what is available in your Ollama setup.

Are goose recipes the same as Agent Skills?

No. They overlap conceptually but solve different problems. Skills package reusable knowledge or procedures, while recipes package repeatable workflows and configuration such as prompts, parameters, extensions and model settings.

Can recipes run automatically?

Recipes are designed to support repeatable workflows and automation, including headless execution and scheduling patterns. Use conservative permissions and explicit success checks for unattended workflows.

Can a recipe use MCP?

Yes. Recipes can configure extensions, and goose integrates with MCP-based extensions. Only enable the tools required by the workflow.

Should I put API keys inside the recipe?

No. Keep credentials in the provider or environment configuration supported by goose. Treat a recipe as shareable configuration and assume that anything embedded in it could be copied.

Can I share a goose recipe with another person?

Yes. Goose supports recipe discovery through local paths and configured GitHub repositories, and its CLI can generate a recipe deep link. Review the contents and extension permissions before sharing or importing one.

Useful GyanAangan guides

• Goose + Ollama Local AI Agent Setup in 2026
• How to Secure Goose MCP Extensions in 2026
• MCP Inspector 2.8.0: Debug Local AI MCP Servers
• Cline Skills in 2026
• Ollama + ChatGPT Desktop in 2026

Official sources

• Goose official site
• Goose GitHub repository
• Goose Recipe Reference
• Goose CLI Commands
• LM Studio Bionic Skills documentation
• LM Studio Bionic Skills announcement

Bottom line: goose recipes are worth learning when your local agent work has moved beyond isolated chats. They provide a practical “workflow as configuration” layer between a one-off prompt and a fully engineered automation system. Start small, validate every recipe, keep permissions narrow, and only add MCP extensions or sub-recipes when they solve a real problem.